NullPointerException in ScopedAttributeELResolver.setValue(…

Splash Forums PrettyFaces Users NullPointerException in ScopedAttributeELResolver.setValue(…

This topic contains 19 replies, has 3 voices, and was last updated by  fred 6 years, 9 months ago.

Viewing 15 posts - 1 through 15 (of 20 total)
  • Author
    Posts
  • #17816

    fred
    Participant

    Hi,

    I’ve got this strange problem. When I navigate to my page through a pretty URL I get a stacktrace (see bottom of my post).

    (I’m on glassfish 3.1, jsf2, primefaces2.2, prettyfaces 3.1.0)

    However, the page displays fine, only somewhat slower because of the logging.

    Furthermore when I navigate to the page without using the ‘pretty URL’, I do not get this stack trace.

    If i navigate it like this, everything is ok:

    http://localhost:8080/uwbedrijfsgids-war/faces/bedrijf.xhtml?urlcompanyname=dynaco

    If i navigate it like this, i get the stack trace:

    http://localhost:8080/uwbedrijfsgids-war/dynaco

    (however, i’m using ‘pretty urls’ for other pages and there it works fine…)

    The url mapping i’m using:

    <url-mapping id="bedrijf">
    <pattern value="/#{urlcompanyname}" />
    <view-id>/faces/bedrijf.xhtml</view-id>
    </url-mapping>

    The metadata section of my .xhtml file:

    (there are two optional arguments for the page as well)

    <f:metadata>
    <f:viewParam name="urlcompanyname" value="#{bedrijfBackingBean.urlcompanyname}"/>
    <f:viewParam name="selectedBedrijfsid" value="#{bedrijfBackingBean.selectedBedrijfsid}"/>
    <f:viewParam name="selectedBedrijfsAdresid" value="#{bedrijfBackingBean.selectedCompanyAddressId}"/>
    </f:metadata>

    Has someone got an idea of what could be wrong here?

    Stack trace:

    WARNING: StandardWrapperValve[default]: PWC1406: Servlet.service() for servlet default threw exception
    com.ocpsoft.pretty.PrettyException: PrettyFaces: Exception occurred while processing <bedrijf:#{urlcompanyname}> for URL </dynaco>
    at com.ocpsoft.pretty.faces.beans.ParameterInjector.injectPathParams(ParameterInjector.java:68)
    at com.ocpsoft.pretty.faces.beans.ParameterInjector.injectParameters(ParameterInjector.java:48)
    at com.ocpsoft.pretty.faces.event.PrettyPhaseListener.afterPhase(PrettyPhaseListener.java:93)
    at com.sun.faces.lifecycle.Phase.handleAfterPhase(Phase.java:189)
    at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:107)
    at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:110)
    at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
    at javax.faces.webapp.FacesServlet.service(FacesServlet.java:312)
    at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1523)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
    at com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:113)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
    at org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:79)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
    at org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:820)
    at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:684)
    at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:517)
    at org.apache.catalina.core.ApplicationDispatcher.doDispatch(ApplicationDispatcher.java:488)
    at org.apache.catalina.core.ApplicationDispatcher.dispatch(ApplicationDispatcher.java:379)
    at org.apache.catalina.core.ApplicationDispatcher.dispatch(ApplicationDispatcher.java:336)
    at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:314)
    at com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:104)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
    at org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:79)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:277)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:188)
    at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:641)
    at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
    at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:85)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:185)
    at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:325)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:226)
    at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:165)
    at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:791)
    at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693)
    at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954)
    at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:170)
    at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
    at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
    at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
    at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
    at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
    at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
    at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
    at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:330)
    at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:309)
    at java.lang.Thread.run(Thread.java:619)
    Caused by: java.lang.NullPointerException
    at com.sun.faces.el.ScopedAttributeELResolver.setValue(ScopedAttributeELResolver.java:167)
    at javax.el.CompositeELResolver.setValue(CompositeELResolver.java:386)
    at com.sun.faces.el.FacesCompositeELResolver.setValue(FacesCompositeELResolver.java:100)
    at com.sun.el.parser.AstIdentifier.setValue(AstIdentifier.java:138)
    at com.sun.el.ValueExpressionImpl.setValue(ValueExpressionImpl.java:286)
    at com.ocpsoft.pretty.faces.util.FacesElUtils.setValue(FacesElUtils.java:84)
    at com.ocpsoft.pretty.faces.beans.ParameterInjector.injectPathParams(ParameterInjector.java:64)
    ... 52 more

    #20388

    Strange, it appears that PrettyFaces is attempting to inject values when it should not.

    Any chance you could zip up your test case and send it to me?

    lincoln@ocpsoft.com

    Thanks,

    #20389

    fred
    Participant

    Hi Lincoln,

    Thanks for your reply.

    While I was trying to setup small project to send to you I found the problem. The error occurs from the moment I try to put a p:graphicText component on one of my pages. (This is a PrimeFaces component).

    http://www.primefaces.org/showcase/ui/graphicText.jsf

    Do you have an idea on how to solve this?

    Fred

    #20390

    Hey Fred,

    I just tried to reproduce this issue but everything seems to work without problems. My setup:

    • Tomcat 7.0.2
    • PrettyFaces 3.1.1-SNAPSHOT
    • PrimeFaces 2.2.RC1
    • Mojarra 2.0.3

    Perhaps it only happens on Glassfish? Could you send me your sample app for debugging?

    christian (AT) kaltepoth (DOT) de

    You could also use the PrettyFaces Maven Archetypes to setup a sample quickly:

    https://github.com/chkal/prettyfaces-archetypes/wiki

    #20391

    fred
    Participant

    Hi Christian, I’ve sent you a sample project

    Best regards,

    Fred

    #20392

    Hey Frederik,

    I looked at your project and can now also reproduce this issue with Tomcat. But I’ve to look deeper into it to find the exact cause. It is definitively related to the request p:graphicText creates.

    To work around this issue you could remove the f:viewParam tag for urlcompanyname from your page and directly inject the path parameter into your bean. Something like this:

    <url-mapping id="bedrijf">
    <pattern value="/#{bedrijfBackingBean.urlcompanyname}" />
    <view-id>/faces/bedrijf.xhtml</view-id>
    </url-mapping>

    This should work as expected. I’ll come back to you later with more details.

    #20393

    Hey Frederik,

    I had another look at this issue. First of all: I think it is a Mojarra bug. In my opinion neither Primefaces nor PrettyFaces are responsible for this. Let me try to explain the technical details.

    Primefaces p:graphicText loads the image by creating a second request to the same URL with a few additional query parameters. Primefaces intercepts this request before RESTORE_VIEW phase, writes the image to the response stream and calls FacesContext.responseComplete(). Somehow this prevents that Mojarra creates a UIViewRoot for this request.

    After that the PrettyFaces PrettyPhaseLister gets executed and processes the path parameters and writes the value to the EL context. This is handled by Mojarra’s ScopedAttributeELResolver which checks if the attribute is available in any scope. During this check Mojarra calls facesContext.getViewRoot().getViewMap(). This line throws the NullPointerException cause there is no UIViewRoot for the request.

    I hope that my explanation is correct. You see that the issue is a bit complex! But I think it is definitively a Mojarra bug.

    You can work around this issue by injecting the path parameter directly into the target bean. I hope this workaround is OK for you.

    #20394

    We could probably also help users work around this bug by checking facesContext.isResponseComplete() before doing any injection. — if that method is available.

    I’m not sure that using direct injection is the solution here. Wouldn’t using named path parameters be the solution instead, if the app is failing during injection?

    –Lincoln

    #20395

    We could probably also help users work around this bug by checking facesContext.isResponseComplete() before doing any injection. — if that method is available.

    I think we should do this. If isResponseComplete() is set there isn’t any reason to do the injection as the request will end anyway.

    I’m not sure that using direct injection is the solution here. Wouldn’t using named path parameters be the solution instead, if the app is failing during injection?

    Just to clarify your idea: You are suggesting that we shouldn’t inject the value of the path parameter into the EL context by setting #{urlcompanyname}? If I understand correctly writing the value to the EL context this way isn’t really intended as the primary idea of named path parameters is to add them to the request parameter map, correct?

    #20396

    fred
    Participant

    Hi guys, thanks for looking into the matter.

    When using this mapping:

    <url-mapping id="bedrijf">

    <pattern value="/#{bedrijfBackingBean.urlcompanyname}" />

    <view-id>/faces/bedrijf.xhtml</view-id>

    </url-mapping>

    Pretty urls are no longer automatically constructed when using <h:link> with nested <f:param> tags on other pages that link to my bedrijf.xhtml page.

    Are there other known components that offer the same functionality as the p:graphicText but that do not suffer from this problem? Or is there another way to acquire the same functionality?

    Thanks again for your help

    Best regards

    Fred

    #20397

    Hey Frederik,

    Pretty urls are no longer automatically constructed when using <h:link> with nested <f:param> tags on other pages that link to my bedrijf.xhtml page.

    That is correct. h:link won’t work anymore if you do it this way. One way to get around this would be to use the pretty:link component that ships with PrettyFaces:

    http://ocpsoft.com/docs/prettyfaces/3.1.0/en-US/html/components.html#components.prettylink

    Perhaps this would be an acceptable workaround for the page you need p:graphicText for?

    Are there other known components that offer the same functionality as the p:graphicText but that do not suffer from this problem? Or is there another way to acquire the same functionality?

    I think RichFaces offers a similar component. You could try that one.

    But as the root cause of the problem is a Mojarra bug, you could either switch the JSF implementation and use MyFaces instead or you could patch the Mojarra issue and use the fixed JAR file. I already prepared a Mojarra patch but unfortunately the Mojarra bug tracker is currently in readonly mode due to the java.net migration currently in progress.

    #20398

    Could you please also try mapping your URL this way:

    <url-mapping id="bedrijf">
    <pattern value="/#{ urlcompanyname : bedrijfBackingBean.urlcompanyname }" />
    <view-id>/faces/bedrijf.xhtml</view-id>
    </url-mapping>

    This way h:link will work as expected and the value will be directly injected into the bean. Perhaps this will fix the error you are seeing.

    #20399

    Christian, that’s correct. If pattern="/#{name}" is being injected into EL under ‘name’, that’s a bug and should be fixed. If so, could one of you open an issue for this and attach the sample project?

    I’ve created an issue for the NPE.

    http://code.google.com/p/prettyfaces/issues/detail?id=79

    #20400

    I just attached the sample project to the issue report.

    However, I still think that this is also a Mojarra issue. Their ScopedAttributeELResolver doesn’t check whether there is a UIViewRoot when reading from the view scope which leads to this exception. I will open a ticket in the RI issue tracker as soon as it gets back online.

    #20401

    Ups, just noticed you meant to create a separate issue for the /#{name} injection issue but I’ve already attached the sample project to the existing one. However, I think we can cover these two things with one ticket! :-)

Viewing 15 posts - 1 through 15 (of 20 total)

You must be logged in to reply to this topic.

Comments are closed.