• Post Reply Bookmark Topic Watch Topic
  • New Topic

Websphere classloader with JPA 2 and 2.1

 
Brian Mulholland
Ranch Hand
Posts: 65
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I hope this is the right group to post this in. None of them seemed perfect to me.

Anyway, here's what I know. We have many j2ee apps running hibernate 3. A previous developer discovered that websphere loaded a copy of jpa in it's startup, and that he was getting version clashes as a result. So he slipped the jpa 2.0 jar into the jre/lib/ext folder to get it loaded first. Problem solved, he thought.

But now we're starting to convert some of our apps to Hibernate 4, which needs jpa 2.1 jar. I don't want to repeat the same trick. For one, it seems like the wrong solution. But also, will it be backwards compatible? Will we always be demendent on this trick even if this one was backwards compatible?

What is the "right way" to do this? The solution my colleague found, while it works, seems like a hack. There must be a beter way so that each app can run it's own jpa jar dependency. Sticking it in web-inf/lib and so forth doesn't work because the Webspere classloader loads the wrong version far earlier.

(update)
Forgot to post the stack trace.
Caused by: java.lang.NoSuchMethodError: javax/persistence/Table.indexes()[Ljavax/persistence/Index;
at org.hibernate.cfg.annotations.EntityBinder.processComplementaryTableDefinitions(EntityBinder.java:936)
at org.hibernate.cfg.AnnotationBinder.bindClass(AnnotationBinder.java:781)
at org.hibernate.cfg.Configuration$MetadataSourceQueue.processAnnotatedClassesQueue(Configuration.java:3762)
at org.hibernate.cfg.Configuration$MetadataSourceQueue.processMetadata(Configuration.java:3716)
at org.hibernate.cfg.Configuration.secondPassCompile(Configuration.java:1410)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1844)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1928)
at org.springframework.orm.hibernate4.LocalSessionFactoryBuilder.buildSessionFactory(LocalSessionFactoryBuilder.java:339)
at org.springframework.orm.hibernate4.LocalSessionFactoryBean.buildSessionFactory(LocalSessionFactoryBean.java:427)
at org.springframework.orm.hibernate4.LocalSessionFactoryBean.afterPropertiesSet(LocalSessionFactoryBean.java:412)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1612)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1549)
... 95 more
 
Claude Moore
Ranch Hand
Posts: 832
7
IBM DB2 Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, as far as I know putting jars into jre/lib/ext to let them be loaded by an appserver is a very bad practice.
With WebSphere product, you may try and define a shared library ad associate it to a classloader to be used by your EAR projects.

May you define hibernate jars as Java Utils Modules within your EAR ? I think you can... in that case, you may play with ClassLoader policy
and specify parent_last policy: doing so, WebSphere should use JPA version loaded within the EAR classloader, "overriding" the version
loaded by root classloader.

Anyway you should fix your enviroment by removing HIbernate jars from jre/lib/folder.



 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!