Weblogic 12c JPA 2.1 spring boot

Question

I want to deploy a spring boot application to weblogic 12c (12.1.2).

The application using latest spring boot libraries. I try to using prefer-web-inf-classes but I run out of luck.

If I try to using prefer-webinf-classes I got (my application is using validation api 1.1.0.Final):

weblogic.application.ModuleException: java.lang.NoSuchMethodError: javax.validation.spi.ConfigurationState.getParameterNameProvider()Ljavax/validation/ParameterNameProvider;
        at weblogic.application.internal.ExtensibleModuleWrapper.start(ExtensibleModuleWrapper.java:140)
        at weblogic.application.internal.flow.ModuleListenerInvoker.start(ModuleListenerInvoker.java:124)
        at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:216)
        at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:211)
        at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42)
        Truncated. see log file for complete stacktrace
Caused By: java.lang.NoSuchMethodError: javax.validation.spi.ConfigurationState.getParameterNameProvider()Ljavax/validation/ParameterNameProvider;
        at org.hibernate.validator.internal.engine.ValidatorFactoryImpl.<init>(ValidatorFactoryImpl.java:142)
        at org.hibernate.validator.HibernateValidator.buildValidatorFactory(HibernateValidator.java:35)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        Truncated. see log file for complete stacktrace

If I try to using this configuration in web.xml:

    <wls:prefer-application-packages>
        <wls:package-name>antlr.*</wls:package-name>
        <wls:package-name>org.apache.commons.*</wls:package-name>
        <wls:package-name>org.apache.xmlbeans.*</wls:package-name>
        <wls:package-name>org.springframework.*</wls:package-name>
        <wls:package-name>org.hibernate.*</wls:package-name>
        <wls:package-name>org.hibernate.validator.*</wls:package-name>
        <wls:package-name>javax.validation.*</wls:package-name>
        <wls:package-name>javax.persistence.*</wls:package-name>
        <wls:package-name>javax.validation.spi.*</wls:package-name>
        <wls:package-name>org.slf4j.*</wls:package-name>
        <wls:package-name>org.joda.*</wls:package-name>
        <wls:package-name>com.fasterxml.*</wls:package-name>
    </wls:prefer-application-packages>

I got hibernate weblogic "org.eclipse.persistence.jpa.PersistenceProvider cannot be cast to javax.persistence.spi.PersistenceProvider" exception from validator.

How can I solve this? (upgrade weblogic is not an option)

Thanks

Answer 1

I had same issue with Spring Boot and WebLogic 12c with error org.eclipse.persistence.jpa.PersistenceProvider cannot be cast to javax.persistence.spi.PersistenceProvider

I was getting this error only if I was using any of validation annotations.

Solved by adding this to weblogic.xml:

    <prefer-application-resources>
        <resource-name>META-INF/services/javax.persistence.spi.PersistenceProvider</resource-name>
    </prefer-application-resources>

Answer 2

Sorry for my late answer. My final solution:

1. add weblogic.xml into your war with these content:

    <?xml version="1.0" encoding="UTF-8"?> <wls:weblogic-web-app xmlns:wls="http://xmlns.oracle.com/weblogic/weblogic-web-app" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd http://xmlns.oracle.com/weblogic/weblogic-web-app http://xmlns.oracle.com/weblogic/weblogic-web-app/1.4/weblogic-web-app.xsd"> <wls:container-descriptor> <wls:prefer-web-inf-classes>true</wls:prefer-web-inf-classes> </wls:container-descriptor> </wls:weblogic-web-app> 

2. Create ear (It's important) and add weblogic-application.xml:

    <?xml version="1.0" encoding="UTF-8"?> <weblogic-application xmlns="http://xmlns.oracle.com/weblogic/weblogic-application" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-application http://xmlns.oracle.com/weblogic/weblogic-application/1.4/weblogic-application.xsd"> <prefer-application-packages> <package-name>org.slf4j.*</package-name> <package-name>com.fasterxml.*</package-name> <package-name>org.joda.*</package-name> <package-name>org.hibernate.*</package-name> <package-name>org.jboss.*</package-name> <package-name>javax.validation.*</package-name> </prefer-application-packages> </weblogic-application> 

This is work for me...

Answer 3

Obviously, there is a classloading conflict between the API and the implementation (eclipse.jpa.PersistenceProvider).

However, the reason for such conflict is yet to explain, since the 'prefer-application-packages' is supposed to tell the container to use what comes within the application package (ie both the API and implementation).

A workaround that worked for me in WLS 12.2.1 is as follows :

1. Exclude the dependency to the JAP2 API :

    <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-jpa</artifactId> <exclusions> <exclusion> <groupId>org.hibernate.javax.persistence</groupId> <artifactId>hibernate-jpa-2.1-api</artifactId> </exclusion> </exclusions> </dependency> 

2. Make sure your the 'prefer-application-packages' in weblogic.xml does not include javax.persistence.* (but should include javax.validation.* and org.hibernate.*)

Using this workaround, you are relying on the JPA2 implementation of the container..

Beware, thought, that this might be confusing if versions are different since behaviour might differ between unit tests (using JPA2 implementation that comes with Spring Boot : hibernate-jpa) and tests in container (using whatever JPA implementation WebLogic provides: likely eclipse JPA Provider).

Answer 4

A bit too late to answer you question I guess but it sounds like you are using a new interface and old implementation. This happens sometimes when you deploy to a container and not using class-path filtering for instance. In turn you will use an older implementation provided by the container. The behavior is very random depending on what gets loaded when. Hope this helps you in right direction or anyone else having similar problem.