You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Travis Reeder <tr...@gmail.com> on 2005/11/04 00:51:07 UTC

Removed exception logging from FacesServlet on 8/11/05

mbr: Any reason you removed the exception logging?  I've mentioned
this before on the list asking why exceptions are being hidden and I
guess this is why.  There was a method called logException, but it's
removed now.   Any reason for that?

Travis

Re: Removed exception logging from FacesServlet on 8/11/05

Posted by Travis Reeder <tr...@gmail.com>.
Here's another example on a property value that has a NullPointerException
and the only reason I know this is because I had to put a try/catch in the
getter.

HTTP Status 500 -
------------------------------

*type* Exception report

*message*

*description* *The server encountered an internal error () that prevented it
from fulfilling this request.*

*exception*

javax.servlet.ServletException: Cannot get value for expression
'#{myBean.notices}'
	javax.faces.webapp.FacesServlet.service(FacesServlet.java:121)
	org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter(ExtensionsFilter.java:123)
	rhythm.marketplace.filters.AuthFilter.doFilter(AuthFilter.java:138)

*root cause*

javax.faces.FacesException: Cannot get value for expression '#{myBean.notices}'
	org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:422)
	org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:234)
	org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:373)
	javax.faces.webapp.FacesServlet.service(FacesServlet.java:107)
	org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter(ExtensionsFilter.java:123)
	rhythm.marketplace.filters.AuthFilter.doFilter(AuthFilter.java:138)



And the log:

Nov 4, 2005 2:15:54 PM
org.apache.myfaces.context.servlet.ServletExternalContextImpllookupCharacterEncoding
FINE: Incoming request has Content-Type header without character encoding:
application/x-www-form-urlencoded
Nov 4, 2005 2:15:54 PM
org.apache.myfaces.custom.ajax.api.AjaxDecodePhaseListener beforePhase
FINE: In AjaxDecodePhaseListener beforePhase
Nov 4, 2005 2:15:54 PM
org.apache.myfaces.custom.ajax.api.AjaxPhaseListenerafterPhase
FINE: In AjaxPhaseListener afterPhase
Nov 4, 2005 2:15:54 PM
org.apache.myfaces.lifecycle.LifecycleImplisResponseComplete
FINE: exiting from lifecycle.execute in invokeApplication because
getResponseComplete is true from one of the after listeners
Nov 4, 2005 2:15:54 PM
org.apache.myfaces.lifecycle.LifecycleImplisResponseComplete
FINE: exiting from lifecycle.execute in render because getResponseComplete
is true from one of the before listeners
Nov 4, 2005 2:15:54 PM
org.apache.myfaces.application.jsp.JspStateManagerImpl restoreTreeStructure
FINE: No tree structure state found in client request
Nov 4, 2005 2:15:54 PM
org.apache.myfaces.lifecycle.LifecycleImplshouldRenderResponse
FINE: exiting from lifecycle.execute in restoreView because
getRenderResponse is true from one of the after listeners
in getNotices


No exceptions logged anywhere.


Travis



On 11/4/05, Travis Reeder <tr...@gmail.com> wrote:
>
> I am just using the Extensions Filter and an AuthFilter (that does not
> catch any exceptions).
>
> Here's an example of one what happens, this is what I get in my log:
>
> Nov 4, 2005 1:09:27 PM
> org.apache.myfaces.context.servlet.ServletExternalContextImpllookupCharacterEncoding
> FINE: Incoming request has Content-Type header without character encoding:
> application/x-www-form-urlencoded
> Nov 4, 2005 1:09:27 PM
> org.apache.myfaces.custom.ajax.api.AjaxDecodePhaseListener beforePhase
> FINE: In AjaxDecodePhaseListener beforePhase
> LOGGING IN
>
> Please note the LOGGING IN is a system.out.println within my action method
> before the exception is happening.
>
> This is what I get on my screen:
>
>  HTTP Status 500 -
> ------------------------------
>
> *type* Exception report
>
> *message*
>
> *description* *The server encountered an internal error () that prevented
> it from fulfilling this request.*
>
> *exception*
>
> javax.servlet.ServletException: Error calling action method of component with id loginForm:submit
> 	javax.faces.webapp.FacesServlet.service(FacesServlet.java:121)
> 	org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter
> (ExtensionsFilter.java:123)
> 	rhythm.marketplace.filters.AuthFilter.doFilter(AuthFilter.java:138)
>
> *root cause*
>
> javax.faces.FacesException: Error calling action method of component with id loginForm:submit
> 	org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:74)
> 	javax.faces.component.UICommand.broadcast
> (UICommand.java:106)
> 	javax.faces.component.UIViewRoot._broadcastForPhase(UIViewRoot.java:90)
> 	javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:164)
> 	org.apache.myfaces.lifecycle.LifecycleImpl.invokeApplication
> (LifecycleImpl.java:336)
> 	org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:87)
> 	javax.faces.webapp.FacesServlet.service(FacesServlet.java:106)
> 	org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter
> (ExtensionsFilter.java:123)
> 	rhythm.marketplace.filters.AuthFilter.doFilter(AuthFilter.java:138)
>
> *note* *The full stack trace of the root cause is available in the Apache
> Tomcat/5.5.9 logs.*
>
>
> As you can see the exception is nowhere to be found. Is nobody else having
> this behaviour?
>
> Travis
>
> On 11/4/05, Mathias Brökelmann <mb...@googlemail.com> wrote:
> > exceptions where logged multiple times by logException before the
> > change. This wasn´t very effective since it produces a lot of output
> > and it was a pain for the user to find the cause of it. The exception
> > is simply thrown and should be catched and logged by the servlet
> > container.
> >
> > If your exception is not shown it must be catched and not beeing
> > rethrown somewhere. Can you provide us with a test case (jsp + bean
> > code) to reproduce the problem. You are using one or more servlet
> > filters. Can you make sure that they don´t catch the exception and
> > hides them?
> >
> > 2005/11/4, Travis Reeder <tr...@gmail.com>:
> > > mbr: Any reason you removed the exception logging? I've mentioned
> > > this before on the list asking why exceptions are being hidden and I
> > > guess this is why. There was a method called logException, but it's
> > > removed now. Any reason for that?
> > >
> > > Travis
> > >
> >
> >
> > --
> > Mathias
> >
>

Re: Removed exception logging from FacesServlet on 8/11/05

Posted by Travis Reeder <tr...@gmail.com>.
I am just using the Extensions Filter and an AuthFilter (that does not catch
any exceptions).

Here's an example of one what happens, this is what I get in my log:

Nov 4, 2005 1:09:27 PM
org.apache.myfaces.context.servlet.ServletExternalContextImpllookupCharacterEncoding
FINE: Incoming request has Content-Type header without character encoding:
application/x-www-form-urlencoded
Nov 4, 2005 1:09:27 PM
org.apache.myfaces.custom.ajax.api.AjaxDecodePhaseListener beforePhase
FINE: In AjaxDecodePhaseListener beforePhase
LOGGING IN

Please note the LOGGING IN is a system.out.println within my action method
before the exception is happening.

This is what I get on my screen:

 HTTP Status 500 -
------------------------------

*type* Exception report

*message*

*description* *The server encountered an internal error () that prevented it
from fulfilling this request.*

*exception*

javax.servlet.ServletException: Error calling action method of
component with id loginForm:submit
	javax.faces.webapp.FacesServlet.service(FacesServlet.java:121)
	org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter(ExtensionsFilter.java:123)
	rhythm.marketplace.filters.AuthFilter.doFilter(AuthFilter.java:138)

*root cause*

javax.faces.FacesException: Error calling action method of component
with id loginForm:submit
	org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:74)
	javax.faces.component.UICommand.broadcast(UICommand.java:106)
	javax.faces.component.UIViewRoot._broadcastForPhase(UIViewRoot.java:90)
	javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:164)
	org.apache.myfaces.lifecycle.LifecycleImpl.invokeApplication(LifecycleImpl.java:336)
	org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:87)
	javax.faces.webapp.FacesServlet.service(FacesServlet.java:106)
	org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter(ExtensionsFilter.java:123)
	rhythm.marketplace.filters.AuthFilter.doFilter(AuthFilter.java:138)

*note* *The full stack trace of the root cause is available in the Apache
Tomcat/5.5.9 logs.*


As you can see the exception is nowhere to be found. Is nobody else having
this behaviour?

Travis

On 11/4/05, Mathias Brökelmann <mb...@googlemail.com> wrote:
> exceptions where logged multiple times by logException before the
> change. This wasn´t very effective since it produces a lot of output
> and it was a pain for the user to find the cause of it. The exception
> is simply thrown and should be catched and logged by the servlet
> container.
>
> If your exception is not shown it must be catched and not beeing
> rethrown somewhere. Can you provide us with a test case (jsp + bean
> code) to reproduce the problem. You are using one or more servlet
> filters. Can you make sure that they don´t catch the exception and
> hides them?
>
> 2005/11/4, Travis Reeder <tr...@gmail.com>:
> > mbr: Any reason you removed the exception logging? I've mentioned
> > this before on the list asking why exceptions are being hidden and I
> > guess this is why. There was a method called logException, but it's
> > removed now. Any reason for that?
> >
> > Travis
> >
>
>
> --
> Mathias
>

Re: Removed exception logging from FacesServlet on 8/11/05

Posted by Mathias Brökelmann <mb...@googlemail.com>.
exceptions where logged multiple times by logException before the
change. This wasn´t very effective since it produces a lot of output
and it was a pain for the user to find the cause of it. The exception
is simply thrown and should be catched and logged by the servlet
container.

If your exception is not shown it must be catched and not beeing
rethrown somewhere. Can you provide us with a test case (jsp + bean
code) to reproduce the problem. You are using one or more servlet
filters. Can you make sure that they don´t catch the exception and
hides them?

2005/11/4, Travis Reeder <tr...@gmail.com>:
> mbr: Any reason you removed the exception logging?  I've mentioned
> this before on the list asking why exceptions are being hidden and I
> guess this is why.  There was a method called logException, but it's
> removed now.   Any reason for that?
>
> Travis
>


--
Mathias