8 Replies Latest reply: Jun 5, 2012 2:29 PM by Andrey Zhemoytuk RSS

Resource handling in RF 4.2

Josh Schneider Newbie

Thanks for this informative blog post (http://rik-ansikter.blogspot.com/2012/02/re-routing-jsf-resource-requests-with.html), and I'm glad resource optimization and loading are separated now. I'm also trying to get real control over resource loading using a customized version of this proposed workaround: https://community.jboss.org/wiki/WorkaroundForLOADNONEResourceLoadingStrategyInRichFaces41#comment-8974.

 

However, I'm pretty much all confused about what previous mapping strategies still apply and how this all is supposed to work. I'll try to break down what options (context params) I've seen discussed. Whatever here is deprecated, would be good to know. And actual scenarios, with all needed configs, would be a great help.

 

  1. Generic resource mapping enabled: "org.richfaces.resourceMapping.enabled", value "true") - seems this may now be deprecated/unnecessary, but not sure.
  2. Generic (dynamic resource override?) resource mapping properties file: "org.richfaces.resourceMapping.mappingFile", pointing to properties file location - suggested path of "/META-INF/richfaces/custom-mapping.properties" [or "custom-mappings.properties" - plural], but should it now point to the file "static-resource-mappings.properties"?)
  3. Generic (dynamic resource override?) resource mapping location: Root of where resources are located - with a suggested path of "#{facesContext.externalContext.requestContextPath}/resources/#{resourceLocation}" - the root location of your local resource libraries, like js, css, etc.
  4. Static resource mapping properties file: "org.richfaces.staticResourceLocation.mappingFile", pointing to properties file location - suggested path of "/META-INF/richfaces/static-resource-mappings.properties". Seems this may or may not be necessary if a file called "static-resource-mappings.properties" is anywhere in your classpath, or is it deprecated altogether?
  5. Static resource mapping location: "org.richfaces.staticResourceLocation", with a suggested path of maybe just "#{resourceLocation}", eg, for CDN. Is this even necessary anymore or is it deprecated? See https://community.jboss.org/message/591640#591640

 

It might also be helpful for me to clear up whether "static" here means a static location or static loading, or both, and whether mapping -- using any strategy -- a default, dynamically loaded resource to a static location turns it into a static resource (ie, it will be loaded regardless of what components happen to be in the page).

 

Finally, although mapping and optimization have now been split apart, I'm still wondering whether it will be effective in RF during deployment, when packing and compression s/b enabled. Because, for example, packed.js (which is already built in the jar) contains a full version of jquery.js, so if I'm pointing jquery.js to a CDN in my mapping file, won't the CDN script file collide with the version in packed.js in a deployment environment? Can this strategy only work if packing is disabled, or if I make a custom packed-patched.js, with jquery.js removed?

 

Hope any of this makes sense. Thanks.

  • 1. Re: Resource handling in RF 4.2
    Lukáš Fryč Master

    1) Generic resource mapping enabled: "org.richfaces.resourceMapping.enabled", value "true") - seems this may now be deprecated/unnecessary, but not sure.

     

    Yes, it is deprecated, resource mapping is now enabled by adding resource mapping configuration file to classpath.

     

    But there is another switch for enabling Resource Optimization (which is now separated from Resource Mapping).

     

     

    2) Generic (dynamic resource override?) resource mapping properties file: "org.richfaces.resourceMapping.mappingFile", pointing to properties file location - suggested path of "/META-INF/richfaces/custom-mapping.properties" [or "custom-mappings.properties" - plural], but should it now point to the file "static-resource-mappings.properties"?)

    As documentation says, Resource Mapping is activated just by adding the default configuration file META-INF/richfaces/static-resource-mappings.properties.

     

    You may register additional files, for details read the doc.

     

     

    3) Generic (dynamic resource override?) resource mapping location: Root of where resources are located - with a suggested path of "#{facesContext.externalContext.requestContextPath}/resources/#{resourceLocation}" - the root location of your local resource libraries, like js, css, etc.

    Is not needed anymore in 4.2, the sensible default was provided in order to serve both features Resource Mapping and Resource Optimization.

     

     

    4) Static resource mapping properties file: "org.richfaces.staticResourceLocation.mappingFile", pointing to properties file location - suggested path of "/META-INF/richfaces/static-resource-mappings.properties". Seems this may or may not be necessary if a file called "static-resource-mappings.properties" is anywhere in your classpath, or is it deprecated altogether?

     

    As answered in (2), you have two options: configure own mapping file with context-param (more in the docs) or just use the default one (when provided in classpath, it will be used).

     

     

    5) Static resource mapping location: "org.richfaces.staticResourceLocation", with a suggested path of maybe just "#{resourceLocation}", eg, for CDN. Is this even necessary anymore or is it deprecated? See https://community.jboss.org/message/591640#591640

    This access has been refactored to current form: use Resource Mapping feature, the CDN example can be found in  Resource Mapping feature docs.

     

     

      It might also be helpful for me to clear up whether "static" here means a static location or static loading, or both, and whether mapping -- using any strategy -- a default, dynamically loaded resource to a static location turns it into a static resource (ie, it will be loaded regardless of what components happen to be in the page).

       

      RichFaces Resource Mapping is dealing just with locations, so static means "static configuration of resource location".

       

      Additionally, static may mean "statically generated RichFaces resources", which are packaged and compressed (alias RichFaces Resource Optimization).

       

       

      Finally, although mapping and optimization have now been split apart, I'm still wondering whether it will be effective in RF during deployment, when packing and compression s/b enabled. Because, for example, packed.js (which is already built in the jar) contains a full version of jquery.js, so if I'm pointing jquery.js to a CDN in my mapping file, won't the CDN script file collide with the version in packed.js in a deployment environment? Can this strategy only work if packing is disabled, or if I make a custom packed-patched.js, with jquery.js removed?

      In RichFaces 4.2, jquery.js is completely separated from packed.js, so you can point it to CDN how it is documented (refer to answer to (5)).

    1. 2. Re: Resource handling in RF 4.2
      Josh Schneider Newbie

      Thanks, Lukáš

       

      I responded to your reply to my other, similar post. I truly appreciate your detailed responses, and think I'm clear on everything now. I'm not sure whether everything's working as expected (particularly with the default static mappings properties file), but will test again once I update from CR1 to Final.

       

      Your explanation of "static" resources is also very helpful. I'm understanding that it entirely depends on the particular project's needs as to whether one can successfully use built-in RF resource optimization, since there is no "real-time" or dynamic resource compression and packing. Essentially, if I really need to customize resource mapping, I may have to rely on using a maven plugin, like the one RichFaces has, for compile-time optimization, which is fine.

       

      A note that might be useful to others. This Servelt filter has been working really well for me, to deliver compressed files over HTTP request: http://sourceforge.net/projects/pjl-comp-filter/. I still have to customize my configuration, and maybe configure server-side caching of already-compressed resources, but this is working for me right out of the box.

       

      Regards,

       

      Josh

    2. 3. Re: Resource handling in RF 4.2
      Josh Schneider Newbie

      OK, now that I'm trying things out with 4.2.0.Final, here's what I'm seeing.

       

      Using the static-resource-mappings.properties file (without any location param) does "work," so to say, but I end up with paths like this:

       

      /myapp/org.richfaces.resources/javax.faces.resource/primefaces/jquery/jquery.js

       

      /myapp/org.richfaces.resources/javax.faces.resource/js/richfaces/a4j.js (a file I created with just a4j scripts concatenated)

       

      These paths don't exist.

       

      The path root seems to come from the initial setup of the servlet:

       

      <servlet>

          <servlet-name>Resource Servlet</servlet-name>

          <servlet-class>org.richfaces.webapp.ResourceServlet</servlet-class>

          <load-on-startup>1</load-on-startup>

      </servlet>

      <servlet-mapping>

          <servlet-name>Resource Servlet</servlet-name>

          <url-pattern>/org.richfaces.resources/*</url-pattern>

      </servlet-mapping>

       

      I think if I were to change the Resource Servlet url-pattern to /faces/*, at least some of the mappings would work, like so:

      /myapp/faces/javax.faces.resource/js/richfaces/a4j.js

       

      That's a valid path. But I don't think that would work for pointing to another library's resources (like the PrimeFaces jquery.js)

       

      Am I misunderstanding something? Thanks.

    3. 4. Re: Resource handling in RF 4.2
      Lukáš Fryč Master

      Josh,

       

      When having ResourceServlet mapped to /org.richfaces.resources/*,

       

      then /myapp/org.richfaces.resources/javax.faces.resource/ is resource root,

       

      and /myapp/org.richfaces.resources/javax.faces.resource/js/richfaces/a4j.js.

       

      This seems totally right, so I would look for issue on another place.

       

      Where you have placed your a4j.js in your directory structure?

      What is the link generated when you do <h:outputScript name="js/richfaces/a4j.js" />?

    4. 5. Re: Resource handling in RF 4.2
      Josh Schneider Newbie

      OK, so for all of my local resources, they are placed in "library" folders underneath the "resources" folder of my app's WebContent, as per JSF 2.0 spec.

       

      If I call, for example <h:outputScript name="js/richfaces/a4j.js" target="head"/> or <h:outputScript library="js" name="richfaces/a4j.js" target="head"/> it loads correctly, since a4j.js is loated in the path /resources/js/richfaces/a4j.js.

       

      EDIT: However, it tries to load twice, once with the path that doesn't exist and once with the correct path (or what looks like once from the mapping file and once from the h:outputScript call).

       

      When I was using custom mapping, defining the mapping location (the old way), and just plopping an a4j tag in the page, the file was loaded correctly, and then, using mappings like org.richfaces\:status.js=a4j.js also worked, and by pointing all a4j-specific scripts to that same local resource, I avoided duplicate loading.

       

      I'm basically just trying to figure out why that's not the same behavior for the default mapping.

    5. 6. Re: Resource handling in RF 4.2
      Josh Schneider Newbie

      This is a total kludge, but it essentially works. In my static-resource-mappings.properties file:

      primefaces\:jquery/jquery.js=../faces/javax.faces.resources/jquery/jquery.js?ln=primefaces (this is the primefaces version of jquery.js + some jquery-ui.js)

      org.richfaces\:jquery-ui-core.js=../faces/javax.faces.resources/jquery/jquery.js?ln=primefaces

      jquery.js=../faces/javax.faces.resources/jquery/jquery.js?ln=primefaces (the original is the richfaces version of jquery.js, now pointing to the primefaces version)

      The resulting path looks like

      src="myapp/resources/../faces/javax.faces.resources/jquery/jquery.js?ln=primefaces"

      And because it's the same path for all three calls, there are no duplicate calls. If I remove the re-mapping of the primefaces jquery.js (which is technically unnecessary), for example, that leads to the script being loaded twice in different places, which causes ordering problems.

       

      I'm just playing around with this for now. The working solution for me is to keep all mapped files either local or pointing to a full URL (like a CDN). Trying to add mapping from one library's resources to another's (except as above) just doesn't seem to work correctly.

    6. 7. Re: Resource handling in RF 4.2
      Lu Han Newbie

      Useful discussion for me to configure the resource handling.

      additional remarks for fresh:

      rf4.1 configuration:
      org.richfaces.resourceMapping.enabled
      org.richfaces.resourceMapping.compressedStages

      org.richfaces.resourceMapping.packedStages

       

      rf4.2 configuration:

      org.richfaces.resourceOptimization.enabled

      org.richfaces.resourceOptimization.compressionStages

      org.richfaces.resourceMapping.packedStages

       

      In rf4.2, the configration of rf4.1 can be used, but they are deprecated.

      The first parameter is a triggler for openning optimization.

      The second is used to config the stage Compressing, the default value is production and system test (Production,SystemTest).

      The last is used to config the stage for Packaging resources, the default value is all.

       

      for instance:

      <context-param>

          <param-name>org.richfaces.resourceOptimization.compressionStages</param-name>

          <param-value>All</param-value>

      </context-param>

    7. 8. Re: Resource handling in RF 4.2
      Andrey Zhemoytuk Newbie

      Lu,

      Small correction. In RichFaces 4.2 it is"org.richfaces.resourceOptimization.packagingStages" not "org.richfaces.resourceMapping.packedStages".

      Summarizing:

      RichFaces 4.1 configuration:
      org.richfaces.resourceMapping.enabled
      org.richfaces.resourceMapping.compressedStages

      org.richfaces.resourceMapping.packedStages

       

      RichFaces 4.2 configuration:

      org.richfaces.resourceOptimization.enabled

      org.richfaces.resourceOptimization.compressionStages

      org.richfaces.resourceOptimization.packagingStages