"barakka" wrote :
| The problem, however, is not related to hibernate search being moved. The class cast
exception that I get are basic hibernate classes, like Session, etc.
|
That can happen if your application is not scoped correctly or you do not have the right
set (or a complete set) of hibernate jars.
"barakka" wrote :
| What I've been able to dig out is that the ejb3.deployer and my ear use two
separate classloader, with the one used by the ejb3.deployer loading the lib from the the
server folder and the one for my app reading the lib from my ear.
|
That's the correct behaviour.
"barakka" wrote :
| In fact, if you take the issue to its extreme and suppose that the server does not
provide any hibernate lib, the ejb3.deployer will not work at all, as it can't find
the hibernate classes needed to create the persistence manager factory
|
That's the very reason why the hibernate libraries are provided by the AS.
"barakka" wrote :
| And I believe this behaviour is not the correct one: the deployer should use the ear
classloader.
| I'm now wondering if I can define the ejb.deployer service within my ear directly,
so it will use its classloader.
|
From your description, i would again say that the application is not
correctly scoped :) So the best way to debug this is to provide more details about your
application including logs and your application packaging.
Post the output of
jar -tf yourapp.ear
Also post the contents of application.xml and jboss-app.xml (in which the classloader
configuration is done).
The other important part would be the TRACE level logs from the org.jboss.classloading
package. But let's first check the other details that i asked for before looking at
the those TRACE logs (which will be too long to post here).
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4212061#...
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...