[
https://issues.apache.org/jira/browse/CXF-4290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13270983#comment-13270983
]
Chris Dolan commented on CXF-4290:
----------------------------------
Sergey: I started prototyping the classloader, but stopped when I realized that
it wouldn't work for sub resources. I think that shipping CXF with a dynamic
loader would be great. It would need to be careful to 1) cache the CL to avoid
making hundreds of copies and 2) carefully use weak references for the cache to
avoid pinning the OSGi bundle. It would certainly be easier and more flexible
to accept a classloader argument, but an automatic implementation would be much
more user-friendly.
> Allow user-specified classloader for JAXRSClientFactory
> -------------------------------------------------------
>
> Key: CXF-4290
> URL: https://issues.apache.org/jira/browse/CXF-4290
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
> Affects Versions: 2.5
> Environment: Apache Karaf 2.2.4, CXF 2.5.0
> Reporter: Chris Dolan
>
> I wrote a helper class that isolates CXF's JAXRSClientFactory from users. My
> helper exposes this interface as a OSGi service:
> {code}
> public interface JaxRsClientBuilder {
> <T> T createClient(@Nonnull String baseUrl, @Nonnull Class<T>
> resourceApiClass);
> }
> {code}
> However, I discovered a blocking problem. If the user of my helper doesn't
> import org.apache.cxf.jaxrs.client in its OSGi classloader, then I get
> exceptions from java.lang.reflect.Proxy because there's no classloader
> anywhere that can see both resourceApiClass and
> org.apache.cxf.jaxrs.client.Client. I tried a solution (based on
> http://blog.osgi.org/2008/08/classy-solutions-to-tricky-proxies.html) where I
> dynamically make an aggregate classloader that can see both resourceApiClass
> and Client. I think I can trick JAXRSClientFactory into using this new
> classloader for the main resource (by passing in a new Proxy instance as the
> resource class), but I can't wedge my custom classloader in for subresources
> because of the way ClientProxyImpl.invoke() calls JAXRSClientFactory.
> I request the following as a possible solution. Certainly, I'd accept a
> better solution. For example, it looks like JAX-RS 2.0 should eliminate this
> problem by making Client into a public interface instead of an implementation
> detail.
> 1) add a new method variant to JAXRSClientFactory that takes a classloader
> 2) pass this classloader to JAXRSClientFactoryBean, and use it instead of
> cri.getServiceClass().getClassLoader() or the thread context classloader
> 3) change ClientProxyImpl to save this classloader and use it for
> subresources
> See also the following which describes my failed attempt to work around this
> issue:
> http://stackoverflow.com/questions/10458378/how-can-i-make-a-java-lang-reflect-proxy-from-two-separate-classloaders
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
