Client Help

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Client Help

Scott Glass

I’ve written a small program to call a REST Web Service written in Jersey.  The service works, and responds with a JSONObject as expected.

But the client keeps throwing warnings and exceptions…

 

Jun 8, 2010 3:56:28 PM com.sun.jersey.spi.service.ServiceFinder$LazyObjectIterator hasNext

WARNING: The class com.sun.jersey.core.impl.provider.header.LocaleProvider implementing the provider interface com.sun.jersey.spi.HeaderDelegateProvider is not found. The provider implementation is ignored.

Jun 8, 2010 3:56:28 PM com.sun.jersey.spi.service.ServiceFinder$LazyObjectIterator hasNext

WARNING: The class com.sun.jersey.core.impl.provider.header.EntityTagProvider implementing the provider interface com.sun.jersey.spi.HeaderDelegateProvider is not found. The provider implementation is ignored.

Jun 8, 2010 3:56:28 PM com.sun.jersey.spi.service.ServiceFinder$LazyObjectIterator hasNext

WARNING: The class com.sun.jersey.core.impl.provider.header.MediaTypeProvider implementing the provider interface com.sun.jersey.spi.HeaderDelegateProvider is not found. The provider implementation is ignored.

Jun 8, 2010 3:56:28 PM com.sun.jersey.spi.service.ServiceFinder$LazyObjectIterator hasNext

WARNING: The class com.sun.jersey.core.impl.provider.header.CacheControlProvider implementing the provider interface com.sun.jersey.spi.HeaderDelegateProvider is not found. The provider implementation is ignored.

Jun 8, 2010 3:56:28 PM com.sun.jersey.spi.service.ServiceFinder$LazyObjectIterator hasNext

WARNING: The class com.sun.jersey.core.impl.provider.header.NewCookieProvider implementing the provider interface com.sun.jersey.spi.HeaderDelegateProvider is not found. The provider implementation is ignored.

Jun 8, 2010 3:56:28 PM com.sun.jersey.spi.service.ServiceFinder$LazyObjectIterator hasNext

WARNING: The class com.sun.jersey.core.impl.provider.header.CookieProvider implementing the provider interface com.sun.jersey.spi.HeaderDelegateProvider is not found. The provider implementation is ignored.

Jun 8, 2010 3:56:28 PM com.sun.jersey.spi.service.ServiceFinder$LazyObjectIterator hasNext

WARNING: The class com.sun.jersey.core.impl.provider.header.URIProvider implementing the provider interface com.sun.jersey.spi.HeaderDelegateProvider is not found. The provider implementation is ignored.

Jun 8, 2010 3:56:28 PM com.sun.jersey.spi.service.ServiceFinder$LazyObjectIterator hasNext

WARNING: The class com.sun.jersey.core.impl.provider.header.DateProvider implementing the provider interface com.sun.jersey.spi.HeaderDelegateProvider is not found. The provider implementation is ignored.

Jun 8, 2010 3:56:28 PM com.sun.jersey.spi.service.ServiceFinder$LazyObjectIterator hasNext

WARNING: The class com.sun.jersey.core.impl.provider.header.StringProvider implementing the provider interface com.sun.jersey.spi.HeaderDelegateProvider is not found. The provider implementation is ignored.

 

com.sun.jersey.api.client.ClientHandlerException: java.lang.NullPointerException

        at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:128)

        at com.sun.jersey.api.client.Client.handle(Client.java:551)

        at com.sun.jersey.api.client.WebResource.handle(WebResource.java:556)

        at com.sun.jersey.api.client.WebResource.access$200(WebResource.java:69)

        at com.sun.jersey.api.client.WebResource$Builder.get(WebResource.java:451)

        at com.sungard.cto.arsystem.plugin.SunGardUpdateService.createEntry(SunGardUpdateService.java:199)

        at com.bmc.arsys.pluginsvr.plugins.a.ArdbcCreate(Unknown Source)

        at com.bmc.arsys.pluginsvr.a.ArEsArdbcCreate_4(Unknown Source)

        at com.bmc.arsys.arrpc.ARPluginServerDispatcher.dispatchOncRpcCall(Unknown Source)

        at org.acplt.oncrpc.server.OncRpcTcpConnectionServerTransport.dispatchCall(Unknown Source)

        at com.bmc.arsys.pluginsvr.a.d.dispatchCall(Unknown Source)

        at org.acplt.oncrpc.server.OncRpcTcpConnectionServerTransport._listen(Unknown Source)

        at org.acplt.oncrpc.server.OncRpcTcpConnectionServerTransport.access$000(Unknown Source)

        at org.acplt.oncrpc.server.OncRpcTcpConnectionServerTransport$1.run(Unknown Source)

Caused by: java.lang.NullPointerException

        at javax.ws.rs.core.MediaType.toString(MediaType.java:265)

        at com.sun.jersey.api.client.ClientRequest.getHeaderValue(ClientRequest.java:223)

        at com.sun.jersey.api.client.TerminatingClientHandler.headerValueToString(TerminatingClientHandler.java:229)

        at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.writeOutBoundHeaders(URLConnectionClientHandler.java:227)

        at com.sun.jersey.client.urlconnection.URLConnectionClientHandler._invoke(URLConnectionClientHandler.java:172)

        at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:126)

        ... 13 more

 

Here’s the code for the client…

 

           ClientConfig config = new DefaultClientConfig();

 

            myClient = Client.create(config);

 

          WebResource resource = myClient.resource(“http://portal-dev2.sgns.net:8181/Case/create”);

 

         MultivaluedMap map = new MultivaluedMapImpl();

 

         map.add("Format", "json");

         map.add("IncidentID", " HD0000001042502");

         map.add("CreateDate", " 2009-07-01 16:47");

 

       resource = resource.queryParams(map);

 

      /* resource.getURI().toString()  returns  http://portal-dev2.sgns.net:8181/Case/create?IncidentID=HD0000001042502&Format=json&CreateDate=2009-07-01+16:47   which works.*/

 

   /* Line 199 */     

    Object object = resource.accept(MediaType.APPLICATION_JSON_TYPE).get(ClientResponse.class);

 

Can anyone please shed some light as to what’s causing this? I’ve read pretty much everything I can get my hands on, but I’m at a loss.

 

Thanks,

Scott

 

Reply | Threaded
Open this post in threaded view
|

Re: Client Help

Paul Sandoz
Administrator
Hi Scott,

The errors are related to Jersey not being able to find some classes whose names are declared in a META-INF/services file (present in the jeresy-core jar). 

This could be because of re-package issues. Have you re-packaged Jersey classes?

Or it could be related to class loading issues. How are you running the client?

Jersey attempts to load the classes using the thread context class loader [*]. One thing you can try is to set the thread context class loader before you create the Client.

Paul.

[*] i think i need to change loading to fall back to the defining class loader of the currently class if look up fails, but i do not know if that will solve your problem.

On Jun 8, 2010, at 9:58 PM, Scott Glass wrote:

I’ve written a small program to call a REST Web Service written in Jersey.  The service works, and responds with a JSONObject as expected.
But the client keeps throwing warnings and exceptions…
 
Jun 8, 2010 3:56:28 PM com.sun.jersey.spi.service.ServiceFinder$LazyObjectIterator hasNext
WARNING: The class com.sun.jersey.core.impl.provider.header.LocaleProvider implementing the provider interface com.sun.jersey.spi.HeaderDelegateProvider is not found. The provider implementation is ignored.
Jun 8, 2010 3:56:28 PM com.sun.jersey.spi.service.ServiceFinder$LazyObjectIterator hasNext
WARNING: The class com.sun.jersey.core.impl.provider.header.EntityTagProvider implementing the provider interface com.sun.jersey.spi.HeaderDelegateProvider is not found. The provider implementation is ignored.
Jun 8, 2010 3:56:28 PM com.sun.jersey.spi.service.ServiceFinder$LazyObjectIterator hasNext
WARNING: The class com.sun.jersey.core.impl.provider.header.MediaTypeProvider implementing the provider interface com.sun.jersey.spi.HeaderDelegateProvider is not found. The provider implementation is ignored.
Jun 8, 2010 3:56:28 PM com.sun.jersey.spi.service.ServiceFinder$LazyObjectIterator hasNext
WARNING: The class com.sun.jersey.core.impl.provider.header.CacheControlProvider implementing the provider interface com.sun.jersey.spi.HeaderDelegateProvider is not found. The provider implementation is ignored.
Jun 8, 2010 3:56:28 PM com.sun.jersey.spi.service.ServiceFinder$LazyObjectIterator hasNext
WARNING: The class com.sun.jersey.core.impl.provider.header.NewCookieProvider implementing the provider interface com.sun.jersey.spi.HeaderDelegateProvider is not found. The provider implementation is ignored.
Jun 8, 2010 3:56:28 PM com.sun.jersey.spi.service.ServiceFinder$LazyObjectIterator hasNext
WARNING: The class com.sun.jersey.core.impl.provider.header.CookieProvider implementing the provider interface com.sun.jersey.spi.HeaderDelegateProvider is not found. The provider implementation is ignored.
Jun 8, 2010 3:56:28 PM com.sun.jersey.spi.service.ServiceFinder$LazyObjectIterator hasNext
WARNING: The class com.sun.jersey.core.impl.provider.header.URIProvider implementing the provider interface com.sun.jersey.spi.HeaderDelegateProvider is not found. The provider implementation is ignored.
Jun 8, 2010 3:56:28 PM com.sun.jersey.spi.service.ServiceFinder$LazyObjectIterator hasNext
WARNING: The class com.sun.jersey.core.impl.provider.header.DateProvider implementing the provider interface com.sun.jersey.spi.HeaderDelegateProvider is not found. The provider implementation is ignored.
Jun 8, 2010 3:56:28 PM com.sun.jersey.spi.service.ServiceFinder$LazyObjectIterator hasNext
WARNING: The class com.sun.jersey.core.impl.provider.header.StringProvider implementing the provider interface com.sun.jersey.spi.HeaderDelegateProvider is not found. The provider implementation is ignored.
 
com.sun.jersey.api.client.ClientHandlerException: java.lang.NullPointerException
        at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:128)
        at com.sun.jersey.api.client.Client.handle(Client.java:551)
        at com.sun.jersey.api.client.WebResource.handle(WebResource.java:556)
        at com.sun.jersey.api.client.WebResource.access$200(WebResource.java:69)
        at com.sun.jersey.api.client.WebResource$Builder.get(WebResource.java:451)
        at com.sungard.cto.arsystem.plugin.SunGardUpdateService.createEntry(SunGardUpdateService.java:199)
        at com.bmc.arsys.pluginsvr.plugins.a.ArdbcCreate(Unknown Source)
        at com.bmc.arsys.pluginsvr.a.ArEsArdbcCreate_4(Unknown Source)
        at com.bmc.arsys.arrpc.ARPluginServerDispatcher.dispatchOncRpcCall(Unknown Source)
        at org.acplt.oncrpc.server.OncRpcTcpConnectionServerTransport.dispatchCall(Unknown Source)
        at com.bmc.arsys.pluginsvr.a.d.dispatchCall(Unknown Source)
        at org.acplt.oncrpc.server.OncRpcTcpConnectionServerTransport._listen(Unknown Source)
        at org.acplt.oncrpc.server.OncRpcTcpConnectionServerTransport.access$000(Unknown Source)
        at org.acplt.oncrpc.server.OncRpcTcpConnectionServerTransport$1.run(Unknown Source)
Caused by: java.lang.NullPointerException
        at javax.ws.rs.core.MediaType.toString(MediaType.java:265)
        at com.sun.jersey.api.client.ClientRequest.getHeaderValue(ClientRequest.java:223)
        at com.sun.jersey.api.client.TerminatingClientHandler.headerValueToString(TerminatingClientHandler.java:229)
        at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.writeOutBoundHeaders(URLConnectionClientHandler.java:227)
        at com.sun.jersey.client.urlconnection.URLConnectionClientHandler._invoke(URLConnectionClientHandler.java:172)
        at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:126)
        ... 13 more
 
Here’s the code for the client…
 
           ClientConfig config = new DefaultClientConfig();
 
            myClient = Client.create(config);
 
          WebResource resource = myClient.resource(“http://portal-dev2.sgns.net:8181/Case/create”);
 
         MultivaluedMap map = new MultivaluedMapImpl();
 
         map.add("Format", "json");
         map.add("IncidentID", " HD0000001042502");
         map.add("CreateDate", " 2009-07-01 16:47");
 
       resource = resource.queryParams(map);
 
      /* resource.getURI().toString()  returns  http://portal-dev2.sgns.net:8181/Case/create?IncidentID=HD0000001042502&Format=json&CreateDate=2009-07-01+16:47   which works.*/
 
   /* Line 199 */     
    Object object = resource.accept(MediaType.APPLICATION_JSON_TYPE).get(ClientResponse.class);
 
Can anyone please shed some light as to what’s causing this? I’ve read pretty much everything I can get my hands on, but I’m at a loss.
 
Thanks,
Scott
 

Reply | Threaded
Open this post in threaded view
|

Re: Client Help

Scott Glass-2
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?

Thanks,
Scott


On Wed, Jun 9, 2010 at 12:58 AM, Paul Sandoz <[hidden email]> wrote:
Hi Scott,

The errors are related to Jersey not being able to find some classes whose names are declared in a META-INF/services file (present in the jeresy-core jar). 

This could be because of re-package issues. Have you re-packaged Jersey classes?

Or it could be related to class loading issues. How are you running the client?

Jersey attempts to load the classes using the thread context class loader [*]. One thing you can try is to set the thread context class loader before you create the Client.

Paul.

[*] i think i need to change loading to fall back to the defining class loader of the currently class if look up fails, but i do not know if that will solve your problem.

On Jun 8, 2010, at 9:58 PM, Scott Glass wrote:

I’ve written a small program to call a REST Web Service written in Jersey.  The service works, and responds with a JSONObject as expected.
But the client keeps throwing warnings and exceptions…
 
Jun 8, 2010 3:56:28 PM com.sun.jersey.spi.service.ServiceFinder$LazyObjectIterator hasNext
WARNING: The class com.sun.jersey.core.impl.provider.header.LocaleProvider implementing the provider interface com.sun.jersey.spi.HeaderDelegateProvider is not found. The provider implementation is ignored.
Jun 8, 2010 3:56:28 PM com.sun.jersey.spi.service.ServiceFinder$LazyObjectIterator hasNext
WARNING: The class com.sun.jersey.core.impl.provider.header.EntityTagProvider implementing the provider interface com.sun.jersey.spi.HeaderDelegateProvider is not found. The provider implementation is ignored.
Jun 8, 2010 3:56:28 PM com.sun.jersey.spi.service.ServiceFinder$LazyObjectIterator hasNext
WARNING: The class com.sun.jersey.core.impl.provider.header.MediaTypeProvider implementing the provider interface com.sun.jersey.spi.HeaderDelegateProvider is not found. The provider implementation is ignored.
Jun 8, 2010 3:56:28 PM com.sun.jersey.spi.service.ServiceFinder$LazyObjectIterator hasNext
WARNING: The class com.sun.jersey.core.impl.provider.header.CacheControlProvider implementing the provider interface com.sun.jersey.spi.HeaderDelegateProvider is not found. The provider implementation is ignored.
Jun 8, 2010 3:56:28 PM com.sun.jersey.spi.service.ServiceFinder$LazyObjectIterator hasNext
WARNING: The class com.sun.jersey.core.impl.provider.header.NewCookieProvider implementing the provider interface com.sun.jersey.spi.HeaderDelegateProvider is not found. The provider implementation is ignored.
Jun 8, 2010 3:56:28 PM com.sun.jersey.spi.service.ServiceFinder$LazyObjectIterator hasNext
WARNING: The class com.sun.jersey.core.impl.provider.header.CookieProvider implementing the provider interface com.sun.jersey.spi.HeaderDelegateProvider is not found. The provider implementation is ignored.
Jun 8, 2010 3:56:28 PM com.sun.jersey.spi.service.ServiceFinder$LazyObjectIterator hasNext
WARNING: The class com.sun.jersey.core.impl.provider.header.URIProvider implementing the provider interface com.sun.jersey.spi.HeaderDelegateProvider is not found. The provider implementation is ignored.
Jun 8, 2010 3:56:28 PM com.sun.jersey.spi.service.ServiceFinder$LazyObjectIterator hasNext
WARNING: The class com.sun.jersey.core.impl.provider.header.DateProvider implementing the provider interface com.sun.jersey.spi.HeaderDelegateProvider is not found. The provider implementation is ignored.
Jun 8, 2010 3:56:28 PM com.sun.jersey.spi.service.ServiceFinder$LazyObjectIterator hasNext
WARNING: The class com.sun.jersey.core.impl.provider.header.StringProvider implementing the provider interface com.sun.jersey.spi.HeaderDelegateProvider is not found. The provider implementation is ignored.
 
com.sun.jersey.api.client.ClientHandlerException: java.lang.NullPointerException
        at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:128)
        at com.sun.jersey.api.client.Client.handle(Client.java:551)
        at com.sun.jersey.api.client.WebResource.handle(WebResource.java:556)
        at com.sun.jersey.api.client.WebResource.access$200(WebResource.java:69)
        at com.sun.jersey.api.client.WebResource$Builder.get(WebResource.java:451)
        at com.sungard.cto.arsystem.plugin.SunGardUpdateService.createEntry(SunGardUpdateService.java:199)
        at com.bmc.arsys.pluginsvr.plugins.a.ArdbcCreate(Unknown Source)
        at com.bmc.arsys.pluginsvr.a.ArEsArdbcCreate_4(Unknown Source)
        at com.bmc.arsys.arrpc.ARPluginServerDispatcher.dispatchOncRpcCall(Unknown Source)
        at org.acplt.oncrpc.server.OncRpcTcpConnectionServerTransport.dispatchCall(Unknown Source)
        at com.bmc.arsys.pluginsvr.a.d.dispatchCall(Unknown Source)
        at org.acplt.oncrpc.server.OncRpcTcpConnectionServerTransport._listen(Unknown Source)
        at org.acplt.oncrpc.server.OncRpcTcpConnectionServerTransport.access$000(Unknown Source)
        at org.acplt.oncrpc.server.OncRpcTcpConnectionServerTransport$1.run(Unknown Source)
Caused by: java.lang.NullPointerException
        at javax.ws.rs.core.MediaType.toString(MediaType.java:265)
        at com.sun.jersey.api.client.ClientRequest.getHeaderValue(ClientRequest.java:223)
        at com.sun.jersey.api.client.TerminatingClientHandler.headerValueToString(TerminatingClientHandler.java:229)
        at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.writeOutBoundHeaders(URLConnectionClientHandler.java:227)
        at com.sun.jersey.client.urlconnection.URLConnectionClientHandler._invoke(URLConnectionClientHandler.java:172)
        at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:126)
        ... 13 more
 
Here’s the code for the client…
 
           ClientConfig config = new DefaultClientConfig();
 
            myClient = Client.create(config);
 
          WebResource resource = myClient.resource(“http://portal-dev2.sgns.net:8181/Case/create”);
 
         MultivaluedMap map = new MultivaluedMapImpl();
 
         map.add("Format", "json");
         map.add("IncidentID", " HD0000001042502");
         map.add("CreateDate", " 2009-07-01 16:47");
 
       resource = resource.queryParams(map);
 
      /* resource.getURI().toString()  returns  http://portal-dev2.sgns.net:8181/Case/create?IncidentID=HD0000001042502&Format=json&CreateDate=2009-07-01+16:47   which works.*/
 
   /* Line 199 */     
    Object object = resource.accept(MediaType.APPLICATION_JSON_TYPE).get(ClientResponse.class);
 
Can anyone please shed some light as to what’s causing this? I’ve read pretty much everything I can get my hands on, but I’m at a loss.
 
Thanks,
Scott
 




--
Scott Glass
Reply | Threaded
Open this post in threaded view
|

Re: Client Help

Paul Sandoz
Administrator

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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Client Help

Scott Glass-2
Paul You Rock!!!  

The classloader fix worked like a charm.

Thank you so much! Major stress, gone.

Scott


On Wed, Jun 9, 2010 at 11:00 AM, Paul Sandoz <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]




--
Scott Glass
Reply | Threaded
Open this post in threaded view
|

Re: Client Help

Paul Sandoz
Administrator

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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]




--
Scott Glass

Reply | Threaded
Open this post in threaded view
|

Re: Client Help

Scott Glass-2
Paul,
 Please forgive the noob question, but I cannot find the 1.3-SNAPSHOT. Where is the Maven repo?

Thanks,
Scott

On Wed, Jun 9, 2010 at 11:57 AM, Paul Sandoz <[hidden email]> wrote:

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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]




--
Scott Glass




--
Scott Glass
Reply | Threaded
Open this post in threaded view
|

Re: Client Help

Pavel Bucek
Hello Scott,

        <repository>
            <id>maven2-repository.dev.java.net</id>
            <name>Java.net Repository for Maven</name>
            <url>http://download.java.net/maven/2/</url>
            <layout>default</layout>
        </repository>

http://download.java.net/maven/2/com/sun/jersey/jersey-core/1.3-SNAPSHOT/ , etc...

Regards,
Pavel


On 6/9/10 8:31 PM, Scott Glass wrote:
Paul,
 Please forgive the noob question, but I cannot find the 1.3-SNAPSHOT. Where is the Maven repo?

Thanks,
Scott

On Wed, Jun 9, 2010 at 11:57 AM, Paul Sandoz <[hidden email]> wrote:

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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]




--
Scott Glass




--
Scott Glass

Reply | Threaded
Open this post in threaded view
|

Re: Client Help

Scott Glass-2
In reply to this post by Scott Glass-2


On Wed, Jun 9, 2010 at 2:31 PM, Scott Glass <[hidden email]> wrote:
Paul,
 Please forgive the noob question, but I cannot find the 1.3-SNAPSHOT. Where is the Maven repo?

Thanks,
Scott


On Wed, Jun 9, 2010 at 11:57 AM, Paul Sandoz <[hidden email]> wrote:

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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]




--
Scott Glass




--
Scott Glass



--
Scott Glass
Reply | Threaded
Open this post in threaded view
|

Re: Client Help

Scott Glass-2
Thanks Pavel,

Paul, yes, I had  success with jersey-core-1.3-SNAPSHOT.jar.   That definitely fixes the issue... and yes, I rolled back the "fix" to make sure it was a proper test.

Thanks again for the help!

Scott


On Wed, Jun 9, 2010 at 2:39 PM,Scott Glass <[hidden email]> wrote:


On Wed, Jun 9, 2010 at 2:31 PM, Scott Glass <[hidden email]> wrote:
Paul,
 Please forgive the noob question, but I cannot find the 1.3-SNAPSHOT. Where is the Maven repo?

Thanks,
Scott


On Wed, Jun 9, 2010 at 11:57 AM, Paul Sandoz <[hidden email]> wrote:

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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]




--
Scott Glass




--
Scott Glass



--
Scott Glass



--
Scott Glass
Reply | Threaded
Open this post in threaded view
|

Re: Client Help

Paul Sandoz
Administrator
On Jun 9, 2010, at 10:38 PM, Scott Glass wrote:
Thanks Pavel,

Paul, yes, I had  success with jersey-core-1.3-SNAPSHOT.jar.   That definitely fixes the issue... and yes, I rolled back the "fix" to make sure it was a proper test.


Great! thanks for verifying. I think that may solve quite a few annoying issues developers were having.

Paul.

Thanks again for the help!

Scott


On Wed, Jun 9, 2010 at 2:39 PM,Scott Glass <[hidden email]> wrote:


On Wed, Jun 9, 2010 at 2:31 PM, Scott Glass <[hidden email]> wrote:
Paul,
 Please forgive the noob question, but I cannot find the 1.3-SNAPSHOT. Where is the Maven repo?

Thanks,
Scott


On Wed, Jun 9, 2010 at 11:57 AM, Paul Sandoz <[hidden email]> wrote:

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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]




--
Scott Glass




--
Scott Glass



--
Scott Glass



--
Scott Glass

Reply | Threaded
Open this post in threaded view
|

Re: Client Help

DuceXu
This post has NOT been accepted by the mailing list yet.
i come cross the issue today, but i don't resolve it in this way ,please help me .thanks
Reply | Threaded
Open this post in threaded view
|

Re: Client Help

varnika89
This post has NOT been accepted by the mailing list yet.
In reply to this post by Scott Glass-2
Hi,

I came across with this posts online regarding HeaderDelegateProvider issue you had got and its solution but not sure how can I use it in my program as I am using jersey client and jersey core jar files version 1.19.1 directly (just importing them) but getting error at the run time. The error reads -

Caused By: javax.ejb.EJBException: java.lang.RuntimeException: com.sun.jersey.spi.service.ServiceConfigurationError: com.sun.jersey.spi.HeaderDelegateProvider: The class com.sun.jersey.core.impl.provider.header.LocaleProvider implementing provider interface com.sun.jersey.spi.HeaderDelegateProvider could not be instantiated: Cannot cast com.sun.jersey.core.impl.provider.header.LocaleProvider to com.sun.jersey.spi.HeaderDelegateProvider

Please help.

Thanks,
Varnika