Details
Bug
Major
Description
I dumped out a stack trace from the constructor for the BridgeFacesContext and noticed that it gets
called twice for every call to the PersistentFacesServlet. I'm of the opinion we should know why we are
doing this and either (a) document it or (b) fix it so that we avoid any unnecessary object creation.
BridgeFacesContext: 1
java.lang.Exception: Stack trace
at java.lang.Thread.dumpStack()V(Unknown Source)
at com.icesoft.faces.context.BridgeFacesContext.<init>(Ljavax.faces.context.ExternalContext;)V
(BridgeFacesContext.java:31)
at com.icesoft.faces.context.FacesContextFactoryImpl.getFacesContext
(Ljava.lang.Object;Ljava.lang.Object;Ljava.lang.Object;Ljavax.faces.lifecycle.Lifecycle;)
Ljavax.faces.context.FacesContext;(FacesContextFactoryImpl.java:51)
at com.icesoft.faces.webapp.xmlhttp.PersistentFacesCommonlet.getFacesContext
(Ljava.lang.Object;Ljava.lang.Object;Ljava.lang.Object;)Ljavax.faces.context.FacesContext;
(PersistentFacesCommonlet.java:150)
at com.icesoft.faces.webapp.xmlhttp.PersistentFacesServlet.service
(Ljavax.servlet.ServletRequest;Ljavax.servlet.ServletResponse;)V(PersistentFacesServlet.java:110)
....
BridgeFacesContext: 2
java.lang.Exception: Stack trace
at java.lang.Thread.dumpStack()V(Unknown Source)
at com.icesoft.faces.context.BridgeFacesContext.<init>(Ljavax.faces.context.ExternalContext;)V
(BridgeFacesContext.java:31)
at com.icesoft.faces.webapp.xmlhttp.PersistentFacesServlet.setupPersistentContext
(Ljavax.servlet.ServletContext;Ljavax.servlet.http.HttpServletRequest;)V(PersistentFacesServlet.java:233)
at com.icesoft.faces.webapp.xmlhttp.PersistentFacesServlet.service
(Ljavax.servlet.ServletRequest;Ljavax.servlet.ServletResponse;)V(PersistentFacesServlet.java:143)
...
called twice for every call to the PersistentFacesServlet. I'm of the opinion we should know why we are
doing this and either (a) document it or (b) fix it so that we avoid any unnecessary object creation.
BridgeFacesContext: 1
java.lang.Exception: Stack trace
at java.lang.Thread.dumpStack()V(Unknown Source)
at com.icesoft.faces.context.BridgeFacesContext.<init>(Ljavax.faces.context.ExternalContext;)V
(BridgeFacesContext.java:31)
at com.icesoft.faces.context.FacesContextFactoryImpl.getFacesContext
(Ljava.lang.Object;Ljava.lang.Object;Ljava.lang.Object;Ljavax.faces.lifecycle.Lifecycle;)
Ljavax.faces.context.FacesContext;(FacesContextFactoryImpl.java:51)
at com.icesoft.faces.webapp.xmlhttp.PersistentFacesCommonlet.getFacesContext
(Ljava.lang.Object;Ljava.lang.Object;Ljava.lang.Object;)Ljavax.faces.context.FacesContext;
(PersistentFacesCommonlet.java:150)
at com.icesoft.faces.webapp.xmlhttp.PersistentFacesServlet.service
(Ljavax.servlet.ServletRequest;Ljavax.servlet.ServletResponse;)V(PersistentFacesServlet.java:110)
....
BridgeFacesContext: 2
java.lang.Exception: Stack trace
at java.lang.Thread.dumpStack()V(Unknown Source)
at com.icesoft.faces.context.BridgeFacesContext.<init>(Ljavax.faces.context.ExternalContext;)V
(BridgeFacesContext.java:31)
at com.icesoft.faces.webapp.xmlhttp.PersistentFacesServlet.setupPersistentContext
(Ljavax.servlet.ServletContext;Ljavax.servlet.http.HttpServletRequest;)V(PersistentFacesServlet.java:233)
at com.icesoft.faces.webapp.xmlhttp.PersistentFacesServlet.service
(Ljavax.servlet.ServletRequest;Ljavax.servlet.ServletResponse;)V(PersistentFacesServlet.java:143)
...
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
-
-
- ICE-261 has been marked as a duplicate of this bug. ***
-
Show
Ted Goddard
added a comment -
ICE-261 has been marked as a duplicate of this bug. ***
This object creation takes place within the servlets, so it's very unlikely that the code is executed during
design time.
Show
Ted Goddard
added a comment -
This object creation takes place within the servlets, so it's very unlikely that the code is executed during
design time.
There is an additional problem related to this. In one of the other areas where
we get the BridgeFacesContext, we do not set the appropriate reference so the
response. It's in the PersistentFacesServlet:
void setupPersistentContext(ServletContext context, HttpServletRequest
request)
But providing null as a reference to the response, developers trying to access
the response are unable to do anything. Is this the intended usage?
Show
Deryk Sinotte
added a comment - There is an additional problem related to this. In one of the other areas where
we get the BridgeFacesContext, we do not set the appropriate reference so the
response. It's in the PersistentFacesServlet:
void setupPersistentContext(ServletContext context, HttpServletRequest
request)
{
// We have our own copy of the request because when a request has
completed, we need to
// ensure access to some of its information. So we keep relevant
information
// in a environment-friendly (servlet,portlet) container for future use.
ServletEnvironmentRequest envReq = new ServletEnvironmentRequest(request);
// Create instances of the appropriate contexts and state and stuff it
in the session.
BridgeExternalContext perExtContext =
new BridgeExternalContext(context, envReq, null);
BridgeFacesContext persistentContext = new
BridgeFacesContext(perExtContext);
perExtContext.getRequestParameterMap()
.put("viewNumber", String.valueOf(viewNumber));
//Make sure that any PersistentFacesState instances retrieved
//by applications are still valid with the current context
//objects
PersistentFacesState.resetInstance(perExtContext.getSessionMap(),
String.valueOf(viewNumber), persistentContext);
}
But providing null as a reference to the response, developers trying to access
the response are unable to do anything. Is this the intended usage?
Recommend target 1.1 – no developer-visible consequences, but may require a fair bit of
implementation work to fix.
Show
Ted Goddard
added a comment -
Recommend target 1.1 – no developer-visible consequences, but may require a fair bit of
implementation work to fix.
Fixed during refactoring (represented by ICE-1249).
Show
Mircea Toma
added a comment - Fixed during refactoring (represented by ICE-1249 ).
Address if necessary during code cleanup.