javaserverfaces
  1. javaserverfaces
  2. JAVASERVERFACES-3146

absolute contract reference (e.g. template="/contracts/base/template.xhtml") fails if the target contract is packaged with a jar

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.2.5
    • Fix Version/s: 2.2.6
    • Component/s: resources
    • Labels:
      None

      Description

      It is possible to reference a template from within a known contract with absolute reference like ...

      (template.xhtml in custom contract - extends template.xhtml of the base contract)
      <ui:composition template="/contracts/base/template.xhtml">
       ..
      </ui:composition>
      

      ... if the target contract is packaged as part of the web application (within the WAR).
      But it fails when the target contract is packaged as a JAR.

      Since the absolute contract resource reference is supported for war-based target contracts it must also be supported for jar-based target contracts. This allows to extend/customize base contracts without the need to copy all base contract resources to the extended/customized contract. The notation of activating contracts like "custom,base" e.g. in the contracts configuration in faces-config.xml also indicates that such combined contracts are to be supported.

      I was able to make such absolute contracts references working with some little changes. But first it must be decided if such absolute contracts references should work by design or must be prevented.

        Issue Links

          Activity

          Hide
          Ed Burns added a comment -

          The initial design of the feature doesn't intend for contracts to be referenced in this way. Rather the intent is that they should be discovered and applied by the runtime without having to be named explicitly.

          I'll ask Frank Caputo, who lead the design of this feature, to comment on this issue.

          Show
          Ed Burns added a comment - The initial design of the feature doesn't intend for contracts to be referenced in this way. Rather the intent is that they should be discovered and applied by the runtime without having to be named explicitly. I'll ask Frank Caputo, who lead the design of this feature, to comment on this issue.
          Hide
          Manfred Riem added a comment -

          Hanspeter can you have a look at https://java.net/projects/glassfish-samples/sources/svn/show/trunk/ws/javaee7/jsf/stylelayoutrlc?rev=1208 and tell me if this does what you are trying to do? Thanks!

          Show
          Manfred Riem added a comment - Hanspeter can you have a look at https://java.net/projects/glassfish-samples/sources/svn/show/trunk/ws/javaee7/jsf/stylelayoutrlc?rev=1208 and tell me if this does what you are trying to do? Thanks!
          Hide
          Frank Caputo added a comment -

          Hi Hanspeter,

          we discussed, what you want, but didn't spec it. See the last section of https://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2012-11/message/44

          Actually you can't combine contracts this way. Using the "custom,base" syntax first looks in the contract "custom" for resources (e.g. facelets), if it doesn't find them there, it looks in "base" as described in section 2.6.1.4 of the spec PDF on page 80.

          You could circumvent this limitation by using different names for the templates.

          • call the template you want to include in the contract base templateBase.xhtml
          • template.xhtml of contract base will include templateBase.xhtml
          • template.xhtml of contract custom will also include templateBase.xhtml and does other funny things.

          Also Manfred's sample should give a good idea on how to combine contracts.

          Show
          Frank Caputo added a comment - Hi Hanspeter, we discussed, what you want, but didn't spec it. See the last section of https://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2012-11/message/44 Actually you can't combine contracts this way. Using the "custom,base" syntax first looks in the contract "custom" for resources (e.g. facelets), if it doesn't find them there, it looks in "base" as described in section 2.6.1.4 of the spec PDF on page 80. You could circumvent this limitation by using different names for the templates. call the template you want to include in the contract base templateBase.xhtml template.xhtml of contract base will include templateBase.xhtml template.xhtml of contract custom will also include templateBase.xhtml and does other funny things. Also Manfred's sample should give a good idea on how to combine contracts.
          Hide
          Manfred Riem added a comment -

          Hanspeter,

          Can we go ahead and close this one as "Works as Designed". And have you file a spec issue for possible inclusion of what this issue is about in 2.3?

          Show
          Manfred Riem added a comment - Hanspeter, Can we go ahead and close this one as "Works as Designed". And have you file a spec issue for possible inclusion of what this issue is about in 2.3?
          Hide
          Hanspeter Duennenberger added a comment -

          Hi Franco and Manfred.

          I agree works as designed. And with separation and naming of the templates (as Franco also suggested) it is possible to get the result I wanted.

          However, I'm not sure whether we should close this issue. Because the current implementation results in an inconsistent behavior. Such absolute references into /contracts_dir/contract_name/resource.xhtml does work as long as the referenced contract is part of the web-application and stops working when moving the contract out to a separate jar.

          Therefore this issue shall be used to track the required change in mojarra while we probably also need a spec-issue to clarify that such absolute references must be impossible also with contracts deployed as part of the web-application.
          Or will the spec issue be enough for tracking?

          regards
          Hanspeter

          Show
          Hanspeter Duennenberger added a comment - Hi Franco and Manfred. I agree works as designed. And with separation and naming of the templates (as Franco also suggested) it is possible to get the result I wanted. However, I'm not sure whether we should close this issue. Because the current implementation results in an inconsistent behavior. Such absolute references into /contracts_dir/contract_name/resource.xhtml does work as long as the referenced contract is part of the web-application and stops working when moving the contract out to a separate jar. Therefore this issue shall be used to track the required change in mojarra while we probably also need a spec-issue to clarify that such absolute references must be impossible also with contracts deployed as part of the web-application. Or will the spec issue be enough for tracking? regards Hanspeter
          Hide
          Ed Burns added a comment -

          Hello Hanspeter,

          Are you suggesting we add code to detect an absolute reference and log a sensible error, perhaps in the page if ProjectStage is Development?

          Manfred, is it possible to detect an absolute reference and flag the error?

          Ed

          Show
          Ed Burns added a comment - Hello Hanspeter, Are you suggesting we add code to detect an absolute reference and log a sensible error, perhaps in the page if ProjectStage is Development? Manfred, is it possible to detect an absolute reference and flag the error? Ed
          Hide
          Manfred Riem added a comment -

          Yes, I think so. I think Hanspeter is wanting it to be disallowed, so something more than just logging an error?

          Show
          Manfred Riem added a comment - Yes, I think so. I think Hanspeter is wanting it to be disallowed, so something more than just logging an error?
          Hide
          Hanspeter Duennenberger added a comment -

          Hi Ed and Manfred.

          Yes I think JSF must react the same as if one would try to address a resource with absolute path like e.g.

           
           <h:outputStylesheet name="/resources/css/styles.css" /> 
          

          instead of using properly

           <h:outputStylesheet name="/css/styles.css" />
           or 
           <h:outputStylesheet library="css" name="styles.css" />  
          

          Using above absolute resource reference JSF is not able to deliver the resource from "webapp-root/resources_dir/css/styles.css" and logs the not-found resource.

          The same behavior must be provided for absolute "/contracts_dir/contract_name/resource.id" references I think: not resolving the reference and in dev-mode logging the incident.

          Best regards
          Hanspeter

          Show
          Hanspeter Duennenberger added a comment - Hi Ed and Manfred. Yes I think JSF must react the same as if one would try to address a resource with absolute path like e.g. <h:outputStylesheet name= "/resources/css/styles.css" /> instead of using properly <h:outputStylesheet name= "/css/styles.css" /> or <h:outputStylesheet library= "css" name= "styles.css" /> Using above absolute resource reference JSF is not able to deliver the resource from "webapp-root/resources_dir/css/styles.css" and logs the not-found resource. The same behavior must be provided for absolute "/contracts_dir/contract_name/resource.id" references I think: not resolving the reference and in dev-mode logging the incident. Best regards Hanspeter
          Hide
          Manfred Riem added a comment -

          Applied to 2.2 branch,

          svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES-3146, when someone tries to use a direct contract reference throw an exception explaining that direct contract references are not allowed."
          Sending jsf-ri/src/main/java/com/sun/faces/facelets/tag/ui/CompositionHandler.java
          Adding test/agnostic/facelets/ui/src/main/webapp/compositionDirectContract.xhtml
          Adding test/agnostic/facelets/ui/src/test/java/com/sun/faces/test/agnostic/facelets/ui/Issue3146IT.java
          Transmitting file data ...
          Committed revision 12822.

          Show
          Manfred Riem added a comment - Applied to 2.2 branch, svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES-3146 , when someone tries to use a direct contract reference throw an exception explaining that direct contract references are not allowed." Sending jsf-ri/src/main/java/com/sun/faces/facelets/tag/ui/CompositionHandler.java Adding test/agnostic/facelets/ui/src/main/webapp/compositionDirectContract.xhtml Adding test/agnostic/facelets/ui/src/test/java/com/sun/faces/test/agnostic/facelets/ui/Issue3146IT.java Transmitting file data ... Committed revision 12822.

            People

            • Assignee:
              Manfred Riem
              Reporter:
              Hanspeter Duennenberger
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: