DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Coding
  3. Frameworks
  4. Running RichFaces on WebLogic 12c

Running RichFaces on WebLogic 12c

Markus Eisele user avatar by
Markus Eisele
·
Sep. 28, 12 · Interview
Like (0)
Save
Tweet
Share
5.25K Views

Join the DZone community and get the full member experience.

Join For Free
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! 

 

 

 

 

 

 

 

 

RichFaces Spring Framework

Published at DZone with permission of Markus Eisele, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • How To Create and Edit Excel XLSX Documents in Java
  • A Brief Overview of the Spring Cloud Framework
  • Fraud Detection With Apache Kafka, KSQL, and Apache Flink
  • How To Check Docker Images for Vulnerabilities

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: