javaserverfaces
  1. javaserverfaces
  2. JAVASERVERFACES-1696

2.0.3 Build Fails on SIMPLE Composite Component

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 2.0.3
    • Fix Version/s: 2.1_gf31_m5
    • Component/s: facelets
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      1,696
    • Status Whiteboard:
      Hide

      size_small importance_medium

      Show
      size_small importance_medium

      Description

      Attached is the example...

      on change attribute named "value" to REQUIRED , i'm recive a error saying the
      attribue is required (but i'm passing a FIELD)... but , i change to false the
      "requied" attribute of "value" property of component... and RUN de Application...

      populate a FIRST and SECOND FIELD IN SCREEN, the THREE FIELD have no value , the
      normal operation is a VALIDATION ERROR , but on CLICK in BUTTON "VAI VAI" ,
      throws the exception above...

      I'm using Mojarra 2.0.3 (SNAPSHOT 20100602)

      Other interessant thing is afeter VALIDATION ERROR , the VALUE OF the FIELDS
      displays with NO VALUE... is bug too ?

      The Exception:

      java.lang.NullPointerException
      at
      com.sun.faces.facelets.tag.jsf.CompositeComponentTagHandler.createMetaRuleset(CompositeComponentTagHandler.java:247)
      at
      com.sun.faces.facelets.tag.jsf.CompositeComponentTagHandler.setAttributes(CompositeComponentTagHandler.java:222)
      at
      com.sun.faces.facelets.tag.jsf.CompositeComponentTagHandler.applyNextHandler(CompositeComponentTagHandler.java:178)
      at
      com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:162)
      at
      javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:114)
      at
      javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:94)
      at
      com.sun.faces.facelets.tag.jsf.ValidatorTagHandlerDelegateImpl.applyWrapping(ValidatorTagHandlerDelegateImpl.java:186)
      at
      com.sun.faces.facelets.tag.jsf.ValidatorTagHandlerDelegateImpl.apply(ValidatorTagHandlerDelegateImpl.java:81)
      at
      javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:114)
      at
      javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:94)
      at
      javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:131)
      at
      com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:162)
      at
      javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:114)
      at
      javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:94)
      at
      javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:131)
      at
      com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:162)
      at
      javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:114)
      at
      javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:94)
      at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:89)
      at
      javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:94)
      at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:79)
      at com.sun.faces.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:148)
      at
      com.sun.faces.application.view.FaceletViewHandlingStrategy.buildView(FaceletViewHandlingStrategy.java:711)
      at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:96)
      at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:97)
      at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:135)
      at javax.faces.webapp.FacesServlet.service(FacesServlet.java:309)
      at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1523)
      at
      org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
      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:332)
      at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:233)
      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)

        Activity

        Hide
        sheetalv added a comment -

        Created an attachment (id=1282)
        new test case for review

        Show
        sheetalv added a comment - Created an attachment (id=1282) new test case for review
        Hide
        Ed Burns added a comment -

        >>>>> On Wed, 08 Sep 2010 11:12:28 -0700, Sheetal Vartak
        <sheetal.vartak@oracle.com> said:

        SV> If the action on the button is not specified correctly i.e. in our
        SV> case the wrong action is "/submit.xhtml". This does not get resolved
        SV> to anything during the Invoke App phase's handling of the
        SV> navigation. In this case, we need to see a good error message rather
        SV> than the NPE which is currently being thrown.

        SV> Index:
        jsf-ri/src/main/java/com/sun/faces/facelets/tag/jsf/ComponentTagHandlerDelegateImpl.java
        SV> ===================================================================
        SV> —
        jsf-ri/src/main/java/com/sun/faces/facelets/tag/jsf/ComponentTagHandlerDelegateImpl.java
        (revision 8594)
        SV> +++
        jsf-ri/src/main/java/com/sun/faces/facelets/tag/jsf/ComponentTagHandlerDelegateImpl.java
        (working copy)
        SV> @@ -174,6 +174,8 @@
        SV> if (c instanceof NamingContainer) {
        SV> oldUnique = ComponentSupport.setNeedUniqueIds(ctx, false);
        SV> setUniqueIds = true;
        SV> + if (createCompositeComponentDelegate != null)
        SV> + createCompositeComponentDelegate.setCompositeComponent(c);

        First, our coding style (even though some find it it unreadable)
        dictates we always use curly braces with an if/else statement.

        Second, it's not appropriate to assume that just because c is a
        NamingContainer it is a composite component. Please add an additional
        operand to your conditional UIComponent.isCompositeComponent(c).

        Like this:

        if (createCompositeComponentDelegate != null &&
        UIComponent.isCompositeComponent(c))

        { createCompositeComponentDelegate.setCompositeComponent(c); }

        Otherwise, looks good. r=edburns

        Ed

        Show
        Ed Burns added a comment - >>>>> On Wed, 08 Sep 2010 11:12:28 -0700, Sheetal Vartak <sheetal.vartak@oracle.com> said: SV> If the action on the button is not specified correctly i.e. in our SV> case the wrong action is "/submit.xhtml". This does not get resolved SV> to anything during the Invoke App phase's handling of the SV> navigation. In this case, we need to see a good error message rather SV> than the NPE which is currently being thrown. SV> Index: jsf-ri/src/main/java/com/sun/faces/facelets/tag/jsf/ComponentTagHandlerDelegateImpl.java SV> =================================================================== SV> — jsf-ri/src/main/java/com/sun/faces/facelets/tag/jsf/ComponentTagHandlerDelegateImpl.java (revision 8594) SV> +++ jsf-ri/src/main/java/com/sun/faces/facelets/tag/jsf/ComponentTagHandlerDelegateImpl.java (working copy) SV> @@ -174,6 +174,8 @@ SV> if (c instanceof NamingContainer) { SV> oldUnique = ComponentSupport.setNeedUniqueIds(ctx, false); SV> setUniqueIds = true; SV> + if (createCompositeComponentDelegate != null) SV> + createCompositeComponentDelegate.setCompositeComponent(c); First, our coding style (even though some find it it unreadable) dictates we always use curly braces with an if/else statement. Second, it's not appropriate to assume that just because c is a NamingContainer it is a composite component. Please add an additional operand to your conditional UIComponent.isCompositeComponent(c). Like this: if (createCompositeComponentDelegate != null && UIComponent.isCompositeComponent(c)) { createCompositeComponentDelegate.setCompositeComponent(c); } Otherwise, looks good. r=edburns Ed
        Hide
        sheetalv added a comment -

        issue has been fixed. Here are my comments from the code review request :
        Here's some background on the issue.
        If the action on the button is not specified correctly i.e. in our case the
        wrong action is "/submit.xhtml". This does not get resolved to anything during
        the Invoke App phase's handling of the navigation. In this case, we need to see
        a good error message rather than the NPE which is currently being thrown.

        During the Invoke Application phase, NavigationHandlerImpl.getViewId() correctly
        adds a message as follows in the server.log :

        #|2010-09-07T10:08:17.947-0700|FINE|glassfish3.1|javax.enterprise.resource.webcontainer.jsf.context|_ThreadID=19;_ThreadName=Thread-1;ClassName=com.sun.faces.context.FacesContextImpl;MethodName=addMessage;|Adding
        Message[sourceId=<<NONE>>,summary=Unable to find matching navigation case with
        from-view-id '/composite/simpleCompositeComponentUsingPage.xhtml' for action
        '#

        {hello.getNextAction}

        ' with outcome '/submit.xhtml')|#]

        But since this phase cannot come up with the right navigation rule, the render
        response phase continues to again build the same old view. During this
        buildView() call, the ComponentTagHandlerDelegateImpl creates a new
        CompositeComponentTagHandler instance but the "cc" object for this instance is
        null (the ComponentTagHandlerDelegateImpl created during Restore View phase is
        discarded. That one had the "cc" set). Since "cc" is null, we see the NPE. Now,
        the ComponentTagHandlerDelegateImpl is able to find the UINamingContainer
        instance for cc via findChild(). But it does not have any way of setting it in
        the CompositeComponentTagHandler. Hence the fix as attached. With the fix, after
        we hit the button, we come back to the same old view but with the error message
        in it.

        code changes already attached.

        Show
        sheetalv added a comment - issue has been fixed. Here are my comments from the code review request : Here's some background on the issue. If the action on the button is not specified correctly i.e. in our case the wrong action is "/submit.xhtml". This does not get resolved to anything during the Invoke App phase's handling of the navigation. In this case, we need to see a good error message rather than the NPE which is currently being thrown. During the Invoke Application phase, NavigationHandlerImpl.getViewId() correctly adds a message as follows in the server.log : #|2010-09-07T10:08:17.947-0700|FINE|glassfish3.1|javax.enterprise.resource.webcontainer.jsf.context|_ThreadID=19;_ThreadName=Thread-1;ClassName=com.sun.faces.context.FacesContextImpl;MethodName=addMessage;|Adding Message[sourceId=<<NONE>>,summary=Unable to find matching navigation case with from-view-id '/composite/simpleCompositeComponentUsingPage.xhtml' for action '# {hello.getNextAction} ' with outcome '/submit.xhtml')|#] But since this phase cannot come up with the right navigation rule, the render response phase continues to again build the same old view. During this buildView() call, the ComponentTagHandlerDelegateImpl creates a new CompositeComponentTagHandler instance but the "cc" object for this instance is null (the ComponentTagHandlerDelegateImpl created during Restore View phase is discarded. That one had the "cc" set). Since "cc" is null, we see the NPE. Now, the ComponentTagHandlerDelegateImpl is able to find the UINamingContainer instance for cc via findChild(). But it does not have any way of setting it in the CompositeComponentTagHandler. Hence the fix as attached. With the fix, after we hit the button, we come back to the same old view but with the error message in it. code changes already attached.
        Hide
        Mathias Werlitz added a comment -

        The fix for this issue relates to JAVASERVERFACES-1988. No new instance of CompositeComponentTagHandler will be created and will cause concurrent access to the UIComponent (Mojarra 2.1.1).

        Show
        Mathias Werlitz added a comment - The fix for this issue relates to JAVASERVERFACES-1988 . No new instance of CompositeComponentTagHandler will be created and will cause concurrent access to the UIComponent (Mojarra 2.1.1).
        Hide
        Manfred Riem added a comment -

        Closing issue out

        Show
        Manfred Riem added a comment - Closing issue out

          People

          • Assignee:
            sheetalv
            Reporter:
            dyegocarmo
          • Votes:
            1 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: