January 19th, 2011 by Lincoln Baxter III

How-to: Modular Java EE Applications with CDI and PrettyFaces

I was recently asked the question, “Is it possible to create a modular JSF application, where JAR-files act as plug-ins and allow xhtml views, images, css, navigation rules, and managed beans to be added as modules to the application?” The answer to this question is, “of course,” but there is no pre-set way of accomplishing such a task, so you’ll have to be a little creative. I’ve come up with a conceptual architecture that “would work,” if properly implemented, but keep in mind that this is just something I threw together in a few minutes of thinking about the problem.

What we need to accomplish our goal

0. Generate a barebones Java EE web-application.
Each module must have the ability to:
  1. Package .xhtml views, CSS, JavaScript, and images
  2. Bundle and register Managed Beans
  3. Add navigation rules
  4. (Bonus) Add bookmark-able URLs for each module
  5. Include Unit & Integration tests
Firstly, most new technologies in the Java EE ecosystem support configuration of resources in JAR-files simply by adding a descriptor in “jar:/META-INF/[web.xml, faces-config.xml, beans.xml]” and so on. This means that all you need to do to bundle artifacts from the various specifications (JPA, JSF, EJB, CDI, and so on) is place a descriptor in the right spot; your artifacts will be discovered and included in the larger application. (For more details on these descriptors, see this post.) To run your application with the least amount of effort, you should use a full Java EE Application Server such as JBoss Application Server 6.0 (download,) since it comes pre-configured with JSF and all necessary Java EE modules for this architecture.

Getting started quickly with a Java EE 6 / JSF web-application

First, we’ll need a project with which to experiment, so to create a simple web-application that we can use as the basis for our concept, we can use Seam Forge: a next generation project generation and enhancement tool from JBoss. With Forge you can have a web-application built in, literally, two command-line commands.
  1. Install and run Forge
  2. $ new-project –named {projectname} –topLevelPackage {com.yourpackage}
  3. $ scaffold setup
  4. $ build

1. Package .xhtml views, CSS, JavaScript, and images

Now that we have a simple web-application running with JSF, let’s look at the first problem. How do we get JSF .xhtml files bundled in a JAR file? If we are using JSF 1.2, this article about packaging Facelets in a JAR file will come in handy, but if using JSF 2, then the hard part is already done for us – it’s already supported! All files in jar:/META-INF/resources/* will automatically be made available to JSF as if they were in the /webapp/resources folder. We can even put Facelets (.xhtml files) themselves in the jar:/META-INF/ folder, and they will be accessible as if they were in the main web-application itself.

2. Detect and register Managed Beans

This part is simple. As mentioned in the same article, simply create an empty jar:/META-INF/beans.xml. This will denote your archive as a “beans archive”, causing all beans in your JAR to be accessible to the CDI BeanManager / your application.

3. Add navigation rules

This part is also simple. JSF allows for the faces-config.xml file to be split into parts and automatically integrated/merged from multiple JAR files. This means all you need to do is create a jar:/META-INF/faces-config.xml file, which contains your navigation (and other) rules, and you’ll see those configurations picked up by the application.

4. (Bonus) Add bookmark-able URLs for each module

This is the coolest part (in my opinion.) Not only can you add new JSF pages to your application, you can also ensure that those pages are accessible via bookmark-able URLs. This is done using PrettyFaces, an open-source URL-rewrite filter tool created by OCPSoft and community. First, you should know that PrettyFaces was initially designed for JSF, but now functions within a pure servlet or Java EE environmenet – you no longer need JSF JAR files on your classpath. Second, you should know that like JSF, PrettyFaces allows for modular configuration, so all you need to do to add new URL-mappings to your application for each JAR is to create a jar:/META-INF/pretty-config.xml file which contains your new URL-mappings:
<pretty-config xmlns="http://ocpsoft.com/prettyfaces/3.2.0" 
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
               xsi:schemaLocation="http://ocpsoft.com/prettyfaces/3.2.0
                                   		http://ocpsoft.com/xml/ns/prettyfaces/ocpsoft-pretty-faces-3.2.0.xsd">
 
   <!-- Begin UrlMappings 
      // These are examples of URL mappings, and should be customized for your application.
 
      <url-mapping id="home"> 
          <pattern value="/summary/" /> 
          <view-id>/faces/module/summary.jsf</view-id>
      </url-mapping> 
 
      <url-mapping id="store"> 
          <pattern value="/detail/" /> 
          <view-id>/faces/module/detail.jsf</view-id>
      </url-mapping> 
 
   -->
 
</pretty-config>
Notice that the view-id defined in each URL-mapping is the location of your Facelet file in the META-INF folder contained within your module’s JAR file. This is about as simple as it gets. For an extra kick, if you wanted to create a self-updating menu with links to your new modules (a navigation area,) all you would need to do in your application is call:
PrettyContext.getCurrentInstance(request).getConfig().getMappings();
This will provide you a list of all URL-mappings in the application, at which point you can decide on a naming-standard which would enable you to identify individual modules that should be included in the navigation area, and create links accordingly.

5. Include Unit & Integration tests

For this topic, all I can really say is that Arquillian, by JBoss is your new best friend – this integration-testing framework brings full-scale web and Java EE testing to your fingertips, and it’s almost as simple as writing a JUnit test; in fact, your tests will be written in JUnit. For an example of a working Arquillian Web-application test, you can inspect the PrettyFaces JSF2-testing project, which uses all of the concepts you would need to apply (Take a look at the PrettyContextTest, in which case you would do something similar, but replace PrettyFaces with your JAR module in the MavenArtifactResolver.)

Conclusion

I hope this is enough to stimulate some thought. I have not been able to actually put this together myself, but in concept at least, there is nothing to stop one from creating a system like the one I have described. I’m sure there would be a few kinks, but this is what the power of Java EE has enabled us to do. A fully modular web-application with very little actual configuration. Just put files in the right place, and you’re good to go. I’d be very interested to hear how people do, if anyone decides to give this a try. Please post your experiences below!
Lincoln Baxter, III

About the author:

Lincoln Baxter, III is a Principal Software Engineer at Red Hat, working on JBoss open-source projects; most notably as creator & project lead of JBoss Forge, and author of Errai UI. This blog represents his personal thoughts and perspectives, not necessarily those of his employer.

He is a founder of OCPsoft, the author of PrettyFaces and Rewrite, the leading URL-rewriting extensions for Servlet, Java EE, and Java web frameworks; he is also the author of PrettyTime, social-style date and timestamp formatting for Java. When he is not swimming, running, or playing Ultimate Frisbee, Lincoln is focused on promoting open-source software and making web-applications more accessible for small businesses, individuals.

Posted in JSF, JSF2, PrettyFaces

80 Comments

  1. Ulisses C says:

    Great article! I was looking for something like this.

  2. José Freitas says:

    Nice article, I was wondering, though, if is there a way to keep the resources from conflicting with each other, I mean, if I use jquery on two of my 10 modules (with possibility to have different versions) for example.

    1. Yeah – put JQuery in the main WAR file. Then just use the resource location of that jquery.js file in all of your plugins. JSF will not add duplicate includes to the same resource if you use the

      <h:outputScript> and <h:outputStylesheet>

      tags.

  3. [...] css, navigation rules, and managed means to be added as modules to the application?” The… [full post] Lincoln Baxter III OcpSoft jsfjsf2prettyfaces 0 0 0 0 [...]

  4. Papapetrou Patroklos says:

    Very interesting article.
    I have tried to follow the instructions with a simple maven project in jboss 6 but although I have added the jar in web app dependencies and added some resources files under jar:/META-INF/resources and some .xhtml files under jar:/META-INF web application seams that cannot find them

    1. You need to make sure that you are accessing them through FacesServlet, otherwise they won’t be found.

      1. Papapetrou Patroklos says:

        Yes! It Works!!
        My question is now whether I can place my jars outside war file ( for example in default\lib or even in \default\deploy )

      2. What was the URL with which you needed to access the resources in jar:META-INF/???

  5. Carlos Ortiz says:

    Hi Lincoln,

    I followed all your instructions and it worked fine using jee 5.

    Thansk for your article!

    Now, i’m working in a self-updating menu logic. It will be great, having something like a “tag” attribute in the url-mapping element.

    1. Awesome :) What about mappingId? Thats already there.

  6. Julien says:

    Hi, very interesting post. Exactly what I was looking for, thank you.
    I’m testing it with a simple web project and including a simple jar with a xhtml page. But I get a com.sun.faces.context.FacesFileNotFoundException when trying to access the xhtml page in the bundled jar…
    Is there something special to configure in the web app so that it can “discover” the bundled jar files ?
    If you have any clue, or need more details…

    1. Rick says:

      Any luck in figuring this out?

    2. Bundled XHTML files must be in the /META-INF/resources/ directory of the JAR file, if I am not mistaken. Those JARs, I believe, also need a faces-config.xml file in order to tell Faces to look for resources.

      1. Rick says:

        Cool — that did it. I was going by the statement “We can even put Facelets ( .xhtml files) themselves in the jar:/META-INF/ folder, and they will be accessible as if they were in the main web-application itself.” from above. That doesn’t seem to work.

        Thanks a ton!

      2. You did need faces-config.xml? Just to clarify…

      3. Julien says:

        Sorry I didn’t give feedback on my previous message. I got it working, but had to put the xhtml files in the jar:/META-INF/resources folder although in the tutorial is written “We can even put Facelets ( .xhtml files) themselves in the jar:/META-INF/ folder”. Everything is working great.

  7. Rick says:

    So this module is just a jar correct? And it’s packaged into the WAR’s WEB-INF/lib? Let’s say I have an xhtml page called test.xhtml at mod1/META-INF/test.xhtml, and mod1 is included with my WAR called modapp.

    What’s the URL to access test.xhtml?

    1. It depends on your FacesServlet mapping, but it should be either:

      /faces/test.xhtml
      -or-
      /test.jsf

      ~Lincoln

      1. Sonali says:

        Hi Lincoln,
        I am trying to do the same – refer resources from a jar which my jsf app depends on.
        Now, in my case, those are OSGi bundles and my css file is in {jarfile}\META-INF\resources\com\test\abc.css
        My jar as got a faces_config inside meta-inf.

        I have a requirement of externalization and during this I will have to share the http URLs to the program which hits back the URLs to get the css.
        I tried putting the jar into the web-inf/lib, as well as required-bundle dependency but I am not sure what should be the http URL for that (if any) to access that resource externally.
        I am trying something like:
        http:\\localhost:8080\{context_root_of_jsf_app}\resources\com\test\abc.css

        And getting a 404 :(
        Can you please help me out with the http URL thing?

        Thanks for help.
        Sonali

      2. Sorry Sonali,

        I’m not very familiar with OSGI, but perhaps another reader would be able to help? Anyone know?

        ~Lincoln

    2. kshitij says:

      Hello rick.

      I am working on project with jsf2.0.

      i want to access xhtml page(static content) from jar file. i can access html page but i cant access xhtml page.

      META-INF/resources/k7.html this page i can access. but META-INF/resources/jk1.xhtml i cant access.

      from this article i learn i have to put faces-config file. but what will be content of faces-config.xml file.

      please help me.

      1. dhrubo says:

        You need to put your xhtml view files under META-INF not under META-INF/resources.
        If you want to use image or css resources you can put them under META-INF/resources/css or META-INF/resources/image.
        I am using JSF 2.1.2 api and impl i.e Mojarra. It works fine
        My XHTML are located as –
        //src/main/resources/META-INF/myhelloworld.xhtml

        I am using Maven 3

      2. kshitij says:

        thanks dhrubo for reply.

        would you please tell me what will be the url pettern to access that xhtml page.

        because i am accessing html page using fillowing url.

        kshitij.

      3. kshitij says:
        <h:outputLink 
        value="#{resource['kcv1:images/k7.html']}"        title="Faq_Option1">				<h:outputText value="Content"/>
        </h:outputLink><br/>
      4. dhrubo says:

        I do not use that kind of url pattern. I use

        <h:outputLink
        value="k7.xhtml"        title="Faq_Option1">               <h:outputText value="Content"/>
        </h:outputLink><br/>

        I use resources only for css and images

      5. kshitij says:

        its is not working. Should i have to put faces-config.xml file in jar file.?

      6. dhrubo says:

        No why on earth you will need faces config unless you have to configure a factor or bean or messages bundle.
        What is yr start URL?
        lets lay you have something like this
        http://localhost:8080/myapp/view/xyz.jsf
        Then if you want to package the xhtml in jar you should have a folder – META-INF/view/xyz.xhtml

      7. kshitij says:

        My jar Structure is META-INF/jk1.xhtml. and i am accessing this url.
        https://localhost/HeWebEV/jk1.jsf
        https://localhost/HeWebEV/jk1.xhtml
        https://localhost/HeWebEV/faces/jk1.xhtml. and it is giving me error.

        jk1.xhtml is something like this.

        <?xml version="1.0" encoding="iso-8859-1"?>
         <!DOCTYPE html 
           PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
           "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
         <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
           <head>
             <title>
               Wikibooksbbbbbbbbbbbbbb
             </title>
           </head>
           <body>
        
             <p>
               <h1>Wikibooks is a great website.</h1>
             </p>
           </body>
         </html>
      8. kshitij says:

        It is Giving me following error.

        14:35:04,626 ERROR [[Faces Servlet]] Servlet.service() for servlet Faces Servlet threw exception
        com.sun.faces.context.FacesFileNotFoundException: /jk1.xhtml Not Found in ExternalContext as a Resource
        at com.sun.faces.facelets.impl.DefaultFaceletFactory.resolveURL(DefaultFaceletFactory.java:232)
        at com.sun.faces.facelets.impl.DefaultFaceletFactory.resolveURL(DefaultFaceletFactory.java:273)
        at com.sun.faces.facelets.impl.DefaultFaceletFactory.getMetadataFacelet(DefaultFaceletFactory.java:209)
        at com.sun.faces.application.view.ViewMetadataImpl.createMetadataView(ViewMetadataImpl.java:114)
        at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:233)
        at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
        at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116)
        at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
        at javax.faces.webapp.FacesServlet.service(FacesServlet.java:409)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
        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:235)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
        at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
        at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
        at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
        at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
        at java.lang.Thread.run(Thread.java:619)

      9. dhrubo says:

        JSF 2 version pls

      10. kshitij says:
        <dependency>
        			<groupId>com.sun.faces</groupId>
        			<artifactId>jsf-api</artifactId>
        			<version>2.1.1-b04</version>
        		</dependency>
        		<dependency>
        			<groupId>com.sun.faces</groupId>
        			<artifactId>jsf-impl</artifactId>
        			<version>2.1.1-b04</version>
        		</dependency>
      11. dhrubo says:

        Check your build if the xhtml are in META-INF/*.xhtml

      12. kshitij says:

        No it is not there. in HeWebEV/META-INT/ one maven folder and MANIFEST.fm file.

      13. kshitij says:

        But jk1.xhtml File I Can See in my WEB-INF/lib/myjar.jar on war.

  8. Rick says:

    Howdy all. I wrote an article this week on the topic of modularizing jsf2 apps with jar modules and cdi. Check it out — I hope it helps.

    http://community.jboss.org/wiki/ModularWebAppsWithJSF2

    Rick

  9. Mulder says:

    Hi Lincoln Brd,

    thanks for all the great stuff you knock out, especially prettyfaces helped us a lot for our last project!

    I am actually doing something like this right now. I have been tasked with a new application (foundation) and did all the jar/jsf/xhtml loading thing. I just discovered your article while i was getting the maven archtype to put prettyfaces in :)

    nice coincident, seems like a popular topic right now (modularising JSF apps).

    anyway, I came up with a variation of your approach.
    * Jars/plugins are self contained.
    * They are outside of the application in a (watched) plugin directory
    * There is a plugin engine which loads the jars
    * each jar has its own spring context, the XmlWebApplicationContext is always parent – means every plugin has access to parent/main spring context)
    * i had to create an event system though to propagate events between plugins so that, e.g. the catalogue plugin can add items to the shopping basket. (another alternative would involve coupling of plugins but i did not fancy that)
    * only the main web application uses faces and prettyfaces
    * a jsf resource resolver lets jsf find resources in plugins (only needed if jars itself are not in web-inf/lib)
    *each plugin has a navigation-controller/config of some sort. a user has to provide URLs for pages of plugins. e.g. imagine a CataloguePlugin. it has two views, a category view and a product view. in order for it to generate proper links to navigate between these two, it needs to know on which URls these two views are accesible. – I can see a problem here with your approach; jsf apps usually use templates which again include stand alone components. when you directly access xhtml files in jars, you have to hard code those template references in the jar, and also hard wire the URLs used to acces the jar resources. (or maybe you could elaborate how you would realize this to me :) ). I do it the other way round. My web app has templates/ simple xhtmls which then include plugin resources, e.g.:

     

    let me know what you think, i can send you some code if you want to have a closer look.

    Cheers,
    Daniel

  10. Mulder says:

    … i used the pre tag, but its all gone :(

    		
    			
    		
    	 
    			
    		
    			
    		
    
    1. Shoot, sorry about that. It’s been eating people’s XML recently. We need to figure out why :/

      Regarding referencing templates, you do not need to specify a URL path to a JAR, you can simple use the jar:/META-INF/resources/ directory, and it will expose those resources just like they were in the WebContent/resources/ directory of your main application.

  11. Mulder says:

    how would you do the navigation? i.e. a xhtml resource packed in a jar is “final”. If the resource is a ui:composition (an include) and the jar is a plugin to render&control a web-product-catalogue, how does the include know how to render links from one page to another (category to product). I use some sort of navigation controller in the plugins which replaces virtual pages with real URls.

    I use an ExternalContextWrapper to resolve xhtml files and can use:
    ‘”ui:include src=”/catalogue/catalogue.xhtml”/’

    might even work for jsf1.2, dunno if it supports FACELETS_RESOURCE_RESOLVER.

    1. Jamila says:

      I want to do the same stuff but you say that you are using an ExternalContextWrapper, did it work well??

      1. Mulder says:

        yes, working well, the app is live. can’t remember if you really need the external context wrapper with JSF2 (or was that the resource resolver?), but thats how it works for us on tomcat and webshere.

      2. Jamila says:

        I have a jar with a template … this template has to be used in the ui:composition of another jar , so when I put and it doesn’t work …and I use jsf 2.0 … I will try it

    2. Jamila says:

      where did you put your externalContextWrapper and resourceResolver? on the war of the jar containing the template?

      because I create them and it’s still not working (http://blogs.steeplesoft.com/2010/05/putting-facelets-in-a-jar/)

      thanks in advance

      1. Mulder says:

        can’t paste XML here so have to descrive it.

        in faces-config, i have put a factory tag with external-context-factory. My external context factory overwrites getExternalContext which then gets the wrapper:

            @Override
            public ExternalContext getExternalContext(Object context, Object request, Object response) throws FacesException {
                return new PluginContextWrapper(getWrapped().getExternalContext(context, request, response));
            }

        faces.xml:

         
            	x.y.z.PluginVariableResolver
            	x.y.z.PluginELResolver    	
         
         
         
                x.y.z.PluginContextWrapperFactory

        in web.xml i have the resourceResolver configured using a context-param tag

        web.xml:

         
        		javax.faces.FACELETS_RESOURCE_RESOLVER
        		x.y.z.PluginContextResourceResolver
      2. Mulder says:

        mmhh, stripped all the xml tags, i tried the pre tag with lang=xml?

      3. Jamila says:

        Thanks a lot for the answer … between the answer an now I found a solution for the externalContext, and my template is correctly loaded

        I’m still working on the resources resolver. I put it on the jar but I have an error with jboss and web-template, and when I put the javax.faces.FACELETS_RESOURCE_RESOLVER
        x.y.z.PluginContextResourceResolver inside the web.xml he doesn’t find the class.

        I miss something in the faces.xml???

        I’m working on, thanks a lot for your help!

      4. dhrubo says:

        Can you please put together the code on a blog entry? I am anxiously trying this.
        Also which web container are you using? I am on Tomcat 7.

      5. Hi guys. I’ve been following your discussion and realized that posting XML was broken. I’ve fixed this, you can now use the following codes for any language:

        <div class='snippit'><pre lang='' class='prettyprint'>... your xml or code here...
  12. Thierry says:

    Good Evening everybody,

    I try to get an xhtml from a jar to use it in another xhtml like :

    <ui:include src=”template-in-a-jar.xhtml” >
    </ui:include>

    is it possible?

      1. Thierry says:

        Yes, it works if I call an xhtml from an xhtml in the same jar. But if I call an xhtml (ex : test.xhtml) from an other xhtml (index.xhtml) located in an external jar, it works only if I go to http://localhost:8080/faces/test.xhtml first.
        If I try to access http://localhost:8080/faces/index.xhtml directly I obtain : java.io.FileNotFoundException:/Applications/glassfish3/glassfish/domains/domain1/generated/jsp/website-war/loader_75033/META-INF/resources/test.xhtml.

        It seems that the jar that contains test.xhtml need to be unzipped but it is unzipped only if i access to http://localhost:8080/faces/test.xhtml. Maybe it occurs only in glassfish server. I can build my war by unzipping all faces resources first but if somebody knows a better alternative solution …

        And if I try to call an xhtml in a jar from an xhtml located in the root directory of the webapp it doesn’t work.

        Have you the same result with your configuration.

      2. Mulder says:

        @Thierry
        It works for us on Websphere and Tomcat servers. We have xhtml files in the webroot which include xhtml fragments/compositions stored in jar files (plugins). The jar don’t get extracted. Is your resource resolver configured and finding your resources in the jars?

      3. Thierry says:

        prettyfaces didn’t work with my glassfish versio so I have updated glassfish from 3.1 to 3.1.1 b10 and now only the access to a xhtml located in a jar from a xhtml located in the root directory doesn’t. Thank you prettyfaces to solve my problem :-).

      4. @Thierry How are you trying to access the xhtml file? did you prefix it with /resources/yourfile.xhtml ? I believe /resources is required.

  13. Thierry says:

    no, i don’t, i’ll try.
    Thank you.

  14. [...] have dramatically increased its popularity among Java developers. When I read for the first time this article, I believed that finally I have found a standard solution for modular web applications.  Although [...]

  15. DHRUBO says:

    Serving XHTML files from jar only works after extension – custom resource resolver, external context and factory. I have tried this on both Tomcat 6 and Tomcat 7. However if I use template then the problem starts. Here is the snippet

     

    It looks for this layout in the same jar as the included xhtml fragments and fails. Any ideas on how this can be solved. BTW I am using primefaces 3.0.M3 with JSF-API+IMPL 2.1.2

    1. dhrubo says:

      I was wrong.
      I had not placed the files in jar in the correct location. It works.
      However the template does not work. The bad work around is you have to copy them in each jar.

  16. DHRUBO says:

    Here is the snippet
    xmlns:p=”http://primefaces.prime.com.tr/ui”
    template=”layout/basiclayout2.xhtml”

  17. dhrubo says:

    I also checked this does not work on JBOSS 6. If you use facelet template, it will have the same problem as I faced above.

    1. You don’t need to use custom resolvers in JSF2. As long as you have placed your files in the /META-INF/resources/xxx.xhtml, JSF should be able to find them. This is the whole point about the new resource handling features in JSF. If this isn’t working, it’s a bug in the JSF implementation version.

      1. dhrubo says:

        I use Mojarra 2.1.2. If you think thats buggy then please let me know which version to use?

  18. DHRUBO says:

    You see the problem is there is a layout which is causing the problem. Files are never served from META-INF/…..
    I use primefaces 3.0.M3 with JSF-API+IMPL 2.1.2
    Can you please tell me which version you are using. It will be helpful if you can post together a post with the right version may be with a maven pom to see.

    BTW it works in JBOSS 6. But not when you ue the template
    xmlns:p=”http://primefaces.prime.com.tr/ui”
    template=”layout/basiclayout2.xhtml”

  19. dhrubo says:

    Surprise surprise no is talking about template
    xmlns:p=”http://primefaces.prime.com.tr/ui”
    template=”layout/basiclayout2.xhtml”

    Please tell me if you are using template like this and still managing to get things working

    1. Mulder says:

      we use templates but don’t have them in the jars because they are the variables between applications. plugins only contain xhtml includes, e.g. a shopping basket or a product catalogue renderer.

  20. Jamila says:

    My folder css and img is not correctly read from the xhtml when it’s coming from an outside jar

    for example, I have put:

    and the logo is not found, the same with the css.

    Jamila

  21. kshitij says:

    I Want To Access xhtml File From Jar. I can Access html file using this url.

    <h:outputLink value="#{resource['kcv1:images/k7.html']}" title="Faq_Option1">
    				<h:outputText value="HTML CONTENT"/>
    			</h:outputLink><br/>

    but i cant access xhtml file just like html page. my jar stucture is jar:/META-INF/resources/k7.html.

    1. That’s likely because you need to access the .xhtml files through the faces servlet. E.g: For a servlet mapping of “*.jsf”, you would access your page via “images/k7.jsf”, and you should probably use not in this case.

      1. kshitij says:

        Means I Have to Put faces-config.xml file in jar?

      2. kshitij says:

        I can not use h:link because it is giving me error like navigation Rule is not found.

  22. dhrubo says:

    Why on earth you need to access gif file using .jsf?

  23. Ashish says:

    I am working with jsf 2.0 project. i want to access xhtml file from jar file. in jar file i putted three files first.html, second.xhtml, h1.jpg. i can access jpg and html file from jar using following url.

    <h:graphicImage url="#{resource['h1.jpg']}"/> 
    <h:outputLink value="#{resource['first.html']}">
               <h:outputText value="OutputLink"/>
    </h:outputLink>

    but i cant access xhtml from jar using following urls.

    <h:outputLink value="#{resource['second.xhtml']}">
               <h:outputText value="OutputLink"/>
    </h:outputLink>
    
    <h:outputLink value="#{resource['second.jsf']}">
               <h:outputText value="OutputLink"/>
    </h:outputLink>

    it is giving source not found error.

    my jar structure is jar:META-INF/resources

    1. Resource expressions should only be used for images and other non html. Your jsf pages should be accessed like they were in the core app war itself. If h li nj k is giving you no such navigation case, then your files may be in the wrong place, or you may be using an invalid outcome expression.

      1. Ashish says:

        Also I tried

        <h:link outcome="second.xhtml" value="Xhtmlcontent"/>

        it is not working. i also putted xhtml files in
        jar: META-INF/. and still it is not working.

      2. Did you remember to put faces-config.xml in your JAR? “META-INF/faces-config.xml” if not, it will not be picked up and activated by the JSF resource system.

      3. Ashish says:

        I have to faces-config.xml files. one is in my WEB-INF folder and other one is in my jar folder. when i see faces-config.xml as GUI it is not displaying content of jar faces-config file. means faces-config.xml in jar is not attaching with my main faces-config.xml file. how to attache it ?

  24. Ashish says:

    I have to faces-config.xml files. one is in my WEB-INF folder and other one is in my jar folder. when i see faces-config.xml as GUI it is not displaying content of jar faces-config file. means faces-config.xml in jar is not attaching with my main faces-config.xml file. how to attache it ?

  25. Mehdi Heidarzadeh says:

    Any one who can upload a simple working sample will be appreciated.

    Thanks

Leave a Comment




Please note: In order to submit code or special characters, wrap it in

[code lang="xml"][/code]
(for your language) - or your tags will be eaten.

Please note: Comment moderation is enabled and may delay your comment from appearing. There is no need to resubmit your comment.