shale-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SHALE-360) NPE in shale on GlassFish
Date Sat, 16 Dec 2006 01:38:57 GMT
    [ 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,com.sun.faces.context.FacesContextImpl@594680) 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,com.sun.faces.context.FacesContextImpl@b07848) 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

        

Mime
View raw message