Hibernate version: 2.1.7c

I have a situation where I have multiple classloaders over the lifetime of my application, each bringing its own set of mappings. Right now, I have multiple SessionFactories, one for each classloader. I would like to try sharing one SessionFactory over all classloaders.

My problem is that during the buildSessionFactory() stage, Configuration wants to find classes in the context classloader, but this is not possible.

Is there any way around this? Is there a way to bind the class as I supply the mappings?

I don't think you can do such things

Solarsail:

You _might_ be able to accomplish what you want using the following general approach:

1. Instantiate your custom classloaders. I'm presuming you are chaining each one together using appropriate constructors AND that the first loader you created bound itself to the classloader of the current thread.

2. Set the context classloader of the current thread using:
Thread.curentThread.setContextClassLoader({refToYourClassLoader})

3. Create your Configuration object and bind definitions as you normally would.

This will not work if Hibernate and your client are operating in separate threads, of course. If you have written a controller that manages the Hibernate thread, you could use a similar philosophy to try and hook the Hibernate class loader.

Note: my only experience with the above has been while idly hacking the Hibernate code. Don't try this in a production environment until you've thoroughly tested it.

Good luck.

btw. this how hibernate console works - but it is surely nothing i would advise you to do.

btw. if the classes is not available in context class loader nor on the classpath of hibernate how should hibernate code know how to find it ?
it would be insanely ugly to carry around a "userclassloader" to do this...and that is actually why there is such a thing as a context classloader.
/max

Max:



Don't know about the ugly part, but it's certainly not insane. There are a variety of problems that could use dynamically resolved/dynamically generated classes to solve. Remote code fetching, on-the-fly classfile generation--these things aren't going to fit nicely into a static context. Examples are everywhere--look at just about any J2EE server or, for that matter, at the Hibernate Console, as you point out.

The classloader mechanism is as extensible as it is for a reason--Sun never thought they'd have the be-all/end-all solution. The context loader works just great about 99% of the time. But that 1% really needs the ability to include it's own loader in the delegation chain.

And the beauty of the extensible classloader is that Hibernate doesn't need to care about finding the classes. As long as the config is supplied a valid classmapping and the classload chain-supplied definitions pass the bytecode verifiers, it doesn't have to give a hoot.

Hi Eric,

I don't think you read my answer ;)

I said *carrying* a userclassloader around (here i meant as arguments/fields across all hibernates code) is insanely ugly....

I then said the context classloader was there to solve this problem since it is a threadlocal and i even used it in hibernate console to work around some quirks with jdbc and user classes et.al.

but i would never advise one to do it, just because he could - messing with ctx classloaders are simple, but it can have nasty sideeffects people don't realize several months into a project where it is to late to fix/shift strategy.