How to Create a Modular Jsf 2.0 Application

How to create a modular JSF 2.0 application?

I understand that your question basically boils down to How can I include Facelets views in a JAR?

You can do this by placing a custom ResourceResolver in the JAR.

public class FaceletsResourceResolver extends ResourceResolver {

    private ResourceResolver parent;
    private String basePath;

    public FaceletsResourceResolver(ResourceResolver parent) {
        this.parent = parent;
        this.basePath = "/META-INF/resources"; // TODO: Make configureable?
    }

    @Override
    public URL resolveUrl(String path) {
        URL url = parent.resolveUrl(path); // Resolves from WAR.

        if (url == null) {
            url = getClass().getResource(basePath + path); // Resolves from JAR.
        }

        return url;
    }

}

Configure this in webapp's web.xml as follows:

<context-param>
    <param-name>javax.faces.FACELETS_RESOURCE_RESOLVER</param-name>
    <param-value>com.example.FaceletsResourceResolver</param-value>
</context-param>

Imagine that you've a /META-INF/resources/foo/bar.xhtml in random.jar, then you can just include it the usual way

<ui:include src="/foo/bar.xhtml" />

or even dynamically

<ui:include src="#{bean.path}" />

Note: since Servlet 3.0 and newer JBoss/JSF 2.0 versions, the whole ResourceResolver approach is not necessary if you keep the files in /META-INF/resources folder. The above ResourceResolver is only mandatory in Servlet 2.5 or older JBoss/JSF versions because they've bugs in META-INF resource resolving.

Locating Javascript and other resources in modular JSF 2.2.x application

I'll ignore the fact that the mentioned versions in your question in its current form is confusing. JSF 2.2 (as you tagged) requires a minimum of Servlet 3.0. Tomcat 6 (as you mentioned) is a Servlet 2.5 container (and a quite old one either). This is not going to work together. Also noted should be that the FaceletsResourceResolver which you found there is only necessary when you're using Servlet 2.5 or are using a very early JBoss AS 6 version.

The library name does here not represent the JAR file name, but the subfolder where all of those resources commonly belong to. So when you have a

<h:outputScript library="modulename" name="foo/bar.js" />

then the following structure is expected in the JAR:

/META-INF/resources/modulename
/META-INF/resources/modulename/foo
/META-INF/resources/modulename/foo/bar.xhtml
/META-INF/resources/modulename/foo/bar.js

Alternatively, you can keep your original structure and use

<h:outputScript library="foo" name="bar.js" />

depending on the meaning of the actual value of foo.

How to modularize a JSF/Facelets/Spring application with OSGi?

What you're aiming to do sounds doable, with a few caveats:

The View Layer: First, your view layer sounds a little overstuffed. There are other ways to modularize JSF components by using custom components that will avoid the headaches involved with trying to create something as dramatic as late-binding managed beans.

The Modules Themselves: Second, your modules don't seem particularly modular. Your first bullet-list makes it sound as if you're trying to create interoperable web apps, rather than modules per se. My idea of a module is that each component has a well-defined, and more or less discrete, purpose. Like how ex underlies vi. If you're going down the OSGi route, then we should define modular like this: Modular, for the sake of this discussion, means that components are hot-swappable -- that is, they can be added and removed without breaking the app.

Dependencies: I'm a little concerned by your description of the modules as "possibly depending on each other." You probably (I hope) already know this, but your dependencies ought to form a directed acyclic graph. Once you introduce a circular dependency, you're asking for a world of hurt in terms of the app's eventual maintainability. One of the biggest weaknesses of OSGi is that it doesn't prevent circular dependencies, so it's up to you to enforce this. Otherwise your dependencies will grow like kudzu and gradually choke the rest of your system's ecosystem.

Servlets: Fuhgeddaboudit. You can't late-bind servlets into a web app, not until the Servlet 3.0 spec is in production (as Pascal pointed out). To launch a separate utility servlet, you'll need to put it into its own app.

OK, so much for the caveats. Let's think about how this might work:

You've defined your own JSF module to do... what, exactly? Let's give it a defined, fairly trivial purpose: a login screen. So you create your login screen, late-bind it using OSGi into your app and... then what? How does the app know the login functionality is there, if you haven't defined it in your .jspx page? How does the app know to navigate to something it can't know is there?

There are ways to get around this using conditional includes and the like (e.g., <c:if #{loginBean.notEmpty}>), but, like you said, things get a little hairy when your managed loginBean exists in another module that may not have even been introduced to the app yet. In fact, you'll get a servlet exception unless that loginBean exists. So what do you do?

You define an API in one of your modules. All the managed beans that you intend to share between modules must be specified as interfaces in this API layer. And all your modules must have default implementations of any of these interfaces that they intend to use. And this API must be shared between all interoperable modules. Then you can use OSGi and Spring to wire together the specified beans with their implementation.

I need to take a moment to point out that this is not how I would approach this problem. Not at all. Given something like as simple as a login page, or even as complicated as a stock chart, I'd personally prefer to create a custom JSF component. But if the requirement is "I want my managed beans to be modular (i.e., hot-swappable, etc)," this is the only way I know to make it work. And I'm not even entirely sure it will work. This email exchange suggests that it's a problem that JSF developers have only just started to work on.

I normally consider managed beans to be part of the view layer, and as such I use them only for view logic, and delegate everything else to the service layer. Making managed beans late-binding is, to my mind, promoting them out of the view layer and into the business logic. There's a reason why all those tutorials are so focused on services: because most of the time you want to consider what it would take for your app to run "headless," and how easy it would be to "skin" your view if, for instance, you wanted it to run, with all its functionality, on an Android phone.

But it sounds like a lot of what you're working with is itself view logic -- for instance, the need to swap in a different view template. OSGi/Spring should be able to help, but you'll need something in your app to choose between available implementations: pretty much what OSGi's Service Registry was built to do.

That leaves static resources. You can modularize these, but remember, you'll need to define an interface to retrieve these resources, and you'll need to provide a default implementation so your app doesn't choke if they're absent. If i18n is a consideration, this could be a good way to go. If you wanted to be really adventurous, then you could push your static resources into JNDI. That would make them completely hot-swappable, and save you the pain of trying to resolve which implementation to use programmatically, but there are some downsides: any failed lookup will cause your app to throw a NamingException. And it's overkill. JNDI is normally used in web apps for app configuration.

As for your remaining questions:

Am I inventing a bicycle here? Are there standard solutions for that?

You are, a little. I've seen apps that do this kind of thing, but you seem to have stumbled into a fairly unique set of requirements.

Do you think OSGi is the right technology for the described task?

If you need the modules to be hot-swappable, then your choices are OSGi and the lighter-weight ServiceLocator interface.

Is my sketch of OSGI application more or less correct?

I can't really tell without knowing more about where your component boundaries are. At the moment, it sounds like you may be pushing OSGi to do more than it is capable of doing.

But don't take my word for it. I found other reading material in these places.

And since you ask about Spring Slices, this should be enough to get you started. You'll need a Git client, and it looks like you'll be training yourself on the app by looking through the source code. And it's very early prototype code.

JSF facelets template packaging

Facelets compositions (so, just plain *.xhtml pages, templates and include files) are resolved by ExternalContext#getResource() which delegates to ServletContext#getResource(). This requires a Servlet 3.x compatible container because /WEB-INF/lib/*.jar!/META-INF/resources resolving from is new since Servlet 3.0. If you aren't on Servlet 3.x yet, or want to put those JARs on a different location for some reason, then you'd need to create a custom ResourceResolver. See also How to create a modular JSF 2.0 application?

Facelets composite components and static resources (so, <cc:xxx> components and CSS/JS/image resources which are to be loaded by <h:outputStylesheet>, <h:outputScript> and <h:graphicImage>) are resolved from the classpath by ClassLoader#getResource(). To include the JAR file in the classpath scan of JSF, you'd need to include a JSF 2.x compatible faces-config.xml file in the /META-INF folder of the JAR file. The same story applies to @ManagedBean, @FacesValidator, @FacesConverter, @FacesComponent and other JSF artifacts.

When developing in Eclipse, you can choose Web > Web Fragment Project to create such a module project. It is not much different from a normal Java project, expect that it will implicitly include JavaScript facet and a targeted runtime, autocreate a /META-INF/web-fragment.xml file and get associated with an existing Dynamic Web Project by adding itself as a deployment assembly to that project.

You can also use an existing standard Java project with the right folder structure prepared. The /META-INF folder has to go in Java source folder. The web-fragment.xml file is by the way optional. You just have to manually add the Java project to the Deployment Assembly section of the main web project properties. Do not add it as another project in project's Build Path section.

When you're (manually) building a JAR file out of it, you need to make sure that the directory entries are added to the JAR, otherwise Facelets compositions can't be resolved. If you're building by build tools like Eclipse/Ant/Maven/etc, this has also to be taken into account. If this is not controllable, a custom ResourceResolver is the most reliable approach.

How to use more than one JSF form

This answer helped me a lot. And also there were some referance problem. After correcting them, I can see all the form structure.

I know the code above is not nested form structure, but for other people who are curious about this issue, you cannot make nested forms in HTML5 (for both <h:form> and <form>). So be careful to your template.

Good luck!

How to Create a Modular Jsf 2.0 Application