Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 1.2.9-core
    • Fix Version/s: 1.2.10-core, 1.0.10-core
    • Component/s: Archetype
    • Labels:
      None
    • Environment:
      JSF RI Mojarra (1.2_08-b06-FCS), JBoss Seam 2.0.2.SP1, Facelets 1.1.14, Tomcat 6.0.14

      Description

      I'm using a facelet component which sets a variable to the row of a tr:table (<c:set var="entity" value="#

      {row}" />). This variable is then used in a child table (which is also a facelet component) as source value.
      In 1.2.9 this approach does not work anymore. The entity is set to the current row of the child table and does not contain the row entity set before.

      Up to 1.2.8, all works fine. I checked the fixes for 1.2.9, but could not find a related one.

      facelet tag code snippet:

      <ui:composition>
      <c:choose>
      <c:when test="${empty value}">
      <c:set var="source" value="${backingBean.list}" />
      </c:when>
      <c:otherwise>
      <c:set var="source" value="${entity[value]}" />
      </c:otherwise>
      </c:choose>
      <c:choose>
      <c:when test="${empty eventBinding}">
      <c:set var="binding" value="${backingBean}" />
      </c:when>
      <c:otherwise>
      <c:set var="binding" value="${eventBinding}" />
      </c:otherwise>
      </c:choose>
      <tr:table value="${source}" binding="${binding.model}" var="row">
      <c:set var="entity" value="#{row}

      " />
      <ui:insert />
      <tr:column headerText="Actions">
      <tr:panelButtonBar>
      <tr:commandLink action="#

      {backingBean.edit}

      " text="Edit" partialSubmit="true" rendered="#

      {!backingBean.editMode and backingBean.visibleOnly}

      " immediate="true" />
      <tr:commandLink action="#

      {backingBean.save}

      " text="Save" partialSubmit="true" rendered="#

      {!backingBean.visibleOnly}" />
      <tr:commandLink action="#{backingBean.cancel}" text="Cancel" partialSubmit="true" rendered="#{!backingBean.visibleOnly}

      " immediate="true">
      <tr:resetActionListener/>
      </tr:commandLink>
      </tr:panelButtonBar>
      </tr:column>
      </tr:table>
      </ui:composition>

      xhtml code snippet:

      <i:ietable panelCaption="Samples" backingBean="#

      {samples}

      " eventBinding="#

      {samplesBindings}

      ">
      <i:field label="ID" name="id" columns="6" readOnly="true"/>
      <f:facet name="detailStamp">
      <i:ietable panelCaption="Findings" value="findings" backingBean="#

      {findings}

      " eventBinding="#

      {findingsBindings}

      " parent="#

      {row}

      " nested="true">

      1. testCase.zip
        5 kB
        Mathias Walter

        Activity

        Hide
        Matthias Weßendorf added a comment -

        reverted TRINIDAD-1135

        Show
        Matthias Weßendorf added a comment - reverted TRINIDAD-1135
        Hide
        Venkata Guddanti added a comment -

        Go ahead and reverse https://issues.apache.org/jira/browse/TRINIDAD-1135. That fix is not needed right now. We need to investigate a better fix at a later time.

        Show
        Venkata Guddanti added a comment - Go ahead and reverse https://issues.apache.org/jira/browse/TRINIDAD-1135 . That fix is not needed right now. We need to investigate a better fix at a later time.
        Hide
        Matthias Weßendorf added a comment -

        When I revert the change for TRINIDAD-1135 the server-side error (PropertyNotFoundException) is gone.
        We need to investigate more here.

        Show
        Matthias Weßendorf added a comment - When I revert the change for TRINIDAD-1135 the server-side error (PropertyNotFoundException) is gone. We need to investigate more here.
        Hide
        Mathias Walter added a comment -

        The test case is not Seam dependend.

        Show
        Mathias Walter added a comment - The test case is not Seam dependend.
        Hide
        Matthias Weßendorf added a comment -

        ok, I won't test with Seam.
        Just MyFaces 1.2.x and Trinidad 1.2.x and Facelets 1.1.14

        Show
        Matthias Weßendorf added a comment - ok, I won't test with Seam. Just MyFaces 1.2.x and Trinidad 1.2.x and Facelets 1.1.14
        Hide
        Matthias Weßendorf added a comment -

        removed fix version

        Show
        Matthias Weßendorf added a comment - removed fix version
        Hide
        Mathias Walter added a comment -

        A minimal test case is provided. It does not contain the libraries.

        I tried it with the latest snapshot from 21th July 2008.

        How to reproduce:

        1. go to ../test/nested.jsf
        2. click on 'Details'
        3. click on one of the new nested 'Details' links.
        4. Now the error occurs.

        Show
        Mathias Walter added a comment - A minimal test case is provided. It does not contain the libraries. I tried it with the latest snapshot from 21th July 2008. How to reproduce: 1. go to ../test/nested.jsf 2. click on 'Details' 3. click on one of the new nested 'Details' links. 4. Now the error occurs.
        Hide
        Andrew Robinson added a comment -

        This either should be (1) not a bug, but discussed on the user mailing list until the actual bug is found and not just reporting that your code doesn't work or (2) submit a reproducible test case maven project to debug.

        #2 would probably be best. As long as the project depends on maven to build and uses only jars from central and other public repositories, it would make testing a lot more easy.

        I meant facelets 1.1.14. There have been people reporting problems with 1.1.14 and variable scoping.

        You haven't nested the components have you?

        If you have nested a table with var=row in another table with var=row, it won't work. You cannot re-use the same var in the same component tree, it has to be unique. This is because the var is stored into the request map. When an inner table would write the value, it would replace any existing value.

        You can read more here:
        http://andrewfacelets.blogspot.com/2008/06/understanding-datatable.html

        Show
        Andrew Robinson added a comment - This either should be (1) not a bug, but discussed on the user mailing list until the actual bug is found and not just reporting that your code doesn't work or (2) submit a reproducible test case maven project to debug. #2 would probably be best. As long as the project depends on maven to build and uses only jars from central and other public repositories, it would make testing a lot more easy. I meant facelets 1.1.14. There have been people reporting problems with 1.1.14 and variable scoping. You haven't nested the components have you? If you have nested a table with var=row in another table with var=row, it won't work. You cannot re-use the same var in the same component tree, it has to be unique. This is because the var is stored into the request map. When an inner table would write the value, it would replace any existing value. You can read more here: http://andrewfacelets.blogspot.com/2008/06/understanding-datatable.html
        Hide
        Mathias Walter added a comment -

        I've replaced all $

        {...} by #{...}

        . The problem still exists.

        And I removed all get references to 'row' and replaced it by 'parent'. The problem still exists.

        Here is the cleaned code snippet:

        <ui:composition>
        <c:choose>
        <c:when test="#

        {empty value}

        ">
        <c:set var="source" value="#

        {backingBean.list}

        " />
        </c:when>
        <c:otherwise>
        <c:set var="source" value="#

        {parent[value]}

        " />
        </c:otherwise>
        </c:choose>
        <c:choose>
        <c:when test="#

        {empty eventBinding}

        ">
        <c:set var="binding" value="#

        {backingBean}

        " />
        </c:when>
        <c:otherwise>
        <c:set var="binding" value="#

        {eventBinding}

        " />
        </c:otherwise>
        </c:choose>
        <tr:table value="#

        {source}

        " binding="#

        {binding.model}

        " var="row"><!--rendered="#

        {source.size() gt 0}

        "-->
        <ui:insert />
        <tr:column headerText="Aktionen">
        <tr:panelButtonBar>
        <tr:commandLink action="#

        {backingBean.edit}

        " text="Bearbeiten" partialSubmit="true" rendered="#

        {!backingBean.editMode and backingBean.visibleOnly}

        " immediate="true" />
        <tr:commandLink action="#

        {backingBean.save}

        " text="Speichern" partialSubmit="true" rendered="#

        {!backingBean.visibleOnly}" />
        <tr:commandLink action="#{backingBean.cancel}" text="Abbrechen" partialSubmit="true" rendered="#{!backingBean.visibleOnly}

        " immediate="true">
        <tr:resetActionListener/>
        </tr:commandLink>
        </tr:panelButtonBar>
        </tr:column>
        </tr:table>
        </ui:composition>

        Show
        Mathias Walter added a comment - I've replaced all $ {...} by #{...} . The problem still exists. And I removed all get references to 'row' and replaced it by 'parent'. The problem still exists. Here is the cleaned code snippet: <ui:composition> <c:choose> <c:when test="# {empty value} "> <c:set var="source" value="# {backingBean.list} " /> </c:when> <c:otherwise> <c:set var="source" value="# {parent[value]} " /> </c:otherwise> </c:choose> <c:choose> <c:when test="# {empty eventBinding} "> <c:set var="binding" value="# {backingBean} " /> </c:when> <c:otherwise> <c:set var="binding" value="# {eventBinding} " /> </c:otherwise> </c:choose> <tr:table value="# {source} " binding="# {binding.model} " var="row"><!--rendered="# {source.size() gt 0} "--> <ui:insert /> <tr:column headerText="Aktionen"> <tr:panelButtonBar> <tr:commandLink action="# {backingBean.edit} " text="Bearbeiten" partialSubmit="true" rendered="# {!backingBean.editMode and backingBean.visibleOnly} " immediate="true" /> <tr:commandLink action="# {backingBean.save} " text="Speichern" partialSubmit="true" rendered="# {!backingBean.visibleOnly}" /> <tr:commandLink action="#{backingBean.cancel}" text="Abbrechen" partialSubmit="true" rendered="#{!backingBean.visibleOnly} " immediate="true"> <tr:resetActionListener/> </tr:commandLink> </tr:panelButtonBar> </tr:column> </tr:table> </ui:composition>
        Hide
        Mathias Walter added a comment -

        As I wrote in the previous comment.

        Show
        Mathias Walter added a comment - As I wrote in the previous comment.
        Hide
        Mathias Walter added a comment - - edited

        > Facelets just translates it to #{}

        Okay, so not the reason for the problem.

        > The exception is pretty clear:
        Sure, it's pretty clear, but wrong!

        >You are trying to access entities.Finding.getFindings() which apparently does not exist.

        No! I'm trying to access entities.Sample.getFindings(), because binding is mapped to #

        {row[value]}

        = samples.findings. I'm setting the table value (=source variable) before the next nested table begins!

        I did not changed the Facelets version. I only switched to Trinidad 1.2.9 and than back to 1.2.8.
        BTW: 1.0.14 is very old. As I wrote above (see Environment), I'm using Facelets 1.1.14.

        It works for the first nested level, but not for the second. If there is a variable conflict, why does it work at the first nested level?

        There is also no way to prevent reusing the same variable with the same nested elements, if I "DRY".

        Show
        Mathias Walter added a comment - - edited > Facelets just translates it to #{} Okay, so not the reason for the problem. > The exception is pretty clear: Sure, it's pretty clear, but wrong! >You are trying to access entities.Finding.getFindings() which apparently does not exist. No! I'm trying to access entities.Sample.getFindings(), because binding is mapped to # {row[value]} = samples.findings. I'm setting the table value (=source variable) before the next nested table begins! I did not changed the Facelets version. I only switched to Trinidad 1.2.9 and than back to 1.2.8. BTW: 1.0.14 is very old. As I wrote above (see Environment), I'm using Facelets 1.1.14. It works for the first nested level, but not for the second. If there is a variable conflict, why does it work at the first nested level? There is also no way to prevent reusing the same variable with the same nested elements, if I "DRY".
        Hide
        Andrew Robinson added a comment -

        By any chance, have you recently changed you facelets version?

        I believe that the variable scoping in facelets has changed in 1.0.14.

        So if you use #

        {row} in one facelet and #{row}

        in another facelet, they could be conflicting with one another.

        Show
        Andrew Robinson added a comment - By any chance, have you recently changed you facelets version? I believe that the variable scoping in facelets has changed in 1.0.14. So if you use # {row} in one facelet and #{row} in another facelet, they could be conflicting with one another.
        Hide
        Andrew Robinson added a comment -

        This is not a bug, bug you should not use ${} in facelets, but #{}. There is no such thing as ${} in facelets, it is JSP syntax. Facelets just translates it to #{}

        The exception is pretty clear:

        Property 'findings' not found on type entities.Finding

        You are trying to access entities.Finding.getFindings() which apparently does not exist.

        It tells you that:
        value="#

        {row[value]}

        "

        row is an instance of entities.Finding and value is "finding", and the way EL works, this is trying to invoke entities.Finding.getFindings()

        Show
        Andrew Robinson added a comment - This is not a bug, bug you should not use ${} in facelets, but #{}. There is no such thing as ${} in facelets, it is JSP syntax. Facelets just translates it to #{} The exception is pretty clear: Property 'findings' not found on type entities.Finding You are trying to access entities.Finding.getFindings() which apparently does not exist. It tells you that: value="# {row[value]} " row is an instance of entities.Finding and value is "finding", and the way EL works, this is trying to invoke entities.Finding.getFindings()
        Hide
        Mathias Walter added a comment -

        And by the way: I removed '<c:set var="entity" value="#

        {row}

        " />' and replaced all $

        {entity[name]}

        with #

        {row[name]}

        for my fields.

        Hopefully that was mentioned by not using TagHandler processed EL and runtime processed EL.

        It works for 1.2.8, but not for 1.2.9.

        More precisely, I've a nested level of three. The first table is drawing correctly. If I click on a detailStamp, the next nested table is also shown correctly. So passing the value and parent attribute of i:ietable works well from first to second nested level.
        But if I now click on a detailStamp in the second nested level, the table of the third nested level is not shown. Instead an exception is thrown (see below), if I use 1.2.9.

        Ergo: From first to second nested level all works well, but not for the next deeper level. I'm sure, that's a bug.

        08.07.2008 08:53:45 com.sun.faces.lifecycle.InvokeApplicationPhase execute
        WARNUNG: /WEB-INF/facelets/tags/ienestedtable.xhtml @27,68 value="$

        {source}": /WEB-INF/facelets/tags/ienestedtable.xhtml @16,52 value="#{row[value]}": Property 'findings' not found on type entities.Finding
        javax.el.PropertyNotFoundException: /WEB-INF/facelets/tags/ienestedtable.xhtml @27,68 value="${source}

        ": /WEB-INF/facelets/tags/ienestedtable.xhtml @16,52 value="#

        {row[value]}

        ": Property 'findings' not found on type entities.Finding
        at com.sun.facelets.el.TagValueExpression.getValue(TagValueExpression.java:73)
        at org.apache.myfaces.trinidad.bean.FacesBeanImpl.getProperty(FacesBeanImpl.java:68)
        at org.apache.myfaces.trinidad.component.UIXComponentBase.getProperty(UIXComponentBase.java:1164)
        at org.apache.myfaces.trinidad.component.UIXIterator.getValue(UIXIterator.java:504)
        at org.apache.myfaces.trinidad.component.UIXCollection._flushCachedModel(UIXCollection.java:1208)
        at org.apache.myfaces.trinidad.component.UIXCollection.broadcast(UIXCollection.java:143)
        at org.apache.myfaces.trinidad.component.UIXTable.broadcast(UIXTable.java:223)
        at org.apache.myfaces.trinidad.component.UIXCollection.broadcast(UIXCollection.java:153)
        at org.apache.myfaces.trinidad.component.UIXTable.broadcast(UIXTable.java:223)
        at org.apache.myfaces.trinidad.component.UIXCollection.broadcast(UIXCollection.java:153)
        at org.apache.myfaces.trinidad.component.UIXTable.broadcast(UIXTable.java:223)
        at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:458)
        at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:763)
        at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:82)
        at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
        at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
        at javax.faces.webapp.FacesServlet.service(FacesServlet.java:265)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
        at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
        at org.jboss.seam.debug.hot.HotDeployFilter.doFilter(HotDeployFilter.java:68)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
        at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:85)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
        at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
        at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:73)
        at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._invokeDoFilter(TrinidadFilterImpl.java:238)
        at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:195)
        at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:138)
        at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
        at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
        at org.jboss.seam.debug.hot.HotDeployFilter.doFilter(HotDeployFilter.java:68)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
        at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:85)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
        at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
        at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
        at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:73)
        at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
        at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:584)
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
        at java.lang.Thread.run(Thread.java:619)

        Show
        Mathias Walter added a comment - And by the way: I removed '<c:set var="entity" value="# {row} " />' and replaced all $ {entity[name]} with # {row[name]} for my fields. Hopefully that was mentioned by not using TagHandler processed EL and runtime processed EL. It works for 1.2.8, but not for 1.2.9. More precisely, I've a nested level of three. The first table is drawing correctly. If I click on a detailStamp, the next nested table is also shown correctly. So passing the value and parent attribute of i:ietable works well from first to second nested level. But if I now click on a detailStamp in the second nested level, the table of the third nested level is not shown. Instead an exception is thrown (see below), if I use 1.2.9. Ergo: From first to second nested level all works well, but not for the next deeper level. I'm sure, that's a bug. 08.07.2008 08:53:45 com.sun.faces.lifecycle.InvokeApplicationPhase execute WARNUNG: /WEB-INF/facelets/tags/ienestedtable.xhtml @27,68 value="$ {source}": /WEB-INF/facelets/tags/ienestedtable.xhtml @16,52 value="#{row[value]}": Property 'findings' not found on type entities.Finding javax.el.PropertyNotFoundException: /WEB-INF/facelets/tags/ienestedtable.xhtml @27,68 value="${source} ": /WEB-INF/facelets/tags/ienestedtable.xhtml @16,52 value="# {row[value]} ": Property 'findings' not found on type entities.Finding at com.sun.facelets.el.TagValueExpression.getValue(TagValueExpression.java:73) at org.apache.myfaces.trinidad.bean.FacesBeanImpl.getProperty(FacesBeanImpl.java:68) at org.apache.myfaces.trinidad.component.UIXComponentBase.getProperty(UIXComponentBase.java:1164) at org.apache.myfaces.trinidad.component.UIXIterator.getValue(UIXIterator.java:504) at org.apache.myfaces.trinidad.component.UIXCollection._flushCachedModel(UIXCollection.java:1208) at org.apache.myfaces.trinidad.component.UIXCollection.broadcast(UIXCollection.java:143) at org.apache.myfaces.trinidad.component.UIXTable.broadcast(UIXTable.java:223) at org.apache.myfaces.trinidad.component.UIXCollection.broadcast(UIXCollection.java:153) at org.apache.myfaces.trinidad.component.UIXTable.broadcast(UIXTable.java:223) at org.apache.myfaces.trinidad.component.UIXCollection.broadcast(UIXCollection.java:153) at org.apache.myfaces.trinidad.component.UIXTable.broadcast(UIXTable.java:223) at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:458) at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:763) at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:82) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100) at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:265) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83) at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.debug.hot.HotDeployFilter.doFilter(HotDeployFilter.java:68) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:85) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:73) at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._invokeDoFilter(TrinidadFilterImpl.java:238) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:195) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:138) at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83) at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.debug.hot.HotDeployFilter.doFilter(HotDeployFilter.java:68) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:85) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:73) at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:584) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:619)
        Hide
        Mathias Walter added a comment -

        It works up to Trinidad 1.2.8 very well - so it's possible!

        1.2.9 breaks something, but not all. The first time the page is rendered, it works for both very well.

        After I click a 'Details' link, I get the exception regarding to a wrong property of the inner row object.

        Please explain in more detail (or point to an URL), why this should not work if it works and how to deal with this.

        Show
        Mathias Walter added a comment - It works up to Trinidad 1.2.8 very well - so it's possible! 1.2.9 breaks something, but not all. The first time the page is rendered, it works for both very well. After I click a 'Details' link, I get the exception regarding to a wrong property of the inner row object. Please explain in more detail (or point to an URL), why this should not work if it works and how to deal with this.
        Hide
        Andrew Robinson added a comment -

        You cannot combine TagHandler processed EL and runtime processed EL.

        Short explanation, never use JSTL to refer to anything that is done in JSF.

        Show
        Andrew Robinson added a comment - You cannot combine TagHandler processed EL and runtime processed EL. Short explanation, never use JSTL to refer to anything that is done in JSF.

          People

          • Assignee:
            Matthias Weßendorf
            Reporter:
            Mathias Walter
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development