CODEWITHSUNDEEP
springjpawebsphere-liberty
mihais
mihais

Reputation: 47

EntityManagerFactory cannot be created in websphere liberty profile

Problem description:

I am trying to migrate a web application from Websphere 8.5.5 to Websphere Liberty Profile (WLP 16.0.0.3) under my local Eclipse environment. The application is working fine in Websphere but when started in WLP i get following exception:

Error creating bean with name 'entityManagerFactory': Post-processing of the FactoryBean's object failed; nested exception is java.lang.NoClassDefFoundError: org.apache.openjpa.persistence.query.QueryBuilder

I would expect the QueryBuilder class to be present in the opnJPA implementation provided by the Liberty runtime, but for some reason is not loaded correctly. Any help would be greatly appreciated.

Few details about the jpa configuration:

Upvotes: 1

Views: 775

Answers (2)

Andy Guibert
Andy Guibert

Reputation: 42926

By default, the jpa-2.0 feature only exposes spec-standard JPA packages to the application. It does not expose the JPA implementaiton-specific classes out-of-the-box.

In your case, since you need to expose Liberty's OpenJPA classes to your application (and libs inside your app such as Spring/Hibernate), you can opt-into this by using Liberty's "api type visibilty" mechanism.

I am guessing you have your application configured something like this in server.xml:

<application location="myApp.war"/>

To allow your application to see third-party (e.g. OpenJPA) classes, you can do this:

<application location="myApp.war">
  <!-- spec, ibm-api, and stable are enabled by default. -->
  <!-- Add third-party to get access to OpenJPA classes from your application -->
  <classloader apiTypeVisibility="spec, ibm-api, stable, third-party"/>
</application>

Official Liberty documentation: Accessing third-party APIs

You may be wondering:

Why does Liberty not make third-party classes, such as OpenJPA, available by default?

This is because Liberty gaurantees zero-migration when all things are held constant and you just upgrade to a newer Liberty version. Zero-migration essentially means "you won't have to change any of your app or config when you upgrade". Third party classes are not under the direct control of Liberty, and could potentially make breaking API changes and therefore break zero-migration. For this reason, Liberty only exposes the official/standard APIs by default, such as JavaEE and MicroProfile APIs.

Upvotes: 1

Alasdair
Alasdair

Reputation: 3176

Liberty by default hides non-API classes from applications. Things considered API are Java EE, MicroProfile and a few other things. You can open this up to third-party open-source apis through configuration.

Configuration like this:

<webApplication location="myapp.war">
  <classLoader apiTypeVisibility="+third-party" />
</webApplication>

Given you didn't give an example of your server configuration, or the stack trace of the exception, I can't know if this will fix your issue, but it is the best suggestion based on limited information.

This configuration may not work on 16.0.0.3. The +third-party support may have been added more recently (if it doesn't substituting spec,ibm-api,api,stable,third-party will work, but is more verbose and less usable). I would strongly recommend moving up to a newer version since 16.0.0.3 is no longer provided with function or security fixes. The most recent release is 19.0.0.3.

Upvotes: 1

Related Questions