Sunday, June 6, 2010

JBoss and RichFaces: jsf libs and errors

Definitely: just following manual is just not enough. So we waste our working days on stuff like this...

Recently I started working on JBoss/RichFaces platform for a new application. I was following the instructions from RichFaces website, and added the jars they said were necessary. It worked well on Tomcat, but it didnt go that wel on JBoss. It resulted in exceptions like this:

ConfigurationException: CONFIGURATION FAILED! null at com.sun.faces.config.

with a long stack trace, of course... Stack trace didn't point to any configuration error, just this null pointer exception. So, after some Google-ing, I saw that it is a common problem, some are lucky to get a few pointers from stack trace, but some just get this null and are stuck. Fortunately, a few guys pointed out that the problem might be with the jfs libraries.

So, what really happens is that libraries that I have put in WEB-INF/lib folder conflict with JBoss JSF libraries already present on server. Libraries in question are jsf-api, jsf-impl and jsf-facelets jars. Problems might arise from the fact that versions of user provided and server provided libraries are not the same, or that interfaces of some required libraries are not appropriate for some other in combination.

So, my first step was to replace those jars with the one present in JBoss server libs (simple search through jars in JBoss with TotalCommander gives you location of libs, packed in JBoss war-s or some similar archive ). It didn't quite work. Obviously, if i deploy app war with the same libraries, the problem remains.

So, I then removed the jsf libs from web-inf/lib. It worked to a point where I started using jsf functions in my code (like FacesContext.getCurrentInstace()....) , where I needed jsf jars in project. But I don't want tohose jars in my war. So, what to do?

Solution is quite simple. Instead of placing jars yourself, you just add JBoss Server LIbrary to your project's build path in Eclipse. (Properties->Configure Build Path...). Your project has all required dependencies for development, and deployed app has the same enviroment like during deployment. You can check through libraries to see if there are any other unnecessary duplicates.


1 comment:

  1. Had similar issues converting to Maven. In general, although it is a lot of work, I think it is easier to add libraries one at a time and resolve ClassNotFoundExceptions than it is to add them all in and try and resolve unusual runtime behaviour.