users@jersey.java.net

Re: [Jersey] adding a _at_Context annotated parameter using an InjectableProvider on Websphere

From: Paul Sandoz <Paul.Sandoz_at_oracle.com>
Date: Thu, 26 Aug 2010 16:23:24 +0200

On Aug 26, 2010, at 3:43 PM, Mark Birenbaum wrote:

> Oops, missed that detail. We're using the @Provider annotation.
>
> @Provider
> public class LocaleProvider
> implements InjectableProvider<Context, Type> {
> ...
>
> I figure it's probably some classloader issue and the LocaleProvider
> isn't being seen in the same context as jersey for some reason,
> although since we have it all as one big war file, I can't imagine
> what the issue would be. If it was broken in both environments I'd
> assume our configuration was messed up, but only broken in websphere
> makes me think there's some subtly to the way jersey looks for
> providers that I need to be concerned with.
>

I cannot recall exactly which version of Jersey but i do recall there
were some issues with scanning on WebSphere. They may have been
similar to those for WebLogic which were fixed in Jersey 1.1.5 and
Jersey 1.2).

What is your web.xml?

Paul.

>
>> From: Paul Sandoz <Paul.Sandoz_at_oracle.com>
>> To: users_at_jersey.dev.java.net
>> Date: Thu, 26 Aug 2010 10:31:52 +0200
>> Subject: Re: [Jersey] adding a @Context annotated parameter using
>> an InjectableProvider on Websphere
>> Hi Mark,
>>
>> How are you deploying and registering your LocaleProvider on
>> WebSphere?
>>
>> I suspect when you deploy on WebSphere the LocaleProvider is not
>> getting registered.
>>
>> Paul.
>>
>> On Aug 25, 2010, at 10:47 PM, Mark Birenbaum wrote:
>>
>>> We’ve added an InjectableProvider to our system to allow the
>>> addition
>>> of Locale to resource methods. Our provider looks like this:
>>>
>>>
>>>
>>> public class LocaleProvider
>>> implements InjectableProvider<Context, Type> {
>>>
>>> ...
>>> public Injectable<Locale> getInjectable(ComponentContext
>>> ic, Context
>>> a, Type c) { ...
>>>
>>>
>>> And our use of it looks like this:
>>>
>>> @GET
>>> @Produces(APPLICATION_JSON)
>>> public JSONArray getTasksAsJsonArray(@Context UriInfo
>>> uriInfo,
>>> @QueryParam("template") boolean isTemplate,
>>> @Context Locale locale)
>>> throws JSONException { ...
>>>
>>>
>>>
>>>
>>> Works great in tomcat. Blows up in websphere like this:
>>>
>>> Exception:
>>> com.sun.jersey.api.container.ContainerException: Method, public
>>> javax.ws.rs.core.Response
>>> com.bps.iproject.jersey.resources.TasksResource. getTasksAsJsonArray
>>> (javax.ws.rs.core.UriInfo,boolean,java.util.Locale), annotated with
>>> GET of resource, class
>>> com.bps.iproject.jersey.resources.TasksResource, is not recognized
>>> as
>>> valid Java method annotated with @HttpMethod.
>>> at
>>> com
>>> .sun
>>> .jersey
>>> .server
>>> .impl
>>> .model.method.ResourceHttpMethod.<init>(ResourceHttpMethod.java:92)
>>> at
>>> com
>>> .sun
>>> .jersey
>>> .server
>>> .impl
>>> .model.method.ResourceHttpMethod.<init>(ResourceHttpMethod.java:69)
>>> at
>>> com
>>> .sun
>>> .jersey
>>> .server
>>> .impl
>>> .model.ResourceClass.processSubResourceMethods(ResourceClass.java:
>>> 258)
>>> at
>>> com
>>> .sun
>>> .jersey.server.impl.model.ResourceClass.<init>(ResourceClass.java:
>>> 128)
>>> at
>>> com
>>> .sun
>>> .jersey
>>> .server
>>> .impl
>>> .application
>>> .WebApplicationImpl.newResourceClass(WebApplicationImpl.java:348)
>>> at
>>> com
>>> .sun
>>> .jersey
>>> .server
>>> .impl
>>> .application
>>> .WebApplicationImpl.getResourceClass(WebApplicationImpl.java:321)
>>> at
>>> com
>>> .sun
>>> .jersey
>>> .server
>>> .impl
>>> .application
>>> .WebApplicationImpl.processRootResources(WebApplicationImpl.java:
>>> 807)
>>> at
>>> com
>>> .sun
>>> .jersey
>>> .server
>>> .impl
>>> .application.WebApplicationImpl.initiate(WebApplicationImpl.java:
>>> 590)
>>> at
>>> com
>>> .sun
>>> .jersey
>>> .spi
>>> .spring
>>> .container.servlet.SpringServlet.initiate(SpringServlet.java:78)
>>> at com.sun.jersey.spi.container.servlet.ServletContainer
>>> $InternalWebComponent.initiate(ServletContainer.java:242)
>>> at
>>> com
>>> .sun
>>> .jersey.spi.container.servlet.WebComponent.load(WebComponent.java:
>>> 449)
>>> at
>>> com
>>> .sun
>>> .jersey.spi.container.servlet.WebComponent.init(WebComponent.java:
>>> 169)
>>> at
>>> com
>>> .sun
>>> .jersey
>>> .spi.container.servlet.ServletContainer.init(ServletContainer.java:
>>> 281)
>>> at
>>> com
>>> .sun
>>> .jersey
>>> .spi.container.servlet.ServletContainer.init(ServletContainer.java:
>>> 442)
>>> at javax.servlet.GenericServlet.init(GenericServlet.java:256)
>>> at
>>> com
>>> .ibm
>>> .ws.webcontainer.servlet.ServletWrapper.init(ServletWrapper.java:
>>> 227)
>>>
>>>
>>>
>>> If I change the Locale to one of the standard @Context options
>>> (i.e.,
>>> HttpServletRequest) I have no issues. So to work around this I'm
>>> changing all our methods that take Locale to take the request
>>> instead.
>>> But I would like to know what I'm doing wrong,.
>>>
>>> We're using spring and Jersey 1.0.3.
>>>
>>> Any thoughts?
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>