DigitalJoel

2009/12/21

JSF 2.0.2 and Google App Engine

Filed under: facelets, GAE, java, JSF — Tags: , — digitaljoel @ 6:46 pm

I spent a couple hours today trying to get a JSF 2 based webapp up in app-engine.  Of course, it wasn’t as easy as simply following the instructions in

configuring jsf 2.0 to run on the google app engine using netbeans

I ran into the problem detailed here  ( JNDI problem in jsf 2.0 and google app engine ) right off the bat.  I tried to use his packaged jar, but app-engine kept giving me an exception that it couldn’t load the zip file. Perhaps it was corrupted when I downloaded it or something.

If you follow his link to the WebConfiguration.java file, you will see that he created a new WebConfiguration.java file within the same package as the existing one and copied the implementation, commenting out the offending code.  I decided to try a different approach. I’m sure there is nothing wrong with Josh’s approach, and if it weren’t for his blog and all the ground work he had already done in finding the offending code, I probably wouldn’t have even bothered going further with JSF 2 in app engine. In any case, here’s what I did.

I downloaded the JSF 2.0.2 source from here ( jsf 2.0.2 source ) and expanded it.  I then found the WebConfiguration.java file and decided to modify it.  Rather than comment out all the source, I added a new config enumeration value to the BooleanWebContextInitParameter enumerations as follows

// around line 1071 in the finished file, after the previously final enum value AllowTextChildren
EnableJNDI(
"com.sun.faces.enableJNDI",
true
);

Then, I check for the value of that parameter in private constructor, around line 113

        // add the isOptionEnabled call to this conditional statement
        if ( isOptionEnabled( BooleanWebContextInitParameter.EnableJNDI ) && canProcessJndiEntries()) {
            processJndiEntries(contextName);
        }

When that is done, simply compile, and you have a new jsf-api/build/lib/jsf-api.jar and jsf-ri/build/lib/jsf-impl.jar that you can use in your project. For my compile, I simply copied the build.properties.glassfish.orig to build.properties and set the jsf.build.home property to the directory in which the source was checked out.

Finally, put a new context-param in web.xml with the name com.sun.faces.enableJNDI and a value of false.

All I’ve got so far is the hello world, so we’ll see if I run into other difficulties as I use further functionality.

2009/12/14

Sharing JSF 2 Composite Components

Filed under: development, facelets, JSF — Tags: , — digitaljoel @ 4:25 pm

Let’s say you have created some awesome composite components in JSF 2 that you want to share between one webapp and another.  One option would be to simply copy all of the .xhtml files from one webapp to the other.  Yuck.  Then you have two versions of each file.  Changes in one are not reflected in the other, and what happens when you are up to 6 webapps that all want to share your awesome components?  That’s ugly.

A better solution is to jar them all up into a new component library.  Sounds complicated huh?  Not really.

Each of your composite components should be in a resources directory.  In order to redistribute those components, you simply add them to a jar under META-INF/resources, and then make sure that your META-INF directory also contains a faces-config.xml file.

The faces-config.xml file ensures that JSF scans the jars for components and annotated classes.  The following ant target, which I added to the build.xml file in a netbeans project automatically takes the resources directory, and creates an empty faces-config.xml file and plops them into a jar.  Now, you simply include that jar as a library in your new webapp.

    <target name="create-lib-jar">
        <property name="stage-dir" value="create-lib-jar-temp" />
        <property name="dist.dir" value="." />
        <property name="lib.jar" value="${dist.dir}/jsfLibrary.jar" />
        <mkdir dir="${stage-dir}" />

        <echo file="${stage-dir}/faces-config.xml" ><![CDATA[<?xml version='1.0' encoding='UTF-8'?>
<faces-config
    xmlns="http://java.sun.com/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd"
    version="2.0">
</faces-config>]]></echo>

        <jar destfile="${lib.jar}">
            <metainf dir="${stage-dir}">
                <include name="faces-config.xml" />
            </metainf>

            <metainf dir="web" includes="resources/">
            </metainf>

        </jar>

        <delete dir="create-lib-jar-temp" />

    </target>

Think of the possibilities.  Now, you have a simple project in which to build your core, re-usable composite components, all running in their own little webapp, testable with junit for the java classes and selenium for the web portions.  Then, you package them up for use in all your webapps.  That’s awesome sauce.

This build target doesn’t get any java class files.  When I get to that part of my project, I’ll update it.

Make sure to modify the properties to fit your environment so it is pulling from the correct directories and all that jazz.

<target name=”create-lib-jar”>
<property name=”stage-dir” value=”create-lib-jar-temp” />
<property name=”dist.dir” value=”.” />
<mkdir dir=”${stage-dir}” /> 

<echo file=”${stage-dir}/faces-config.xml” ><![CDATA[<?xml version=’1.0′ encoding=’UTF-8′?>
<faces-config
xmlns=”http://java.sun.com/xml/ns/javaee&#8221;
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance&#8221;
xsi:schemaLocation=”http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd&#8221;
version=”2.0″>
</faces-config>]]></echo>

<jar destfile=”${dist.dir}/jsfLibrary.jar”>
<metainf dir=”${stage-dir}”>
<include name=”faces-config.xml” />
</metainf>

<metainf dir=”web” includes=”resources/”>
</metainf>

</jar>

<delete dir=”create-lib-jar-temp” />

</target>

Create a free website or blog at WordPress.com.