[fleXive] Developer Blog

Even though it did not take as long as expected, it was a bumpy road to get [fleXive] to run on WebLogic 10.3.

All Application Servers are equal and follow the Java EE specification … yeah, right

Ok, lets start with pure EJB3 connectivity and leave JSF 1.2 for later: The very first thing I stumbled upon when I tried to deploy [fleXive] was some strange and misleading message about WebLogic being unable to set the transaction attribute to a bean method signature. My first thought was that there was a problem in the way we use remote and local Interfaces: The @Remote Interface contains the method signature and the @Local Interface is just derived from the @Remote one without having to declare the signatures again. The Bean itself implements both the @Local and @Remote Interface.

After some trial and (only) errors – like adding signatures to the @Local Interfaces as well and removing @Local Interfaces at all – it turned out that WebLogic chokes on (although public) inner classes passed as Bean parameters!

Some refactorings later (which had to break the API by moving those inner classes to outer ones – the reason why WebLogic support is exclusive to the upcoming version 3.1 of [fleXive] and won’t be backported to the 3.0 branch) [fleXive] still didn’t deploy:
The reason was a rather old commons-lang version bundled with WebLogic that is visible to the applications ClassLoader which lead to ClassCastException’s.
To work around this, the EAR has to contain a custom WebLogic deployment descriptor (weblogic-application.xml) to override classloading behaviour:

<?xml version='1.0' encoding='UTF-8'?>
<weblogic-application>
    <library-ref>
        <library-name>jsf</library-name>
        <specification-version>1.2</specification-version>
        <implementation-version>1.2</implementation-version>
        <exact-match>false</exact-match>
    </library-ref>
    <prefer-application-packages>
        <package-name>org.apache.*</package-name>
    </prefer-application-packages>
</weblogic-application>

The library-ref tag in above file is needed to prevent patching the javax.jsf_1.2.0.0.jar with META-INF/services entries as described here. Now everything deployed fine …

Or so I thought … dependency injection using @Resource and @EJB worked, but manual JNDI lookups for the database connections and beans (needed by some core engines, scripts and on the web layer) failed. Two things had to be added: mappedName to the @Stateless Annotation in the enterprise beans and a lookup strategy using simpleName#complexName (e.g. ContentEngine#com.flexive.ejb.beans.ContentEngine).
MySQL DataSource lookups worked without any problems, but Supports Global Transactions had to be disabled. Without mappedName Annotation values WebLogic would create a binding involving the name of the deployed EAR which is unknown to the application. The downside is that beans can only be deployed once on a server.

EJB issues were solved and the application started without any further problems. Now came the hardest part: getting JSF 1.2 to work …
The good news is that WebLogic does support JSF, else it would not be certified. JSF 1.2 support is required by the Java EE 5 specification for the web container – the specification states that it must be provided by the container but unfortunately not how! – see table EE.6-1 in the Java EE 5 platform specification about required Java Optional Packages.
WebLogic provides different JSF implementations (Sun RI 1.2 dating back to 2007, Sun RI 1.1.1, MyFaces 1.1.1 and MyFaces 1.1.3) which have to be deployed as library. A good intention to give developers a choice but with the implication that the deployed library is only partially visible to the web application. I got a good hint from the JBoss Seam reference documentation:

For some reason, even with the steps above classes in the jsf-api.jar are not found during application deployment. The only way for this to work is to put the javax.jsf_1.2.0.0.jar (the jsf-api.jar) from jsf-1.2.war in the domains shared library. This requires a restart of the server.

In addition to the javax.jsf_1.2.0.0.jar I had to add glassfish.jsf_1.2.3.2.jar to the lib directory as well to get it to work.
So far no changes had to be made to the web applications deployment descriptor, but now JSF could still not be started. The remaining issue was to include a configuration listener for the RI in the web.xml deployment descriptor:

<listener>
    <listener-class>com.sun.faces.config.ConfigureListener</listener-class>
</listener>

Being forced to use this descriptor makes the web application incompatible with MyFaces! Therefor it is commented out by default and has to be enabled in [fleXive] if deployed on WebSphere …

A step by step instruction how to deploy [fleXive] can be found in the [fleXive] wiki.