[ http://issues.apache.org/struts/browse/SHALE-360?page=comments#action_39109 ] Craig McClanahan commented on SHALE-360: ----------------------------------------
Interesting analysis ... thanks for digging in. I'll do a "poor mans threaded repsonse" (i.e. do it by hand) since JIRA doesn't help us here. > I went back and setup the environent that I had which caused this problem and > reproduced it. > I investigated more to find out what combination of jars / etc. where causing > the problem. I found > that when I had jsftemplating.jar file w/ a "Faces Servlet" mapping of > "/resources" (a special mapping > for JSFTemplating's resource resolution, which is configurable) before any > other faces mappings, > the problem exists. Ah ... and if you had done this mapping second, it would have just happened to work? There's an existing issue on Shale Remoting dealing with multiple FacesServlet mappings (SHALE-266) that probably overlaps here. It's not obvious to me at the moment how Remoting would decide which mapping to use in its responses, however. > It appears that Shale Remoting looks for the first Faces Mapping and uses > this to generate the URL to > the resource. In this particular case, that URL is handled in JSFTemplating > LayoutViewHandler.createView(...). > However, JSFTemplating upon not finding the resource (because "static" is > there), logs a message > (see above... I missed that this was coming from my code, had I seen this > that night I would have had a clue), > then continues. The context is already marked "response complete". Makes sense. > It then appears that Shale's "after phase" listener is invoked which leads to > the exception. > This doesn't answer why "mappings" is null, though. RIght, that is still a mystery. > Here's some information to help you find out why "mappings" might be null. > When JSFTemplating > receives a "resource" request, it does very little in "createView()". It does > still return a UIViewRoot > b/c the JSF RI blows up if it returns null. But that UIViewRoot only sets its > renderKitId... and it sets > it to "dummy" b/c it isn't used (except to avoid the NPE in the RI). In the > normal flow of things, the > "createView" would do the following: > * create UIViewRoot > * Set the viewId on the view root > * Set the locale on the view root > * Set the render kit id on the view root > My impl does a couple more things, but nothing that you might depend on. Of > these things, are any > of them used to calculate "mappings"? Shale Remoting lazily configures its Mappings data (basically a JavaBean representation of the configuration rules to use) the first time that a Remoting request asks for it, and then assumes it is read only for the remainder of the application's lifetime. There must still be some scribbling going on, but maybe some of the other ideas here will address this. > Do you need to wait until after the restoreView phase for shale remoting to > execute? That seems to be the earliest point that a phase listener gets invoked. I've never been able to receive anything for a "before Restore View" event. > Can you check to see if the response is complete? If it is, you should not do > any further > processing. This would have avoided the exception in this case, although it > still wouldn't > have worked as expected... but my code did have a useful error message that I > ignored, > so it could have been debugged. That makes good sense, and I'll add in a check ... although I think it only helps the cases where your ViewController actually calls responseComplete() during its createView() processing. > And finally, is there a way in shale to explicitly specify the mapping to > use, similar to > what JSFTemplating does? This would avoid the name-space collision that > occurred here. Do you mean, which FacesServlet mapping to use? That's not currently possible (and was probably the reason that SHALE-266 was filed. Let me put a higher priority on dealing with that ... I had always thought multiple FacesServlet mappings would be a small corner case, but it sounds like that might not be true. > NPE in shale on GlassFish > ------------------------- > > Key: SHALE-360 > URL: http://issues.apache.org/struts/browse/SHALE-360 > Project: Shale > Issue Type: Bug > Components: Remoting > Affects Versions: 1.0.3 > Environment: GlassFish v2 build 28 > Reporter: Ken Paulsen > Fix For: TBD > > > The following are the stack traces I received. It seemed to be intermittent. > I think another bug occurred in Dynamic Faces related to GlassFish restoring > session state across server restarts. After deserialization, transient > variables were not restored... I don't know if something similar is > happenning here, but could be. > [#|2006-12-10T23:13:23.158-0800|INFO|sun-appserver-ee9.1|com.sun.jsftemplating|_ThreadID=12;_ThreadName=httpWorkerThread-8080-0;|WEBUI0004: > The requested resource > (/static/META-INF/libs/scriptaculous/version1.6.4/prototype.js) is not > available.|#] > [#|2006-12-10T23:13:23.159-0800|WARNING|sun-appserver-ee9.1|javax.enterprise.resource.webcontainer.jsf.lifecycle|_ThreadID=12;_ThreadName=httpWorkerThread-8080-0;_RequestID=1de3fe2b-e48e-435e-9976-ce30efc56ed4;|phase(RESTORE_VIEW > 1,[EMAIL PROTECTED]) threw exception: java.lang.NullPointerException null > org.apache.shale.remoting.impl.MappingImpl.viewId(MappingImpl.java:300) > org.apache.shale.remoting.impl.MappingImpl.mapViewId(MappingImpl.java:227) > org.apache.shale.remoting.faces.RemotingPhaseListener.afterPhase(RemotingPhaseListener.java:94) > com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:278) > com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117) > javax.faces.webapp.FacesServlet.service(FacesServlet.java:244) > org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:398) > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:277) > org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:255) > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:188) > org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:586) > com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:73) > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:186) > org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:586) > org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:556) > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1032) > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:137) > org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:586) > org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:556) > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1032) > org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:250) > com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:618) > com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.processNonBlocked(DefaultProcessorTask.java:549) > com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:790) > com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:326) > com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:248) > com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:199) > com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:252) > com.sun.enterprise.web.connector.grizzly.WorkerThreadImpl.run(WorkerThreadImpl.java:103) > |#] > I had accidentally missed the Dynamic Faces init parameter... I thought it > was related to that (note standard lifecycle above). But after installing > the init-param, clearing the generated directory in GF, and restarting the > whole server... I still had an exception from shale: > [#|2006-12-10T23:18:56.641-0800|INFO|sun-appserver-ee9.1|com.sun.jsftemplating|_ThreadID=12;_ThreadName=httpWorkerThread-8080-0;|WEBUI0004: > The requested resource > (/static/META-INF/libs/scriptaculous/version1.6.4/prototype.js) is not > available.|#] > [#|2006-12-10T23:18:56.642-0800|WARNING|sun-appserver-ee9.1|javax.enterprise.resource.webcontainer.jsf.lifecycle|_ThreadID=12;_ThreadName=httpWorkerThread-8080-0;_RequestID=4921981e-6383-4aa8-9655-f474eec508e3;|phase(RESTORE_VIEW > 1,[EMAIL PROTECTED]) threw exception: java.lang.NullPointerException null > org.apache.shale.remoting.impl.MappingImpl.viewId(MappingImpl.java:300) > org.apache.shale.remoting.impl.MappingImpl.mapViewId(MappingImpl.java:227) > org.apache.shale.remoting.faces.RemotingPhaseListener.afterPhase(RemotingPhaseListener.java:94) > com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:278) > com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117) > com.sun.faces.extensions.avatar.lifecycle.PartialTraversalLifecycle.execute(PartialTraversalLifecycle.java:79) > javax.faces.webapp.FacesServlet.service(FacesServlet.java:244) > org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:398) > > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:277) > > org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:255) > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:188) > org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:586) > com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:73) > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:186) > org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:586) > org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:556) > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1032) > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:137) > org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:586) > org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:556) > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1032) > org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:250) > com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:618) > com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.processNonBlocked(DefaultProcessorTask.java:549) > com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:790) > com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:326) > com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:248) > com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:199) > com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:252) > com.sun.enterprise.web.connector.grizzly.WorkerThreadImpl.run(WorkerThreadImpl.java:103) > I had it working at one point, I don't know if I did something to break it or > if it's intermittent. It might not be shale's fault, it may be Dynamic Faces > or the app server which has an error message on startup w/ the init-parm for > Dynamic Faces in place: > [#|2006-12-10T23:24:08.654-0800|WARNING|sun-appserver-ee9.1|javax.enterprise.resource.webcontainer.jsf.lifecycle|_ThreadID=10;_ThreadName=main;_RequestID=82a8ab26-627d-4681-8565-5c574f07d7db;|LifecycleId > com.sun.faces.lifecycle.PARTIAL does not exist|#] > [#|2006-12-10T23:24:08.656-0800|SEVERE|sun-appserver-ee9.1|javax.enterprise.system.container.web|_ThreadID=10;_ThreadName=main;_RequestID=82a8ab26-627d-4681-8565-5c574f07d7db;|WebModule[]StandardWrapper.Throwable > java.lang.IllegalArgumentException: Cant create Lifecycle for id: > com.sun.faces.lifecycle.PARTIAL. > at > com.sun.faces.lifecycle.LifecycleFactoryImpl.getLifecycle(LifecycleFactoryImpl.java:226) > at javax.faces.webapp.FacesServlet.init(FacesServlet.java:170) > at > org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1165) > at > org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:994) > at > org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4689) > at > org.apache.catalina.core.StandardContext.start(StandardContext.java:5081) > at com.sun.enterprise.web.WebModule.start(WebModule.java:299) > at > org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1189) > at org.apache.catalina.core.StandardHost.start(StandardHost.java:924) > at > org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1189) > at > org.apache.catalina.core.StandardEngine.start(StandardEngine.java:520) > at org.apache.catalina.startup.Embedded.start(Embedded.java:916) > at com.sun.enterprise.web.WebContainer.start(WebContainer.java:839) > at > com.sun.enterprise.web.PEWebContainer.startInstance(PEWebContainer.java:750) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
