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
>>
>>
>