Re: classloader issues in httpclient from jets3t in different classloader

2016-03-02 Thread Alexey Panchenko 
That was fast. I am just curious why making changes here :-) if
- those classes were deprecated long ago? (the "java-deprecated" folder
kind of reminds of that)
- the code on jets3t master looks better and use newer httpclient APIs (its
probably not released yet)

On Thu, Mar 3, 2016 at 12:31 PM, Gary Gregory 
wrote:

> Closing the loop: This should be fixed in trunk now. See
> https://issues.apache.org/jira/browse/HTTPCLIENT-1727
>
> Gary
>
> On Wed, Mar 2, 2016 at 2:22 PM, Charles Allen <
> charles.al...@metamarkets.com
> > wrote:
>
> > I'm getting the following stack trace when using jets3t which uses
> > httpclient:
> >
> > Caused by: java.lang.IllegalStateException: Invalid class name:
> > org.jets3t.service.utils.RestUtils$ConnManagerFactory
> > at
> >
> >
> org.apache.http.impl.client.AbstractHttpClient.createClientConnectionManager(AbstractHttpClient.java:319)
> > ~[druid-selfcontained-2f990f7.jar:2f990f7]
> > at
> >
> >
> org.apache.http.impl.client.AbstractHttpClient.getConnectionManager(AbstractHttpClient.java:465)
> > ~[druid-selfcontained-2f990f7.jar:2f990f7]
> > at
> >
> >
> org.apache.http.impl.client.AbstractHttpClient.createHttpContext(AbstractHttpClient.java:285)
> > ~[druid-selfcontained-2f990f7.jar:2f990f7]
> > at
> >
> >
> org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:799)
> > ~[druid-selfcontained-2f990f7.jar:2f990f7]
> > at
> >
> >
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
> > ~[druid-selfcontained-2f990f7.jar:2f990f7]
> > at
> >
> >
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:57)
> > ~[druid-selfcontained-2f990f7.jar:2f990f7]
> > at
> >
> >
> org.jets3t.service.impl.rest.httpclient.RestStorageService.performRequest(RestStorageService.java:328)
> > ~[?:?]
> > at
> >
> >
> org.jets3t.service.impl.rest.httpclient.RestStorageService.performRequest(RestStorageService.java:279)
> > ~[?:?]
> > at
> >
> >
> org.jets3t.service.impl.rest.httpclient.RestStorageService.performRestHead(RestStorageService.java:1052)
> > ~[?:?]
> > at
> >
> >
> org.jets3t.service.impl.rest.httpclient.RestStorageService.getObjectImpl(RestStorageService.java:2264)
> > ~[?:?]
> > at
> >
> >
> org.jets3t.service.impl.rest.httpclient.RestStorageService.getObjectDetailsImpl(RestStorageService.java:2193)
> > ~[?:?]
> > at
> > org.jets3t.service.S3Service.getObjectDetails(S3Service.java:2574) ~[?:?]
> > at
> > org.jets3t.service.S3Service.getObjectDetails(S3Service.java:1773) ~[?:?]
> >
> >
> > Looking into it, it seems httpclient doesn't take classloaders into
> > consideration when looking for connection manager factories:
> >
> >
> https://github.com/apache/httpclient/blob/4.5.2/httpclient/src/main/java-deprecated/org/apache/http/impl/client/AbstractHttpClient.java#L332
> >
> > As such, the only connection manager factories that can be used must be
> in
> > the same classloader as AbstractHttpClient. If something like jets3t is
> > loaded in a child classloader with AbstractHttpClient's classloader as a
> > parent, then jets3t will not work with the exception shown above.
> >
> > The correct solution would be to set the thread context classloader
> before
> > calling things which end up calling Class.forName, and having the library
> > (httpclient in this case) be aware of the context classloader.
> >
> > But currently there is no way for me to force httpclient to be aware of
> any
> > classloader other than the one used to load AbstractHttpClient
> >
> > Is there any workaround? Or am I mis-reading the problem here?
> >
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>

Re: classloader issues in httpclient from jets3t in different classloader

2016-03-02 Thread Gary Gregory 
Closing the loop: This should be fixed in trunk now. See
https://issues.apache.org/jira/browse/HTTPCLIENT-1727

Gary

On Wed, Mar 2, 2016 at 2:22 PM, Charles Allen  wrote:

> I'm getting the following stack trace when using jets3t which uses
> httpclient:
>
> Caused by: java.lang.IllegalStateException: Invalid class name:
> org.jets3t.service.utils.RestUtils$ConnManagerFactory
> at
>
> org.apache.http.impl.client.AbstractHttpClient.createClientConnectionManager(AbstractHttpClient.java:319)
> ~[druid-selfcontained-2f990f7.jar:2f990f7]
> at
>
> org.apache.http.impl.client.AbstractHttpClient.getConnectionManager(AbstractHttpClient.java:465)
> ~[druid-selfcontained-2f990f7.jar:2f990f7]
> at
>
> org.apache.http.impl.client.AbstractHttpClient.createHttpContext(AbstractHttpClient.java:285)
> ~[druid-selfcontained-2f990f7.jar:2f990f7]
> at
>
> org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:799)
> ~[druid-selfcontained-2f990f7.jar:2f990f7]
> at
>
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
> ~[druid-selfcontained-2f990f7.jar:2f990f7]
> at
>
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:57)
> ~[druid-selfcontained-2f990f7.jar:2f990f7]
> at
>
> org.jets3t.service.impl.rest.httpclient.RestStorageService.performRequest(RestStorageService.java:328)
> ~[?:?]
> at
>
> org.jets3t.service.impl.rest.httpclient.RestStorageService.performRequest(RestStorageService.java:279)
> ~[?:?]
> at
>
> org.jets3t.service.impl.rest.httpclient.RestStorageService.performRestHead(RestStorageService.java:1052)
> ~[?:?]
> at
>
> org.jets3t.service.impl.rest.httpclient.RestStorageService.getObjectImpl(RestStorageService.java:2264)
> ~[?:?]
> at
>
> org.jets3t.service.impl.rest.httpclient.RestStorageService.getObjectDetailsImpl(RestStorageService.java:2193)
> ~[?:?]
> at
> org.jets3t.service.S3Service.getObjectDetails(S3Service.java:2574) ~[?:?]
> at
> org.jets3t.service.S3Service.getObjectDetails(S3Service.java:1773) ~[?:?]
>
>
> Looking into it, it seems httpclient doesn't take classloaders into
> consideration when looking for connection manager factories:
>
> https://github.com/apache/httpclient/blob/4.5.2/httpclient/src/main/java-deprecated/org/apache/http/impl/client/AbstractHttpClient.java#L332
>
> As such, the only connection manager factories that can be used must be in
> the same classloader as AbstractHttpClient. If something like jets3t is
> loaded in a child classloader with AbstractHttpClient's classloader as a
> parent, then jets3t will not work with the exception shown above.
>
> The correct solution would be to set the thread context classloader before
> calling things which end up calling Class.forName, and having the library
> (httpclient in this case) be aware of the context classloader.
>
> But currently there is no way for me to force httpclient to be aware of any
> classloader other than the one used to load AbstractHttpClient
>
> Is there any workaround? Or am I mis-reading the problem here?
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

classloader issues in httpclient from jets3t in different classloader

2016-03-02 Thread Charles Allen 
I'm getting the following stack trace when using jets3t which uses
httpclient:

Caused by: java.lang.IllegalStateException: Invalid class name:
org.jets3t.service.utils.RestUtils$ConnManagerFactory
at
org.apache.http.impl.client.AbstractHttpClient.createClientConnectionManager(AbstractHttpClient.java:319)
~[druid-selfcontained-2f990f7.jar:2f990f7]
at
org.apache.http.impl.client.AbstractHttpClient.getConnectionManager(AbstractHttpClient.java:465)
~[druid-selfcontained-2f990f7.jar:2f990f7]
at
org.apache.http.impl.client.AbstractHttpClient.createHttpContext(AbstractHttpClient.java:285)
~[druid-selfcontained-2f990f7.jar:2f990f7]
at
org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:799)
~[druid-selfcontained-2f990f7.jar:2f990f7]
at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
~[druid-selfcontained-2f990f7.jar:2f990f7]
at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:57)
~[druid-selfcontained-2f990f7.jar:2f990f7]
at
org.jets3t.service.impl.rest.httpclient.RestStorageService.performRequest(RestStorageService.java:328)
~[?:?]
at
org.jets3t.service.impl.rest.httpclient.RestStorageService.performRequest(RestStorageService.java:279)
~[?:?]
at
org.jets3t.service.impl.rest.httpclient.RestStorageService.performRestHead(RestStorageService.java:1052)
~[?:?]
at
org.jets3t.service.impl.rest.httpclient.RestStorageService.getObjectImpl(RestStorageService.java:2264)
~[?:?]
at
org.jets3t.service.impl.rest.httpclient.RestStorageService.getObjectDetailsImpl(RestStorageService.java:2193)
~[?:?]
at
org.jets3t.service.S3Service.getObjectDetails(S3Service.java:2574) ~[?:?]
at
org.jets3t.service.S3Service.getObjectDetails(S3Service.java:1773) ~[?:?]


Looking into it, it seems httpclient doesn't take classloaders into
consideration when looking for connection manager factories:
https://github.com/apache/httpclient/blob/4.5.2/httpclient/src/main/java-deprecated/org/apache/http/impl/client/AbstractHttpClient.java#L332

As such, the only connection manager factories that can be used must be in
the same classloader as AbstractHttpClient. If something like jets3t is
loaded in a child classloader with AbstractHttpClient's classloader as a
parent, then jets3t will not work with the exception shown above.

The correct solution would be to set the thread context classloader before
calling things which end up calling Class.forName, and having the library
(httpclient in this case) be aware of the context classloader.

But currently there is no way for me to force httpclient to be aware of any
classloader other than the one used to load AbstractHttpClient

Is there any workaround? Or am I mis-reading the problem here?