Re: Authentication with Browser stopped working / missing exception handling in getRemainingLifetime

[Mark Thomas]

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 clue when and how it happens, but I have seen 
this problem every few months.
So it is only occurring sometimes. Maybe if the Kerberos ticket 
expires and the http session is still alive (?)


Nevertheless, the application should be able to recover from this 
situation and handles it like "not authenticated".


So as suspected it may actually be an invalid credential that maybe
Tomcat had a hand in. If Tomcat disposed the credential and then
subsequently tried to use it for any reason, that would be "invalid".
So that might warrant investigation before submitting a bug report.


That might be possible.

Tomcat calls dispose when the user explicitly logs out or the session 
expires. The OP is using http2 so parallel requests are likely.


I'll look into this some more.


It looks like concurrent requests for an expired session will trigger 
this. Avoiding the IllegalStateExcpetion would require adding 
synchronization to Request.getUserPrincipal(). Given that issue occurs 
once every few months my preference is to catch the ISE rather than 
avoid it since avoiding it has a (small) impact on every request.


I've checked and multiple calls to dispose() are safe so the current 
approach appears to be sound. I'll add some comments to the code for 
future maintainers.


Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

AW: Authentication with Browser stopped working / missing exception handling in getRemainingLifetime

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

though it might be a bug in the implementation, the current proposed 
remediation within Tomcat
is still a good choice for the time being in my point of view and won't have 
any bad side effects in future.
It makes Tomcat more robust, more robust than the JGSS API requires.

Greetings,
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 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.
> So it is only occurring sometimes. Maybe if the Kerberos ticket 
> expires and the http session is still alive (?)
>
> Nevertheless, the application should be able to recover from this situation 
> and handles it like "not authenticated".

So as suspected it may actually be an invalid credential that maybe Tomcat had 
a hand in. If Tomcat disposed the credential and then subsequently tried to use 
it for any reason, that would be "invalid".
So that might warrant investigation before submitting a bug report.

But I would still argue that a JGSS implementation should not throw exceptions 
that are not defined by the API and currently only GSSException is defined.

Correction: This is not a bug in the JGSS API, it is (almost
certainly) a bug in the *Oracle / Sun implementation* of JGSS.

Mike

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Authentication with Browser stopped working / missing exception handling in getRemainingLifetime

[Mark Thomas]

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 seen this problem 
every few months.
So it is only occurring sometimes. Maybe if the Kerberos ticket expires and the 
http session is still alive (?)

Nevertheless, the application should be able to recover from this situation and handles 
it like "not authenticated".


So as suspected it may actually be an invalid credential that maybe
Tomcat had a hand in. If Tomcat disposed the credential and then
subsequently tried to use it for any reason, that would be "invalid".
So that might warrant investigation before submitting a bug report.


That might be possible.

Tomcat calls dispose when the user explicitly logs out or the session 
expires. The OP is using http2 so parallel requests are likely.


I'll look into this some more.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Authentication with Browser stopped working / missing exception handling in getRemainingLifetime

[Michael B Allen]

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.
> So it is only occurring sometimes. Maybe if the Kerberos ticket expires and 
> the http session is still alive (?)
>
> Nevertheless, the application should be able to recover from this situation 
> and handles it like "not authenticated".

So as suspected it may actually be an invalid credential that maybe
Tomcat had a hand in. If Tomcat disposed the credential and then
subsequently tried to use it for any reason, that would be "invalid".
So that might warrant investigation before submitting a bug report.

But I would still argue that a JGSS implementation should not throw
exceptions that are not defined by the API and currently only
GSSException is defined.

Correction: This is not a bug in the JGSS API, it is (almost
certainly) a bug in the *Oracle / Sun implementation* of JGSS.

Mike

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

AW: Authentication with Browser stopped working / missing exception handling in getRemainingLifetime

[Thomas Hoffmann (Speed4Trade GmbH)]

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.
So it is only occurring sometimes. Maybe if the Kerberos ticket expires and the 
http session is still alive (?)

Nevertheless, the application should be able to recover from this situation and 
handles it like "not authenticated".

Greetings, 
Thomas


-Ursprüngliche Nachricht-
Von: Thomas Hoffmann (Speed4Trade GmbH) 
 
Gesendet: Dienstag, 23. November 2021 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.security.jgss/share/classes/sun/security/jgss/GSSCredentialImpl.java

public int getRemainingLifetime() throws GSSException {

if (destroyed) {
throw new IllegalStateException("This credential is " +
"no longer valid");
}
...

Latest Java 18 Code looks the same.

I agree, that there are better ways to tell the caller about the invalid 
Kerberos ticket status.
IllegalStateException is a runtime exception whereas the method only declares a 
checked GSSException which is maybe not the best way to design this method.

If somebody has good connections to the Java developers, maybe he/she can 
trigger an improvement. Unfortunately it might break the compatibility to other 
tools if a checked exception is used.

Btw: you are right, the authentication is done via Kerberos. For role 
assignment, LDAP is used in combination in our case.

Thanks!
Thomas


-Ursprüngliche Nachricht-
Von: Michael B Allen 
Gesendet: Dienstag, 23. November 2021 17:32
An: 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 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 it had mostly stabilized over the last 5-10 years but this 
is a good example of the sort of bad behavior from that lib. Throwing an 
IllegalStateException there is a bad API choice. I have to wonder if that was 
not the designers intention. The getRemainingLifetime API documentation does 
not say anything about it throwing an IllegalStateException when your cred 
expires. You might want to try the latest JRE if you're using something old. Or 
maybe there's something screwy about the cred and it's tripping up an 
unexpected code path. I assume you mean Kerberos and not LDAP BTW.

But I think the only real short term solution for now would be to catch the 
IllegalStateException and just set left = 0.

Mike

--
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

B CB  [  
X  ܚX KK[XZ[
 \ \  ][  X  ܚX P X ]
 \X K ܙ B  ܈Y][ۘ[  [X[  K[XZ[
 \ \  Z[ X ]
 \X K ܙ B 

AW: Authentication with Browser stopped working / missing exception handling in getRemainingLifetime

[Thomas Hoffmann (Speed4Trade GmbH)]

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.security.jgss/share/classes/sun/security/jgss/GSSCredentialImpl.java

public int getRemainingLifetime() throws GSSException {

if (destroyed) {
throw new IllegalStateException("This credential is " +
"no longer valid");
}
...

Latest Java 18 Code looks the same.

I agree, that there are better ways to tell the caller about the invalid 
Kerberos ticket status.
IllegalStateException is a runtime exception whereas the method only declares a 
checked GSSException which is maybe not the best way to design this method.

If somebody has good connections to the Java developers, maybe he/she can 
trigger an improvement. Unfortunately it might break the compatibility
to other tools if a checked exception is used.

Btw: you are right, the authentication is done via Kerberos. For role 
assignment, LDAP is used in combination in our case.

Thanks!
Thomas


-Ursprüngliche Nachricht-
Von: Michael B Allen  
Gesendet: Dienstag, 23. November 2021 17:32
An: 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 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 it had mostly stabilized over the last 5-10 years but this 
is a good example of the sort of bad behavior from that lib. Throwing an 
IllegalStateException there is a bad API choice. I have to wonder if that was 
not the designers intention. The getRemainingLifetime API documentation does 
not say anything about it throwing an IllegalStateException when your cred 
expires. You might want to try the latest JRE if you're using something old. Or 
maybe there's something screwy about the cred and it's tripping up an 
unexpected code path. I assume you mean Kerberos and not LDAP BTW.

But I think the only real short term solution for now would be to catch the 
IllegalStateException and just set left = 0.

Mike

--
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Authentication with Browser stopped working / missing exception handling in getRemainingLifetime

[Michael B Allen]

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 it had mostly stabilized over the
last 5-10 years but this is a good example of the sort of bad behavior
from that lib. Throwing an IllegalStateException there is a bad API
choice. I have to wonder if that was not the designers intention. The
getRemainingLifetime API documentation does not say anything about it
throwing an IllegalStateException when your cred expires. You might
want to try the latest JRE if you're using something old. Or maybe
there's something screwy about the cred and it's tripping up an
unexpected code path. I assume you mean Kerberos and not LDAP BTW.

But I think the only real short term solution for now would be to
catch the IllegalStateException and just set left = 0.

Mike

-- 
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

AW: Authentication with Browser stopped working / missing exception handling in getRemainingLifetime

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello Mark,

thank you very much for your lightning speed fix and answer 😊

Have a nice day,
Thomas

-Ursprüngliche Nachricht-
Von: Mark Thomas  
Gesendet: Montag, 22. November 2021 18:44
An: users@tomcat.apache.org
Betreff: Re: Authentication with Browser stopped working / missing 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 better to also catch IllegalStateException and instead of 
> checking left == 0 to change it to left <= 0 ?

Both fair points. Thanks for bringing them to the community's attention. 
I've fixed both issues for the next set of releases.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Authentication with Browser stopped working / missing exception handling in getRemainingLifetime

[Mark Thomas]

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 checking 
left == 0 to change it to left <= 0 ?


Both fair points. Thanks for bringing them to the community's attention. 
I've fixed both issues for the next set of releases.


Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Authentication with Browser stopped working / missing exception handling in getRemainingLifetime

[Thomas Hoffmann (Speed4Trade GmbH)]

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 
valid
   at 
java.security.jgss/sun.security.jgss.GSSCredentialImpl.getRemainingLifetime(GSSCredentialImpl.java:208)
   at 
org.apache.catalina.connector.Request.getUserPrincipal(Request.java:2659)
   at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:508)
   at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:135)
   at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
   at 
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:687)
   at 
org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:312)
   at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:78)
   at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:357)
   at 
org.apache.coyote.http2.StreamProcessor.service(StreamProcessor.java:413)
   at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
   at 
org.apache.coyote.http2.StreamProcessor.process(StreamProcessor.java:74)
   at 
org.apache.coyote.http2.StreamRunnable.run(StreamRunnable.java:35)

Looking into the sources of Request.java I can see that the exception is not 
catched and handled:

public Principal getUserPrincipal() {
if (userPrincipal instanceof TomcatPrincipal) {
GSSCredential gssCredential =
((TomcatPrincipal) userPrincipal).getGssCredential();
if (gssCredential != null) {
int left = -1;
try {
left = gssCredential.getRemainingLifetime();
} catch (GSSException e) {
log.warn(sm.getString("coyoteRequest.gssLifetimeFail",
userPrincipal.getName()), e);
}
   if (left == 0) {


Would it be better to also catch IllegalStateException and instead of checking 
left == 0 to change it to left <= 0 ?

The only possible way to resolve the issue was to delete the browser cache 
including the credentials.

Greetings,
Thomas

Re: Null pointer when calling getRemoteAddr in exception handling

[Konstantin Kolinko]

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
> ), ex);
>
> ..
>
> throws java.lang.NullPointerException
> at
> org.apache.coyote.http11.Http11AprProcessor.actionInternal(Http11AprProcessor.java:272)
> at
> org.apache.coyote.http11.AbstractHttp11Processor.action(AbstractHttp11Processor.java:834)
> at org.apache.coyote.Request.action(Request.java:346)
> at
> org.apache.catalina.connector.Request.getRemoteAddr(Request.java:1280)
> at
> org.apache.catalina.connector.RequestFacade.getRemoteAddr(RequestFacade.java:517)
>
>
> but this equivalent code works as it should
>
> ...servlet code ...
>
> String remoteAddr = request.getRemoteAddr();
>
> throw new LoginException(String.format("Login failed for user %s from IP %s
> (%s)",
> principalName,
> remoteAddr,
> type
> ), ex);
>
> ..
>
> Is this correct behavior ?

1. It depends on version of Tomcat and on which connector you are using.

If it is some old version of Tomcat 5.5 (your are not saying what you
are using) and an APR connector (as can be confirmed from your stack
trace), then yes, it is known behaviour that was fixed a year ago.

2. If you are using request object outside of its request processing
cycle, it is also a known behaviour. (You do not have access to the
socket if it is not the thread responding to the request).

If it is none of the above, then yes - that would be a bug, but you
have to provide a recipe (e.g. a simple web application) on how to
reproduce it.

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Null pointer when calling getRemoteAddr in exception handling

[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
), ex);

..

throws java.lang.NullPointerException
	at  
org.apache.coyote.http11.Http11AprProcessor.actionInternal(Http11AprProcessor.java:272)
	at  
org.apache.coyote.http11.AbstractHttp11Processor.action(AbstractHttp11Processor.java:834)

at org.apache.coyote.Request.action(Request.java:346)
at 
org.apache.catalina.connector.Request.getRemoteAddr(Request.java:1280)
	at  
org.apache.catalina.connector.RequestFacade.getRemoteAddr(RequestFacade.java:517)



but this equivalent code works as it should

...servlet code ...

String remoteAddr = request.getRemoteAddr();

throw new LoginException(String.format("Login failed for user %s from IP  
%s (%s)",

principalName,
remoteAddr,
type
), ex);

..

Is this correct behavior ?

--
Peter Cipov



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Exception Handling

[Mark Eggers]

- 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 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" that you 
> mentioned
> sounded helpful.  So far I have not been able to figure out how to do that.
> I was able to add a stack trace.
> 
> So far, I am quite willing to live with what I have.  Thanks for your input.
> 
>          ... doug
>

There's an implicit object called pageContext.


The javadoc for that (javax.servlet.jsp.PageContext) has a lot of interesting 
information.

One of the methods is getErrorData. Looking at the javadoc for ErrorData 
(javax.servlet.jsp.ErrorData), there's a method called getRequestURI. This 
sounds exactly like what you're looking for:

${pageContext.errorData.requestURI} will give you the URI.

Also in the javadoc for pageContext, there's a method called getException, 
which returns an Exception object.

java.lang.Exception implements java.lang.Throwable, which has a lot of nice 
information.

One nice one is getMessage, which may give a more detailed message than the 
default toString. You could access that by:

${pageContext.exception.message}

Another one is getStackTrace, which returns an array of StackTraceElement. So 
you could
print the stack trace using the following code (if you've included the standard 
tag lib):


   ${st}


This makes use of the StackTraceElement.toString() method. There are obviously 
more games you can play. For example, if you don't want the entire stack trace, 
you can do this:

${pageContext.exception.stackTrace[0].fileName}
${pageContext.exception.stackTrace[0].lineNumber}
${pageContext.exception.stackTrace[0].className}

There may be more than one class you're responsible for, so the first entry in 
the array might not be the most interesting one. Here's a slightly different 
foreach loop which just dumps class names and line numbers:


   ${st.className} ${st.lineNumber}


See the java.lang.StackTraceElement for other useful features.

In short, look at implicit objects, then see what's populated when 
isErrorPage="true" is set, and finally look at the javadoc for the classes.


. . . . just my two cents.
/mde/


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Exception Handling

[Donald Jolley]

> 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" that you mentioned
sounded helpful.  So far I have not been able to figure out how to do that.
I was able to add a stack trace.

So far, I am quite willing to live with what I have.  Thanks for your input.

 ... doug

Re: Exception Handling

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Donald,

On 8/29/2011 5:46 PM, Donald Jolley wrote:
> Finally, as I have said, I now have the error handling working.

Great.

> My errors page displays the information obtained from 
> exception.toString().  Is there any other information 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 and message, the exception object itself, etc.

Generally speaking, if you want "more" information, you'll have to
manage it yourself. 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 :)

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5cDk4ACgkQ9CaO5/Lv0PCQ5wCgvO6Ku6hpBPPl7uSHpoeYEJRW
LdgAoLiOKdBF1DoIMZ82XYt3wnOlsyhE
=9fVe
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Exception Handling

[Donald Jolley]

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
contributed.

I also want to report exactly what the hangup was because it illustrates how
newbies like myself can easily miss important points.

The solution is very obvious once the problem is understood.  The thing is
that the web.xml approach is an exception catcher.  It is an alternative to
try/catch blocks.  For web.xml to catch an exception, the exception has to
actually be thrown and not caught by some other means such as a catch
block.  In the situation under study the exception that I was dealing with
was logged but caught in a catch block.  Therefore, web.xml never saw the
exception.  The solution was simply to remove the try/catch blocks and
substitute a throws statement.  Once I did that, web.xml began catching the
exceptions just fine.  It's all just a case of understanding.  In that
regard I want to report that I have taken Mark's suggestion and ordered a
new book dealing with servlets and JSP (expedited shipping).  I should have
it in a few days.  I recognize that I need some major help that goes beyond
what a list can provide.  I do, however, sincerely appreciate all the help
that I have received on this list.

Finally, as I have said, I now have the error handling working.  My errors
page displays the information obtained from exception.toString().  Is there
any other information available that I could display on my errors page?

Thanks.

  ... doug

Re: Exception Handling

[Christopher Schultz]

-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 get it to work.  I
> have the following stanza in the web-app container of my web.xml
> file:
> 
>  java.lang.Throwable 
> /errors.jsp 
> 
> It is my understanding that the above is a catch-all that will trap
> any error.

Servlets aren't allowed to throw Throwable directly, so that might be
the problem. Try catching java.lang.RuntimeException instead.

> I also have the following at the top of my errors.jsp file:
> 
> <%@ page isErrorPage="true" %>

That is proper procedure.

> That almost sounds like the display of the error page specified in
> web.xml won't get triggered unless the default Tomcat error page
> would have been displayed.  IOW, it sort of suggests that it
> wouldn't work with errors that would not trigger the display of the
> Tomcat default error page (such as Java exceptions)  I don't know
> if that is the case or not; but, it sure doesn't seem to be
> working.

No, the implementation looks conceptually like this:

try {
  Servlet servlet = // get the servlet to execute

  servlet.service(request, response);

  // check status code, show appropriate error page defined in web.xml
} catch (RuntimeException|IOException|ServletException ex) {
  Servlet errorHandler = // get error handler from web.xml or default

  request.setAttribute("javax.servlet.error.exception", ex);
  // and others... see SVR 10.9.1

  try {
errorHandler.service(request, response);
  } catch (Throwable t) {
// show default error page, guaranteed not to fail
  }
}

Tomcat should be able to intercept any exception that a servlet can
legally throw. Again, java.lang.Throwable is too generic for that.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5bxpMACgkQ9CaO5/Lv0PB7HACeLJ0psZpMC21m9dZ7o+bYbzC7
GkAAoLMDFZAVOLavQhDS703Y4DTGBv6D
=3+3P
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Exception Handling

[Donald Jolley]

 > 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.Throwable
  /errors.jsp
 

It is my understanding that the above is a catch-all that will trap any
error.

I also have the following at the top of my errors.jsp file:

<%@ page isErrorPage="true" %>

It's my understanding that the above 2 things is all that is required.

One piece of documentation that I have been reading (
http://wiki.metawerx.net/wiki/Web.xml.ErrorPage} states:

Tomcat will check your web.xml <http://wiki.metawerx.net/wiki/Web.xml> for
these elements before displaying it's default error page.

That almost sounds like the display of the error page specified in web.xml
won't get triggered unless the default Tomcat error page would have been
displayed.  IOW, it sort of suggests that it wouldn't work with errors that
would not trigger the display of the Tomcat default error page (such as Java
exceptions)  I don't know if that is the case or not; but, it sure doesn't
seem to be working.

Thanks for your suggestion.  As I say, I think that it holds a lot of
promise if I could just get it to work.

 ... doug

Re: Exception Handling

[Mark Eggers]

- 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 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 same title except that it has
> SCWCD appended to the end.  I don't know what that's all about.  
> Finally, I
> am assuming there is a typo in the list of authors, it's "Basham" 
> rather
> than Batham.  I just want to be certain that I am ordering the correct
> book.  I plan on ordering "Head First Servlets and JSP: Passing the Sun
> Certified Web Component Developer Exam" without the "SCWCD" 
> appended to the
> end.  Would that be correct?  Thanks.
> 
>         ... doug
> <http://www.amazon.com/Head-First-Servlets-JSP-Certified/dp/0596005407/ref=sr_1_1?s=books&ie=UTF8&qid=1314493158&sr=1-1>
>

Yep, sorry for the typo. You've linked to the first edition. You might want to 
check out the second edition.

BTW, the Head First style of books aren't for everyone. I recommend browsing 
one if you can before purchasing . . . especially if you're comfortable with a 
more traditional approach.

. . . . just my two cents.

/mde/


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Exception Handling

[Donald Jolley]

> . . . . 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 same title except that it has
SCWCD appended to the end.  I don't know what that's all about.  Finally, I
am assuming there is a typo in the list of authors, it's "Basham" rather
than Batham.  I just want to be certain that I am ordering the correct
book.  I plan on ordering "Head First Servlets and JSP: Passing the Sun
Certified Web Component Developer Exam" without the "SCWCD" appended to the
end.  Would that be correct?  Thanks.

... doug

Re: Exception Handling

[Mark Eggers]

>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 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
>> longer possible to forward.  That being the case, I'd love to hear
>> suggestions as to what should be done upon the occurrence of an exception.
>> At a minimum, I'd like to get some basic information about the exception
>> displayed.  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, for
>> example).  Suggestions?
>
>1. Exception handling can be configured in WEB-INF/web.xml (see spec)
>
>2. I suggest you to look at MVC web frameworks. In short, you have a
>servlet that calls your class that does all the work. After processing
>you forward to a JSP page and the page is then used only to display
>the result (and thus having errors there will be less probable).
>
>My favorite one is part of the Spring framework. [1][2] There are
>others as well (e.g. Struts).
>
>[1] http://www.springsource.org/download
>[2] 
>http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/mvc.html
>
>Best regards,
>Konstantin Kolinko


Donald,

You've been exploring a lot of fundamental ideas about servlets / jsp / java 
web applications.

I'd like to suggest a different book if I could:

Head First Servlets and JSP by Batham, Sierra, Bates

I have the first edition, but the second edition is out.

The book talks about (among other things) error handling (pgs 457-464), 
forwarding (pgs 204-205 including IllegalStateException), and weaves MVC 
throughout the book. It's a pretty fun read, with lots of questions, answers, 
and problems to work on.

I think you should build a few small web applications by hand (using the MVC 
design pattern of course) before plunging into frameworks. Once you are 
comfortable with how that works, then investigate frameworks.

Doing it this way will help you understand what the frameworks are doing under 
the covers, as well as give you an appreciation for the amount of effort that 
frameworks can save.

Like Konstantin, I like the Spring framework. Struts 2 is interesting, but 
seems to marry code and output formatting too tightly for my tastes. JSF 2 is 
nice, but the standard output is XHTML, which Internet Explorer doesn't handle 
properly.

. . . . just my two cents.
/mde/

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Exception Handling

[Donald Jolley]

> 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 practical
within the context of a JSP, right?

> Then if an exception occurs I just dump the previous contents of the
string,
> change it to the error display and write it to the output.

Of course you could also forward to an errors page on the occurrence of an
exception since there has been no committed response at that point.

> Whether this will work for you depends on exactly what you're doing,
> and how large your responses are.

Since responses are just HTML, I would not expect them to be very big.
Someone made mention of the fact that the default buffer size was 8k.  I'm
really surprised that I exceeded that with my test.

Thanks for the input.

   ... doug

Re: Exception Handling

[Konstantin Kolinko]

2011/8/27 Donald Jolley :
> 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
> longer possible to forward.  That being the case, I'd love to hear
> suggestions as to what should be done upon the occurrence of an exception.
> At a minimum, I'd like to get some basic information about the exception
> displayed.  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, for
> example).  Suggestions?

1. Exception handling can be configured in WEB-INF/web.xml (see spec)

2. I suggest you to look at MVC web frameworks. In short, you have a
servlet that calls your class that does all the work. After processing
you forward to a JSP page and the page is then used only to display
the result (and thus having errors there will be less probable).

My favorite one is part of the Spring framework. [1][2] There are
others as well (e.g. Struts).

[1] http://www.springsource.org/download
[2] 
http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/mvc.html

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Exception Handling

[David Kerber]

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 because once a response is committed it is no
longer possible to forward.  That being the case, I'd love to hear
suggestions as to what should be done upon the occurrence of an exception.
At a minimum, I'd like to get some basic information about the exception
displayed.  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, for
example).  Suggestions?

Thanks for any input.

   ... doug



What I do is build the response in a string instead of writing it to the 
buffer.  Then if an exception occurs I just dump the previous contents 
of the string, change it to the error display and write it to the 
output.  If no exception, then just write the original string to the 
output.  Whether this will work for you depends on exactly what you're 
doing, and how large your responses are.


D


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Exception Handling

[Donald Jolley]

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
longer possible to forward.  That being the case, I'd love to hear
suggestions as to what should be done upon the occurrence of an exception.
At a minimum, I'd like to get some basic information about the exception
displayed.  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, for
example).  Suggestions?

Thanks for any input.

  ... doug

RE: "Exception handling Container property change"

[/U]

Hello.

This exception stack trace is very distracting to the folks who watch for
problems in the log. Could you pl tell me if writing my own Custom
VirtualWebappClassLoader requires me to intrument the classloader
woth a specific MBean?

Thanks,

/U


/U wrote:
> 
> Thanks! It looks like this is related to the long conversation we had
> about
> using VirtualWebappClassLoader a couple of months ago.
> 
> I needed to use VirtualWebappLoader and hence chose to extend
> WebappLoader ("CustomWebappClassLoader) and install the class in
> ${CATALINA_BASE}/lib.
> This classloader is used with multiple contexts but in loading
> a specific context alone, Tomcat yields this error:
> 
>Caused by: java.lang.Exception: ManagedBean is not found with
> CustomWebappClassLoader
>   at 
> org.apache.catalina.mbeans.MBeanUtils.createMBean(MBeanUtils.java:397)
>   ... 46 more
> 
> Is my custom WebappLoader supposed to provide an MBean? If I choose not
> to,
> would it be a fatal error (as in one which would abort the context)?
> 
> Regards,
> 
> /U
> 
> 
>  -- Original message --
> 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 yields the following 
>> > MBean exception.
>> > Mar 3, 2008 9:12:30 PM 
>> > org.apache.catalina.mbeans.ServerLifecycleListener propertyChange
>> > SEVERE: Exception handling Container property change
>> > javax.management.MBeanException
>> >at 
>> > org.apache.catalina.mbeans.MBeanUtils.createMBean(MBeanUtils.java:398)
>> 
>> Look further in the logs - there should be a nested exception related to
>> the one above with this text:
>> "ManagedBean is not found with "
>> 
>> The actual  will tell you what MBean can't be created.
>> 
>>  - Chuck
>> 
>> 
>> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
>> MATERIAL and is thus for use only by the intended recipient. If you
>> received this in error, please contact the sender and delete the e-mail
>> and its attachments from all computers.
>> 
>> -
>> To start a new topic, e-mail: users@tomcat.apache.org
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>> 
> 
> 
> -
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/%22Exception-handling-Container-property-change%22-tp15820562p17590598.html
Sent from the Tomcat - User mailing list archive at Nabble.com.


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: "Exception handling Container property change"

[uma_rk]

Thanks! It looks like this is related to the long conversation we had about
using VirtualWebappClassLoader a couple of months ago.

I needed to use VirtualWebappLoader and hence chose to extend
WebappLoader ("CustomWebappClassLoader) and install the class in 
${CATALINA_BASE}/lib.
This classloader is used with multiple contexts but in loading
a specific context alone, Tomcat yields this error:

   Caused by: java.lang.Exception: ManagedBean is not found with 
CustomWebappClassLoader
at 
org.apache.catalina.mbeans.MBeanUtils.createMBean(MBeanUtils.java:397)
... 46 more

Is my custom WebappLoader supposed to provide an MBean? If I choose not to,
would it be a fatal error (as in one which would abort the context)?

Regards,

/U


 -- Original message --
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 yields the following 
> > MBean exception.
> > Mar 3, 2008 9:12:30 PM 
> > org.apache.catalina.mbeans.ServerLifecycleListener propertyChange
> > SEVERE: Exception handling Container property change
> > javax.management.MBeanException
> > at 
> > org.apache.catalina.mbeans.MBeanUtils.createMBean(MBeanUtils.java:398)
> 
> Look further in the logs - there should be a nested exception related to
> the one above with this text:
> "ManagedBean is not found with "
> 
> The actual  will tell you what MBean can't be created.
> 
>  - Chuck
> 
> 
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you
> received this in error, please contact the sender and delete the e-mail
> and its attachments from all computers.
> 
> -
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: "Exception handling Container property change"

[Caldarale, Charles R]

> 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.ServerLifecycleListener propertyChange
> SEVERE: Exception handling Container property change
> javax.management.MBeanException
>   at 
> org.apache.catalina.mbeans.MBeanUtils.createMBean(MBeanUtils.java:398)

Look further in the logs - there should be a nested exception related to
the one above with this text:
"ManagedBean is not found with "

The actual  will tell you what MBean can't be created.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

"Exception handling Container property change"

[uma_rk]

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
javax.management.MBeanException
at 
org.apache.catalina.mbeans.MBeanUtils.createMBean(MBeanUtils.java:398)
at 
org.apache.catalina.mbeans.ServerLifecycleListener.processContainerPropertyChange(ServerLifecycleListener.java:1091)
at 
org.apache.catalina.mbeans.ServerLifecycleListener.propertyChange(ServerLifecycleListener.java:216)
at 
java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:339)
at 
java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:276)
at 
org.apache.catalina.core.ContainerBase.setLoader(ContainerBase.java:373)
at 
org.apache.catalina.core.StandardContext.setLoader(StandardContext.java:1323)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
org.apache.tomcat.util.IntrospectionUtils.callMethod1(IntrospectionUtils.java:899)
at org.apache.tomcat.util.digester.SetNextRule.end(SetNextRule.java:193)
at org.apache.tomcat.util.digester.Rule.end(Rule.java:229)
at 
org.apache.tomcat.util.digester.Digester.endElement(Digester.java:1058)
at 
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:601)

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]