We are deploying our hibernate domain classes and .hbm.xml files as a .sar file into the jboss deploy directory, and using an MBean to manage it.

The problem we are having is that occasionally on a hot deploy (dropping the .sar into the deploy directory while jboss is running), we get an exception something like "No persister found for class ..." Is there something that we should be doing in our code, or a trick to get around this problem?

Here are some setup details...

Using JBoss 3.2.1_tomcat-4.1.24 and hibernate-2.0.3
.hbm.xml files are generated with middlegen-r3
.java files are generated with hbm2java ant task

The .sar file is as follows:
hibernate\com\company\project\domain\MappedClass1.hbm.xml
hibernate\com\company\project\domain\MappedClass1.hbm.xml
meta-inf\application.xml
meta-inf\jboss-service.xml
Manifest.mf

Here is the MBean:


Thanks for any insight that anyone can provide!

-Kat

The trick you should do is yell at Gavin to get off his ass and finish the brand-new Hibernate MBean which includes a JBoss deployer.


(Well, or you could ask me to email you what I've done and you can get it finished and working....)

So this is a known bug and is in the fix state? That would go a long way towards satisfying TPTB around here...

Thanks!!
-Kat

ummm we know that we need to change the way classes are loaded. I'm not so sure about your particular problem.

what is TPTB?

TPTB = The Powers That Be... in other words, management.

So this is basically a classloader problem, then. We thought that it might be something like that... that Hibernate is not letting go of something when it un-deploys, and on redeployment we get some sort of clash between what is left in memory and what is in the new .sar.

Thanks again!
-Kat

It certainly sounds like that. "no persister for..." is often a classloading issue.


Also, I'm not an expert on JBoss classloading, but with this unified-class-loader stuff, it could be possible that a class gets loaded by someone else first? maybe? I'm not sure.

Try asking Adrian Brock or someone on the JBoss forums they would have some more insight into this.

Hot deploy works as follows:
You must always cycle all deployable units that depend on eachother
By depend, I mean, if they uses eachother's classes.

Otherwise if you have an component loaded that is not hot-deployed but is referencing a class from a hot-deployed component, it will still use the old version.

I don't know what is happening within Hibernate for "no persister found..." so I really can't say if this is what is happening.

Bill

The "no persister found" is likely caused by either Hibernate or the client of Hibernate holding onto a "stale" class, when the other is reloaded. If you always cycle both, it should not occur.

If you package your SAR and (assuming) the EJB JAR/Web JAR into an EAR it will hot deploy all items with no risk of resulting in stale handles.

Thanks for all your help... I think that I have figured it out now.

The problem is that the domain model is being deployed as a SAR, and classes that are using it (session bean, etc) are deployed in a couple of different EARs. Since each piece is handled distributed across different developers, in a dev deploy we will just deal and restart jboss. The production solution will most likely be to redeploy them in order (domain SAR, then the EARs) to keep from having stale handles, and/or combine everything into one EAR and deploy that.

Thanks again!
-Kat

Kat

I don't know JBoss but I had a similar problem with hot deployment. I use hot deployment during the development phase of our projects to avoid re-starting the SessionFactory( or other classes) every time I change a .java file and compile.

Well to make the story short as you know Hibernate uses the Configuration object to load the mapping files; inside this class most of the add methods use the current class loader to load the mapping files

Ej: In the case of the add(Class persistentClass) method the hbm.xml file is retrieved with:
InputStream rsrc =persistentClass.getClassLoader ().getResourceAsStream(fileName);

However to load the classes referred from the mapping file (ej: <class name="ef.foo.Foo" table="FOO"/>)
a different approach is taken.
There is a Binder object that uses a static method of another class called ReflectHelper which load classes using the classloader return by:

Thread.currentThread().getContextClassLoader().loadClass(classname)

which is the context class loader. You can check the javadocs to see what this class loader is and the implications. The bottom line is that when you get the persistent class not found error is because the contextClassLoader
can't find it.

In my project I have total control over the CLassLoaders and I just used the method setContextClassLoader of the Thread object to fix the problem, however in some environments doing this may have major security implications, the approach taken by Hibernate seems to be the right one but I am not an expert on this, so I really can not make an statement on this

I hope this information is useful
best regards