users@jersey.java.net

Re: [Jersey] Client Help

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Wed, 09 Jun 2010 17:57:30 +0200

On Jun 9, 2010, at 5:29 PM, Scott Glass wrote:

> Paul You Rock!!!
>
> The classloader fix worked like a charm.
>

Great.

The 1.3-SNAPSHOT i was referring to is now available from the maven
repo. If you have time to give that a try i would be interested to
know if that solves your issue without having to resort to thread
context class loader wrapping.

Paul.


> Thank you so much! Major stress, gone.
>
> Scott
>
>
> On Wed, Jun 9, 2010 at 11:00 AM, Paul Sandoz <Paul.Sandoz_at_sun.com>
> wrote:
>
> On Jun 9, 2010, at 4:25 PM, Scott Glass wrote:
>
> Paul,
> Thank you for the reply. I haven't repackaged it, but it is being
> used in a "plug-in" for BMC's Action Request System (Remedy).
> I was including (in the classpath) jersey-core-1.2.jar then switched
> over to the jersey-bundle-1.2.jar. Both of which have resulted in
> the same response.
> Would it make more sense to re-package it and include my code?
>
>
> No, i think this is a class loader issue as i suspect the plugin
> defines some class loading scope.
>
> Is it possible to set the thread context class loader to the class
> loader of the current class?
>
> ClassLoader old = Thread.currentThread().getContextClassLoader();
>
> Thread
> .currentThread
> ().setContextClassLoader(this.getClass().getClassLoader());
> try {
> // Jersey client stuff
> } finally {
> Thread.currentThread().setContextClassLoader(old);
> }
>
>
>
> I have fixed the loading of classes to use the class loader of the
> current class if class loading fails using the context class loader.
> When a new 1.3-SNAPSHOT is available on the maven repo could you
> give that a try and see if that fixes the problem for you?
>
> Paul.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>
>
>
> --
> Scott Glass