Alexander Mitenko wrote:
Metawidget's library realization for default action Class.forName( "....PersistentBag" ) fails in the web tier when hibernate-core-4.0.0.CR2.jar is available in the app server!
I'm guessing it's not using the correct classloader. Class.forName has overloaded methods, make sure you are using the correct one. You could also post the relevant code and the exception stacktrace.
Here is output of toString() for every used class loaders:
19:20:28,034 INFO [stdout] (http--127.0.0.1-8080-1) Current thread classloader: ModuleClassLoader for Module "deployment.nfcs-1.0.0.ear.web-1.0.0.war:main" from Service Module Loader
19:20:28,034 INFO [stdout] (http--127.0.0.1-8080-1) ClassUtils class classloader: ModuleClassLoader for Module "deployment.nfcs-1.0.0.ear.web-1.0.0.war:main" from Service Module Loader
Our trick, that forces project to work:
19:20:28,034 INFO [stdout] (http--127.0.0.1-8080-1) nfcs.model.User classloader: ModuleClassLoader for Module "deployment.nfcs-1.0.0.ear:main" from Service Module Loader
But, war project is embedded into ear and deployed, of course, together by standard file deployment mechanism. Why they use different classloaders?
There are no obvious reasons to use native Hibernate in WEB tier, isn't it? Then I do not used it!
I use my own entities to transfer data into EJB tier to use a container managed space for CRUD operations with EntityManager and no any Hibernate calls at any tier.
Thanks for Yours opinion, but it is not for my case.
1 of 1 people found this helpful
You did mention using JPA but sometimes people use that term to refer to the Hibernate native api. We currently inject the Hibernate module dependency in the same place as the persistence unit definition.
This documentation explains more and gives some possible workarounds when you run into problems. You probably could try adding a META-INF/MANIFEST.MF entry (for the org.hibernate module) to your war. The entry would contain:
See if that helps workaround the issue.
Your workaround is works for me! Thanks.