Details
-
Type:
Improvement
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 3.0
-
Fix Version/s: 3.0.1, EE-3.0.0.GA
-
Component/s: Framework
-
Labels:None
-
Environment:ICEfaces3
Description
The main issue is that, even when in Development stage, there are Server Internal Errors that will popup a dialog in the browser, but won't provide any information on what the error was. Nothing at all in the server logs, and only if you capture the network traffic can you get the exception type and message from the server post response. There should be a stack trace in the server log.
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
We have existing logging, when in development stage, at the fine level. But it's not showing the test error in the log, when I get the server internal error. Changing it to log level ALL doesn't help either:
if(fc.isProjectStage(ProjectStage.Development))
{ log.log(Level.ALL,"queued exception", ex); }I've modified the logging level to WARNING when in development mode so that it'll be more straightforward to log exceptions that appear on the queue simply by setting:
<context-param>
<param-name>javax.faces.PROJECT_STAGE</param-name>
<param-value>Development</param-value>
</context-param>
However, I don't believe all exceptions make it on to this queue so we'll still need to treat future issues on a case-by-case basis.
Verified, using the scenario from ICE-7809 (fix locally rolled back), I can now see the stack trace in the server log:
Mar 22, 2012 3:22:50 PM org.icefaces.impl.application.ExtendedExceptionHandler handle
WARNING: queued exception
java.lang.UnsupportedOperationException: this method is here only to maintain binary compatibility w/ the RI
at javax.faces.component.UIData.setDataModel(UIData.java:1961)
at org.icefaces.impl.component.UISeriesBase.broadcast(UISeriesBase.java:466)
at org.icefaces.impl.component.UISeriesBase.broadcast(UISeriesBase.java:481)
at javax.faces.component.UIViewRoot._broadcastAll(UIViewRoot.java:1015)
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:284)
at javax.faces.component.UIViewRoot._process(UIViewRoot.java:1309)
at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:746)
at org.apache.myfaces.lifecycle.InvokeApplicationExecutor.execute(InvokeApplicationExecutor.java:38)
at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:170)
at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:197)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:928)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:539)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:298)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
It is likely possible for us to log Exceptions on the way by using this class:
src/main/java/org/icefaces/impl/application/ExtendedExceptionHandler.java
Please try adding some logging to that class to see if it has access to the Exception you observed in the test case. If this works, then we should likely log a stack trace for everything that is not explicitly a ViewExpired.