users@jersey.java.net

Re: [Jersey] Re: Jersey 1.2 and Guice

From: Alexandru Popescu ☀ <the.mindstorm.mailinglist_at_gmail.com>
Date: Tue, 31 Aug 2010 23:50:25 +0300

Trying to run the tests I'm always seen this error:

SEVERE: service exception:
com.sun.jersey.api.container.ContainerException: No WebApplication
provider is present
        at com.sun.jersey.spi.container.WebApplicationFactory.createWebApplication(WebApplicationFactory.java:66)
        at com.sun.jersey.spi.container.servlet.ServletContainer.create(ServletContainer.java:351)
        at com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.create(ServletContainer.java:266)
        at com.sun.jersey.spi.container.servlet.WebComponent.load(WebComponent.java:564)
        at com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:211)
        at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:333)
        at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:497)
        at javax.servlet.GenericServlet.init(GenericServlet.java:242)
        at com.google.inject.servlet.ServletDefinition.init(ServletDefinition.java:83)
        at com.google.inject.servlet.ManagedServletPipeline.init(ManagedServletPipeline.java:84)
        at com.google.inject.servlet.ManagedFilterPipeline.initPipeline(ManagedFilterPipeline.java:106)
        at com.google.inject.servlet.GuiceFilter.init(GuiceFilter.java:168)
        at com.sun.grizzly.http.servlet.FilterChainImpl.init(FilterChainImpl.java:116)
        at com.sun.grizzly.http.servlet.ServletAdapter.loadServlet(ServletAdapter.java:431)
        at com.sun.grizzly.http.servlet.ServletAdapter.doService(ServletAdapter.java:367)
        at com.sun.grizzly.http.servlet.ServletAdapter.service(ServletAdapter.java:324)
        at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:166)
        at com.sun.grizzly.tcp.http11.GrizzlyAdapterChain.service(GrizzlyAdapterChain.java:180)
        at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:166)
        at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:791)
        at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693)
        at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954)
        at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:170)
        at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
        at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
        at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
        at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
        at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
        at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
        at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
        at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:330)
        at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:309)
        at java.lang.Thread.run(Thread.java:613)

Must confess I have no idea what's the real root cause of it :-(.

:- alex

2010/8/31 Alexandru Popescu ☀ <the.mindstorm.mailinglist_at_gmail.com>:
> Just a quick update: I've got the backport to compile. But there are
> many changes to multiple parts of jersey so I'm a bit torn apart on
> what to do.
>
> jersey-core
>
> com/sun/jersey/core/header/MediaTypes.java
> com/sun/jersey/core/spi/component/ProviderServices
>
> com/sun/jersey/spi/inject/ConstrainedTo.java
> com/sun/jersey/spi/inject/ConstrainedToType.java
> com/sun/jersey/spi/inject/Errors.java
> com/sun/jersey/spi/inject/ServerSide.java
>
>
> jersey-server:
>
> com/sun/jersey/server/impl/model/ResourceUriRules.java
> com/sun/jersey/server/impl/model/RulesMap.java
>
> com/sun/jersey/server/impl/model/method/ResourceMethod.java
> com/sun/jersey/api/model/AbstractResourceMethod.java
>
> com/sun/jersey/server/impl/application/RootResourceUriRules.java
> com/sun/jersey/server/impl/application/WebApplicationImpl.java
> com/sun/jersey/server/impl/application/WebApplicationContext.java
> com/sun/jersey/server/impl/application/DeferredResourceConfig.java
>
> com/sun/jersey/spi/container/WebApplication.java
>
> :- alex
>
> 2010/8/31 Alexandru Popescu ☀ <the.mindstorm.mailinglist_at_gmail.com>:
>> Thanks Paul. I'll actually try to port the whole module. My plan is
>> quite simple:
>>
>> - make a list of the dependencies in the jersey-guice 1.3
>> - diff those against their correspondents in jersey-1.2
>>
>> Hopefully that will work... but I'll give it a try first.
>>
>> :- alex
>>
>> On Tue, Aug 31, 2010 at 1:17 PM, Paul Sandoz <Paul.Sandoz_at_oracle.com> wrote:
>>> Hi Alex,
>>>
>>> That is a useful summary, thanks for writing this up.
>>>
>>> Sorry that the Jersey switch from SE 5 to SE 6 is causing some pain :-(
>>>
>>> I think you may be able to port 99% of the 1.3 Guice code to SE 5 and Jersey
>>> 1.2. The exception is that you will not be able to define a provider method
>>> for the binding of javax.ws.rs.ext.Providers as that is not accessible from
>>> 1.2 WebApplication [*], which amounts to the removal of about 4 lines of
>>> code from JerseyServletModule.
>>>
>>> Paul.
>>>
>>> [*] BTW i updated the @since JavaDoc on WebApplication
>>>
>>>
>>> On Aug 31, 2010, at 11:05 AM, Alexandru Popescu ☀ wrote:
>>>
>>>> Hi,
>>>>
>>>> As I've promised I've condensed all my research and the answers in
>>>> this thread to a post:
>>>>
>>>> http://jots.mypopescu.com/post/1041538385/jersey-and-guice-integration
>>>>
>>>> If someone could please review it, it would be great. I don't want to
>>>> publish any more confusing info about this subject :-).
>>>>
>>>> :- alex
>>>>
>>>> On Mon, Aug 30, 2010 at 12:26 PM, Paul Sandoz <Paul.Sandoz_at_oracle.com>
>>>> wrote:
>>>>>
>>>>> On Aug 30, 2010, at 11:16 AM, Alexandru Popescu ☀ wrote:
>>>>>
>>>>>>>> 4. A new question that arose while looking at the jersey-guice in 1.3
>>>>>>>> and the sample code is: who is actually injecting the values.
>>>>>>>>
>>>>>>>> The PerRequestResource is defined as:
>>>>>>>>
>>>>>>>> [code]
>>>>>>>> @Path("bound/perrequest")
>>>>>>>> @RequestScoped
>>>>>>>> public class PerRequestResource {
>>>>>>>>
>>>>>>>>  @Context UriInfo ui;
>>>>>>>>
>>>>>>>>  @QueryParam("x") String x;
>>>>>>>>
>>>>>>>>  private final SingletonComponent sc;
>>>>>>>>
>>>>>>>>  @Inject
>>>>>>>>  public PerRequestResource(SingletonComponent sc) {
>>>>>>>>     this.sc = sc;
>>>>>>>>  }
>>>>>>>>
>>>>>>>> }
>>>>>>>> [/code]
>>>>>>>>
>>>>>>>> While it is clear that Guice will manage the lifecycle of this
>>>>>>>> resource (per request) and will inject the SingletonComponent through
>>>>>>>> the constructor, it is not clear who will provide @Context UriInfo and
>>>>>>>> @QueryParam("x") String
>>>>>>>>
>>>>>>>
>>>>>>> Guice will inject everything related to @Inject. Jersey will inject
>>>>>>> everything related to the JAX-RS annotations. Basically after Guice
>>>>>>> instantiates and injects Jersey will have a go injecting.
>>>>>>>
>>>>>>>
>>>>>>>> I know this mail got really long, so I apologize in advance for the
>>>>>>>> effort to go through it while still hoping to get some help from the
>>>>>>>> more experienced people on the list.
>>>>>>>>
>>>>>>>
>>>>>>> Np, hth,
>>>>>>> Paul.
>>>>>>
>>>>>>
>>>>>> To see if I got this right: the only limitation of the current
>>>>>> integration is that you cannot use both @Inject and @*Param on
>>>>>> constructors, methods or fields. Is this correct?
>>>>>
>>>>> Yes, in the sense that Jersey cannot tell Guice how to provide bindings
>>>>> for
>>>>> such @*Param annotated types.
>>>>>
>>>>> Ideally i would like Jersey to provide all bindings to Guice. Then it
>>>>> would
>>>>> not be necessary for Jersey to inject after Guice has instantiated and
>>>>> injected.
>>>>>
>>>>>
>>>>>> If so, I'll give it
>>>>>> a try to see if it really is a limitation or you can easily work
>>>>>> around it.
>>>>>>
>>>>>
>>>>> The main limitation i have found is one cannot use constructor injection
>>>>> with @*Param annotated types. Which is a shame since it is recommended to
>>>>> utilize constructor injection whenever possible.
>>>>>
>>>>>
>>>>>> I'll make sure I'll study all the links you've provided.
>>>>>>
>>>>>> thanks so much,
>>>>>>
>>>>>
>>>>> Np,
>>>>> Paul.
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>
>>>
>>
>