On 24/11/2021 08:06, Mark Thomas wrote:
On 23/11/2021 20:42, Michael B Allen wrote:
On Tue, Nov 23, 2021 at 2:59 PM Thomas Hoffmann (Speed4Trade GmbH)
wrote:
Short Addendum:
The "destroyed" flag gets set, when the dispose-method of the
GSSCredentialImpl was invoked.
Currently, I have no clu
tings,
Thomas
-Ursprüngliche Nachricht-
Von: Michael B Allen
Gesendet: Dienstag, 23. November 2021 21:42
An: Tomcat Users List
Betreff: Re: Authentication with Browser stopped working / missing exception
handling in getRemainingLifetime
On Tue, Nov 23, 2021 at 2:59 PM Thomas Hof
On 23/11/2021 20:42, Michael B Allen wrote:
On Tue, Nov 23, 2021 at 2:59 PM Thomas Hoffmann (Speed4Trade GmbH)
wrote:
Short Addendum:
The "destroyed" flag gets set, when the dispose-method of the GSSCredentialImpl
was invoked.
Currently, I have no clue when and how it happens, but I have see
On Tue, Nov 23, 2021 at 2:59 PM Thomas Hoffmann (Speed4Trade GmbH)
wrote:
>
> Short Addendum:
>
> The "destroyed" flag gets set, when the dispose-method of the
> GSSCredentialImpl was invoked.
> Currently, I have no clue when and how it happens, but I have seen this
> problem every few months.
>
021 20:51
An: Tomcat Users List
Betreff: AW: Authentication with Browser stopped working / missing exception
handling in getRemainingLifetime
Hello Mike,
I checked the last Java 17 Sources, the illegalStateException is still there:
https://github.com/openjdk/jdk/blob/jdk-17%2B35/src/java.securit
n: Tomcat Users List
Betreff: Re: Authentication with Browser stopped working / missing exception
handling in getRemainingLifetime
On Mon, Nov 22, 2021 at 2:39 AM Thomas Hoffmann (Speed4Trade GmbH)
wrote:
> Would it be better to also catch IllegalStateException and instead of
> checking
On Mon, Nov 22, 2021 at 2:39 AM Thomas Hoffmann (Speed4Trade GmbH)
wrote:
> Would it be better to also catch IllegalStateException and instead of
> checking left == 0 to change it to left <= 0 ?
I would argue that this is a bug in JGSS. JGSS has been a comedy of
errors over the years. I thought
exception
handling in getRemainingLifetime
On 22/11/2021 07:38, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> Hello,
> we are using apache-tomcat-9.0.54 with LDAP authentication under Windows
> 2012R2.
> One of the user complained that access with Firefox stopped working.
> Would it be
On 22/11/2021 07:38, Thomas Hoffmann (Speed4Trade GmbH) wrote:
Hello,
we are using apache-tomcat-9.0.54 with LDAP authentication under Windows 2012R2.
One of the user complained that access with Firefox stopped working.
Would it be better to also catch IllegalStateException and instead of ch
Hello,
we are using apache-tomcat-9.0.54 with LDAP authentication under Windows 2012R2.
One of the user complained that access with Firefox stopped working.
Looking into the logs I could find the following message:
java.lang.IllegalStateException: This credential is no longer
vali
2012/8/20 Peter Cipov :
> Hello,
> I have encountered ambiguous feature/bug of request
>
> ...servlet code ...
>
> throw new LoginException(String.format("Login failed for user %s from IP %s
> (%s)",
> principalName,
> request.getRemoteAddr(),
> type
Hello,
I have encountered ambiguous feature/bug of request
...servlet code ...
throw new LoginException(String.format("Login failed for user %s from IP
%s (%s)",
principalName,
request.getRemoteAddr(),
type
), ex);
..
t
- Original Message -
> From: Donald Jolley
> To: Tomcat Users List
> Cc:
> Sent: Monday, August 29, 2011 5:38 PM
> Subject: Re: Exception Handling
>
>> Like... what other information do you want to
>> provide? An explanation of what to do to avoid the
> Like... what other information do you want to
> provide? An explanation of what to do to avoid the error? That is
> worthy of a Turing Award if you can pull it off :)
I am interested in identifying as clearly as possible the specific code that
was the root cause of the error. The "original URI"
available
> that I could display on my errors page?
Check the servlet spec section called "Exception Handling" under "Web
Applications". There are a few things that the container is required
to provide to you: stuff like the original URI being processed, the
exception type a
I am happy to report that I finally got exception handling to work using the
web.xml approach. To me this approach makes the most sense for handling
errors. (Forwarding is a different issue.) It was a patchwork of
assistance from many that finally led me to this point. Thanks to all who
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Donald,
On 8/28/2011 4:35 PM, Donald Jolley wrote:
>> Exception handling can be configured in WEB-INF/web.xml
>
> This suggestion seems to hold a lot of promise for error handling.
> The only problem is that I have not been able to
> Exception handling can be configured in WEB-INF/web.xml
This suggestion seems to hold a lot of promise for error handling. The only
problem is that I have not been able to get it to work. I have the
following stanza in the web-app container of my web.xml file:
java.lang.Throwa
- Original Message -
> From: Donald Jolley
> To: Tomcat Users List ; Mark Eggers
>
> Cc:
> Sent: Saturday, August 27, 2011 6:09 PM
> Subject: Re: Exception Handling
>
>> . . . . just my two cents.
>
> I think that's a great idea. There i
> . . . . just my two cents.
I think that's a great idea. There is no substitute for having a good book.
By any chance, is the full title of the book you are referencing, "Head
First Servlets and JSP: Passing the Sun Certified Web Component Developer
Exam"? Then, there is another one with the s
>From: Konstantin Kolinko
>To: Tomcat Users List
>Sent: Saturday, August 27, 2011 12:40 PM
>Subject: Re: Exception Handling
>
>2011/8/27 Donald Jolley :
>> For days I have been playing around with trying to develop a general-purpose
>> forwarding mechanism tha
> What I do is build the response in a string instead of writing it to the
buffer.
Interesting. The string serves as a pseudo buffer which expands in length
as required. Very cool. To use this approach one would have to be dealing
directly with a servlet, right? IOW, this approach would not be
ayed. I realize that I could just stuff that information into the
> response buffer. It seems to me that that approach has the potential for
> being a bit crude depending upon the state of the response buffer at the
> time the exception occurred (it could be right in the middle of a table,
On 8/27/2011 3:10 PM, Donald Jolley wrote:
For days I have been playing around with trying to develop a general-purpose
forwarding mechanism that I could use to forward to an errors page upon the
occurrence of an exception. It has just been revealed to me that this
approach is not going to work
For days I have been playing around with trying to develop a general-purpose
forwarding mechanism that I could use to forward to an errors page upon the
occurrence of an exception. It has just been revealed to me that this
approach is not going to work because once a response is committed it is no
-
> From: "Caldarale, Charles R" <[EMAIL PROTECTED]>
>> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>> > Subject: "Exception handling Container property change"
>> >
>> > Everytime I load my app context, the log yiel
: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > Subject: "Exception handling Container property change"
> >
> > Everytime I load my app context, the log yields the following
> > MBean exception.
> > Mar 3, 2008 9:12:30 PM
> > org.apache.catalina.mbe
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Subject: "Exception handling Container property change"
>
> Everytime I load my app context, the log yields the following
> MBean exception.
> Mar 3, 2008 9:12:30 PM
> org.apache.catalina.mbeans.ServerL
Env: Tomcat 6.0.14, Jre 1.6
Everytime I load my app context, the log yields the following MBean exception.
What does this error indicate?
Regards
/U
Mar 3, 2008 9:12:30 PM org.apache.catalina.mbeans.ServerLifecycleListener
propertyChange
SEVERE: Exception handling Container property change
29 matches
Mail list logo
