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.
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.