I can't say I'm having any real issues w/ 3.3.1.
Works with no problems with latest hibernate.
But be careful when you upgrade, because hibernate 3.3 introduced some new jar dependencies that you have to also put in your jboss/server/instance/lib
other than that it works great.
I have bundled 3.4 in my ear and it works fine. I have found the best solution is to bundle all the dependencies in the ear as well, and leave the app server's jars alone as much as possible, as it makes management easier
have you experienced any problems when redeploying your app to JBoss AS when your ear is packaged with Hibernate 3.4? Similar to the problem described in http://www.seamframework.org/Community/ErrorOnApplicationRedeploy and http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210223
I have packaged my ear with Hibernate Core 3.3.1.GA in '/lib' and have no problem when deploying the app to JBoss 4.2.3.GA. Unfortunately redeployment resulted in stack trace and require a server restart.
No, but from the sounds of it they are upgrading the application servers hibernate version. I am using scoped classloading and packaging a new hibernate jar (and its dependencies) into my ear.
Would you mind posting exactly how to bundle the latest hibernate into my ear? There are so many places in the ear where a lib can be placed:
What about all the different hibernate jar: core, validator, entitymanager etc?
Greatly appreciate the help.
For the benefit of anyone who lands here, the following worked for me on JBoss 4.2.3GA, Seam 2.1.0A1:
- Download the following from Hibernate Downloads: Hibernate Annotations 3.4.0 GA, Hibernate EntityManager 3.4.0GA, Hibernate Validator 3.1.0GA. You don't really need to get hibernate core 3.1.0 GA since the core jar is also part of the other downloads.
- Copy hibernate-annotations-3.4.0.GA/lib/ejb3-persistence.jar to $JBOSS_HOME/server/config/lib. This is the only app server lib you need to replace, other go into your Ear.
- Copy the following libs to your app.ear/lib: dom4j.jar, hibernate-validator.jar, hibernate-commons-annotations.jar, hibernate-core.jar, hibernate-annotations.jar, hibernate-entitymanager.jar, javassist.jar, slf4j-api.jar, slf4j-log4j12.jar
Thats about all I needed to get my Seam ear going with the new hibernate.
it is actually better to put/replace all those jars just in jbosshome/server/config/lib and not in your ear/lib
Not in my experiance, you risk breaking everything else on the app server that depends on hibernate. And I am pretty sure you could not get support for that configuration.
Also every time you deploy you have to make sure that you remember to upgrade the jars, and add in any extra dependencies. I have done it both ways and replacing the app servers jars caused nothing but trouble.
What advantages do you see in replacing the app servers jars that makes you say it is better?
I'd very interested to understand exactly which is your setup and the various descriptor.
I've tried to follow this approach in the past and I've found the following problem: on JBoss 4.2.3 I was leaving the default libs in /server/config/lib and bundle the new hibernate version in ear lib/. My persistence unit was in an ejb.jar. I was using a scoped class loader in the ear. What happened was that the ejb3 deployer that was starting the persistence unit was using the old server libs, while my ear was using the new bundled ones, and I was getting into a lot of class cast exceptions cos the versions of the classes that the container was providing were not the same my ear was expecting.
So, how did you solve this problem (if you had it), or what exactly is you setup?
Thanks a lot,
Ps: this topic (http://www.jboss.org/index.html?module=bb&op=viewtopic&t=150791) refers to this problem, and they were confirming that the hibernate lib should be deployed in the server libs
The biggest difference that I can see is that my entities are deployed in a seperate non ejb jar file, as they are shared between several ejb jars. This seperate entity jar does not depend on any ejb3 classes, so there is not really any thing in it that can class cast.
And where is the persistence unit declared or initialized? Is still managed, or are you creating it manually?
I mean, the point is if the SessionFactory is created by the container through one of the default deployers (and as such is using the container libs) or by your ear somehow with a loader correctly scoped.