Running RichFaces on WebLogic 12c

I initially thought I could write this post months back already. But I ended up being overwhelmed by different things. One among them was, that it wasn't able to simply fire up the RichFaces showcase like I did it for the 4.0 release. With all the JMS magic and the different provider checks in the showcase this has become some kind of a challenge to simply build and deploy it.
Anyway, I was willing to give this a try and here we go. If you want to get started with any of the JBoss technologies it is a good idea to check with the JBoss Developer Framework first. That is a nice collection of different examples and quickstarts to get you started on Java EE and it's technologies. One of them is the RichFaces-Validation example which demonstrates how to use JSF 2.0, RichFaces 4.2, CDI 1.0, JPA 2.0 and Bean Validation 1.0 together.

The Example

The example consists of a Member entity which has some JSR-303 (Bean Validation) constraints on it. Usually those are checked in several places, beginning with the Database, on to the persistence layer and finally the view layer in close interaction with the client. Even if this quickguide doesn't contain a persistence layer it starts with the Enity which reflects the real life situation quite good. The application contains a view layer written using JSF and RichFaces and includes an AJAX wizard for new member registration. A newly registered member needs to provide a couple of information before he is actually "registered". This includes e-mail a name and his phone number.

Getting Started
I'm not going to repeat what the excellent and detailed quickstart is already showing you. So, if you want to run this on JBoss AS7 .. go there. We're starting with a blank Maven web-project. And the best and easiest way to do this is to fire up NetBeans 7.2 and create one. Lets name it "richwls-web". Open your pom.xml and start changing some stuff there. First remove the endorsed stuff there. We don't need it. Next is to add a little bit of dependencyManagement:

<dependencyManagement>
       <dependencies>
           <dependency>
               <groupId>org.jboss.bom</groupId>
               <artifactId>jboss-javaee-6.0-with-tools</artifactId>
               <version>1.0.0.Final</version>
               <type>pom</type>
               <scope>import</scope>
           </dependency>
            
           <dependency>
               <groupId>org.richfaces</groupId>
               <artifactId>richfaces-bom</artifactId>
               <version>4.2.0.Final</version>
               <scope>import</scope>
               <type>pom</type>
           </dependency>
       </dependencies>
   </dependencyManagement>

This adds the Bill of Materials (BOM) for both Java EE 6 and RichFaces to your project. A BOM specifies the versions of a "stack" (or a collection) of artifacts. You find it with anything from the RedHat guys and it is considered "best practice" to have one. At the end this makes your life easier because it manages versions and dependencies for you.

On to the lengthy list of true dependencies:

<!-- Import the CDI API -->
        <dependency>
            <groupId>javax.enterprise</groupId>
            <artifactId>cdi-api</artifactId>
            <scope>provided</scope>
        </dependency>
         
        <!-- Import the JPA API -->
        <dependency>
            <groupId>javax.persistence</groupId>
            <artifactId>persistence-api</artifactId>
            <version>1.0.2</version>
            <scope>provided</scope>
        </dependency>
         
        <!-- JSR-303 (Bean Validation) Implementation -->
        <dependency>
            <groupId>org.hibernate</groupId>
            <artifactId>hibernate-validator</artifactId>
            <version>4.3.0.Final</version>
            <scope>provided</scope>
            <exclusions>
                <exclusion>
                    <groupId>org.slf4j</groupId>
                    <artifactId>slf4j-api</artifactId>
                </exclusion>
            </exclusions>
        </dependency>
         
        <!-- Import the JSF API -->
        <dependency>
            <groupId>javax.faces</groupId>
            <artifactId>jsf-api</artifactId>
            <version>2.1</version>
            <scope>provided</scope>
        </dependency>
         
        <!-- Import RichFaces runtime dependencies - these will be included
        as libraries in the WAR -->
        <dependency>
            <groupId>org.richfaces.ui</groupId>
            <artifactId>richfaces-components-ui</artifactId>
        </dependency>
        <dependency>
            <groupId>org.richfaces.core</groupId>
            <artifactId>richfaces-core-impl</artifactId>
        </dependency>
        

Except the RichFaces dependencies all others are provided by the runtime. In this case it will be GlassFish 3.1.2.2. In case you haven't defined it elsewhere (settings.xml) you should also add the JBoss repository to your build section: 

<repository>
                   <id>jboss-public-repository-group</id>
                   <name>JBoss Public Maven Repository Group</name>
                   <url>https://repository.jboss.org/nexus/content/groups/public-jboss/</url>
               </repository>

Copy the contents of the richfaces-validation directory of the source-zip or check it out from github. Be a little bit careful and don't mess up with the pom.xml we created ;) Build it and get that stuff deployed.

Issues
First thing you are greeted with is a nice little weld message:

WELD-000054 Producers cannot produce non-serializable instances for injection into 
non-transient fields of passivating beans [...] Producer Method [Logger] with qualifiers 

We obviously have an issue here and need to declare the Logger field as transient.

@Inject
private transient Logger logger;

Don't know why this works on AS7 but might be I find out someday :) Next iteration: Change it, build, deploy.

java.lang.NoSuchMethodError: com.google.common.collect.ImmutableSet.copyOf(Ljava/util/Collection;)
Lcom/google/common/collect/ImmutableSet;

That doesn't look better. Fire up the WLS CAT at http://localhost:7001/wls-cat/ and try to find out about it.

Seems as if Oracle is using Google magic inside the server. Ok, fine. We have no way to deploy RichFaces as a standalone war on WebLogic because we need to resolve some classloading issues here. And the recommended way is to add a so-called Filtering Classloader. You do this by adding a weblogic-application.xml to your ear. Yeah: Lets repackage everything and put the war into an empty ear and add the magic to the weblogic-application.xml:

<prefer-application-packages>
       <package-name>com.google.common.*</package-name>
   </prefer-application-packages>

Done? Another deployment and you finally see your application. Basically RichFaces run on WebLogic but you have to package it into an ear and turn the classloader around for the com.google.common.* classes. That is way easier with PrimeFaces but ... anyway, there are reasons why I tried this. One is, that I do like the idea of being able to trigger the Bean Validation on the client side. If you take a look at the example you see, that the <rich:validator event="blur" /> adds client side validation for both bean validation constraints and standard jsf validators to the client. Without having to mess around with anything in JavaScript or duplicate logic. Great! Thanks!