You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The ordering of the class loaders means that the Proxy.newProxy call will fail when it tries to reload the interfaces from loader with the following message "org.glassfish.hk2.api.ProxyCtl is not visible from class loader" even though it is available.
If you alter the order of the class loaders then this problem goes away because the local class loader is prioritised.
This was seen when trying to shoehorn Jersey 2.21.1 into WLS 12.1.2 and the classes was using @context to inject HttpServletRequest. In this case HttpServletRequest came from the root class loader for the server but we have a different version of hk2 in the root class loader and the .war class loader. FYI my weblogic.xml looked like this, I can provide more details if you need a more complete test case.
<?xml version="1.0" encoding="UTF-8"?>
<weblogic-web-appxmlns="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/web-app_2_5.xsd http://xmlns.oracle.com/weblogic/weblogic-web-app http://xmlns.oracle.com/weblogic/weblogic-web-app/1.2/weblogic-web-app.xsd">
<context-root/>
<!-- Use built version to say deploy change <library-ref> <library-name>jax-rs</library-name> <specification-version>2.0</specification-version> <exact-match>false</exact-match> </library-ref> -->
<container-descriptor>
<prefer-application-packages>
<!-- apis -->
<package-name>javax.ws.rs.*</package-name>
<package-name>javax.validation.*</package-name>
<!-- guava -->
<package-name>com.google.common.*</package-name>
<!-- A hibernate validation provider -->
<package-name>org.hibernate.validator.*</package-name>
<!-- jersey providers -->
<package-name>com.sun.jersey.*</package-name>
<package-name>org.glassfish.jersey.*</package-name>
<package-name>jersey.repackaged.*</package-name>
<!-- hk2 -->
<package-name>org.jvnet.hk2.*</package-name>
<package-name>org.jvnet.hk2.tiger_types.*</package-name>
<package-name>org.glassfish.hk2.*</package-name>
<package-name>javassist.*</package-name>
<!-- media providers -->
<package-name>org.eclipse.persistence.jaxb.rs.*</package-name>
<package-name>org.codehaus.jackson.jaxrs.*</package-name>
<!-- wls -->
<package-name>weblogic.jaxrs.api.client.*</package-name>
<package-name>weblogic.jaxrs.internal.api.client.*</package-name>
<package-name>weblogic.jaxrs.dispatch.*</package-name>
<package-name>weblogic.jaxrs.monitoring.util.*</package-name>
</prefer-application-packages>
<prefer-application-resources>
<resource-name>META-INF/services/javax.validation.spi.ValidationProvider</resource-name>
</prefer-application-resources>
</container-descriptor>
<!-- XXXXXX redacted-->
<session-descriptor>
<cookie-secure>true</cookie-secure>
<url-rewriting-enabled>false</url-rewriting-enabled>
</session-descriptor>
</weblogic-web-app>
The text was updated successfully, but these errors were encountered:
When creating the delegating class loader:
The ordering of the class loaders means that the Proxy.newProxy call will fail when it tries to reload the interfaces from loader with the following message "org.glassfish.hk2.api.ProxyCtl is not visible from class loader" even though it is available.
If you alter the order of the class loaders then this problem goes away because the local class loader is prioritised.
This was seen when trying to shoehorn Jersey 2.21.1 into WLS 12.1.2 and the classes was using @context to inject HttpServletRequest. In this case HttpServletRequest came from the root class loader for the server but we have a different version of hk2 in the root class loader and the .war class loader. FYI my weblogic.xml looked like this, I can provide more details if you need a more complete test case.
The text was updated successfully, but these errors were encountered: