Monday, January 26, 2009

Classloading in Application Servers: JARmaggedon!

original issue with trying to access the tomcat security principal in IMGWS, but since class was loaded from a sibling classloader, not a direct parent was unable to cast the object to the correct class to access it, even though debugging revealed it to be the correct object. Problem: class loaded from an unavailable classloader, so unable to use any methods or fields related to the class, have to break in through reflection.

current issue: upgrading JBoss 4.0.4 to JBoss 4.2.3, except that we use spring hibernate, and JBoss tries to be helpful by providing those jars as well, thanks JBoss, now I get
java.lang.ClassCastException: cannot be cast to org.hibernate.event.PostInsertEventListener

Solution? remove hibernate jars from jboss server/default/lib. this works ok in dev, but will probably break advanced jboss functionality which relies on those jars, lucky I don't use it... :-)

Our deployment scenario is amenable to not having spring/hibernate etc jars provided by app server, instead provided by each applications WAR. for us this works as we have one app per app server, but as more come online this may change. On the other hand, each application providing all it's own dependencies may cause some duplication of libraries and cost disk space, but this is a cheap price to pay for applications to evolve at their own rates and not be constrained by server dependencies, eg - I need a feature in hibernate 3.3.0, but in prod we only have 3.2.2. No thanks!
Personal opinion is that applications should be as self-contained as possible to simplify deployment and dependency management (leave that to maven). the exception to that is infrastructure explicitly provided by the app server, eg servlets, ejb3 persistence maybe, JDBC drivers definitely. Big fat WAR is Not A Problem, compared to Jarmeggadon...

1 comment:

Anonymous said...

Hello and thanks for the answer ! Useful for a new enginneer googleing all day for solutions.