2010/8/29 Alexandru Popescu ☀ <the.mindstorm.mailinglist_at_gmail.com>:
> Hi,
>
> I learn that there have been some improvements in the Guice
> integration in the last Jersey release. Unfortunately I need to stay
> with Jersey 1.2 due to the 1.5 requirement. Anyways, here are my two
> questions:
>
> 1. are there any major reasons for the current Guice integration not
> to work with Jersey 1.2?
> 2. what exactly are the current limitations?
>
> All I could find about this have been published on Paul's blog, but
> I'm worried if that is the complete information. For example, this
> part is not at all clear: " Unfortunately due to Guice's restriction
> in binding it is not currently possible to support the @*Params in the
> same manner. "
>
After digging through the code I just wanted to partially answer
myself some of the questions:
1. it looks like using jersey-guice 1.3 with jersey 1.2 will not work
out of box, mainly because of the new WebApplication.getProviders. On
this note, I think it would be tremendously useful to use the @since
javadoc to mark new API.
2. while I think I understand how the integration works there are
still a couple of questions:
Guice seems to be configured to server everything through
GuiceContainer. That raises the questions:
- how can you bypass Jersey for some requests (say static resources, etc.)
- how can you configure Jersey template engine
My feeling is that this is still possible by replacing in
GuiceServletContextListener:
serve("/*").with(GuiceContainer.class)
with:
serve("/*").with(GuiceContainer.class, /* Map<String, String>*/ params)
where params will contain the configuration that you'd otherwise pass
to ServletContainer
Can anyone confirm this?
3. A part that is still unclear is Paul's quote above related to
@*Params. If someone would be able to clarify it, I think that would
be great.
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
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.
tia,
:- alex