Thoughts about modularizing deegree’s JSF components

In order to conquer complexity in modern systems, modularization is key. deegree 3 uses Maven modules to break the codebase into manageable pieces. However, deegree’s service administration console is still a single Maven module that includes JSF beans and facelets for all administration tasks (defining JDBC connections, style definition, feature store creation wizard, service configuration, etc.). Only some core JSF functionality (including a few tags) is separated into module deegree-jsf-core.

It would be quite helpful, if also beans and facelets for specific functionality (say: the SQL feature store configuration wizard) could be separated into independent JARs. After searching the web a bit, I stumbled upon a very simple and easy solution for that. It basically involves two steps:

  • Ensure that the JAR is considered for scanning for JSF annotated classes (as it’s already done with deegree-jsf-core). JSF’s behavior for finding JSF beans is documented in section 11.4.2 of the JSF 2.0 specification. The most common and straightforward way is to place a file named META-INF/faces-config.xml or a file matching META-INF/*.faces-config.xml into the JAR.
  • Implement and register an extension of ResourceResolver which considers the classpath for retrieving facelets.

Writing a custom ResourceResolver is simple. The implementation below uses /META-INF/deegree/jsf as the common location for facelets inside the JAR.

package org.deegree.console;

import [...]

public class JARFaceletsResolver extends ResourceResolver {

    private static final String JSF_BASE_PATH = "/META-INF/deegree/jsf";

    private final ResourceResolver parent;

    public JARFaceletsResolver( ResourceResolver parent ) {
        this.parent = parent;
    }

    @Override
    public URL resolveUrl( String path ) {

        URL url = parent.resolveUrl( path );

        // not found in webapp -> resolve on classpath
        if ( url == null ) {
            url = JARFaceletsResolver.class.getResource(  JSF_BASE_PATH + path );
        }
        return url;
    }
}

The only thing left to do is tell JSF to use the JARFaceletsResolver for locating requested facelets. This can be done by adding the following to a (already JSF-enabled web.xml):

<web-app xmlns="http://java.sun.com/xml/ns/j2ee" [...]>
[...]
  <context-param>
      <param-name>javax.faces.FACELETS_RESOURCE_RESOLVER</param-name>
      <param-value>org.deegree.console.JARFaceletsResolver</param-value>
  </context-param>
[...]
</web-app>

That was pretty easy 🙂 This could be the option to effectively modularize deegree’s JSF codebase into JARs as well.

Advertisements

About Markus Schneider

Geospatial software developer, CEO of Occam Labs
This entry was posted in Uncategorized. Bookmark the permalink.

One Response to Thoughts about modularizing deegree’s JSF components

  1. Pingback: More thoughts about modularizing deegree’s JSF components | Simple Features

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s