Thanks for the quick reply Paul. Please see my comments inline ..
On Wed, Jun 24, 2009 at 8:17 PM, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
> Hi Meeraj,
>
> Using a MessageBodyReader is not really the write place to do this.
>
> The quick solution, using Jersey specific stuff, do the following:
>
> @Path("/myResource")
> public MyResource {
> @GET
> public String myMethod(@Context ResourceContext rc) {
> CustomType ct = rc.get(CustomType.class);
> }
> }
Are there any convetions on CustomType? Also, can I annotate injection sites
within CustomType with @QueryParam, @PathParam etc?
>
>
> I have yet to implement injection directly for such cases, but it should
> not be hard to implement e.g.:
>
> @Path("/myResource")
> public MyResource {
> @GET
> public String myMethod(@InjectParam CustomType ct) {
> CustomType ct = rc.get(CustomType.class);
> }
> }
I prefer this to the first one, as this will maintain the semantic richness
of the service contract.
>
>
> It is also possible to plug in your own injection support for certain
> annotations, which is how the above would be implemented, deferring to
> ResourceContext. If you need more details on that, just say so, and i will
> write a very simple app to show you how it works.
That will be hugely helpful. I have been integrating Jersey with an OSS SCA
container, I have been working on. We use JAX-RS as an SCA binding, which
means most of the JAX-RS annotations go on the interface rather than the
implementation class. We pass a proxy to the interface to the Jersey runtime
using the IOC container provider and invocations on the proxy from the
Jersey runtime are tunnelled back into the SCA runtime. Hence the reason, I
am looking at parameter based injection and not field or method based
injection sites as the lifecycle of the implementation class is managed by
the SCA container.
>
>
> Form parameters are slightly different in that they can only be supported
> for a resource method that consumes a certain media type, so it would
> require slightly different support, there is an issue open to implement
> support form param beans.
Yeah, I thought so as well. However, a uniform mechanism that can deal with
query and form parameters would be great.
>
>
>
> Note that ideally what we require is really nice integration with Guice 2.0
> (or GuiceyFruit with appropriate extensions/modifications to Guice 2.0),
> then one should be able to inject all the JAX-RS/Jersey stuff "naturally".
>
> Paul.
>
>
> On Jun 24, 2009, at 8:07 PM, Meeraj Kunnumpurath wrote:
>
> Hi,
>>
>> I am trying to implement a custom parameter ninding, where I can map HTTP
>> query parameters, form parameters, http headers etc to a custom Java class.
>>
>> For eg, instead of having something below
>>
>> @Path("/myResource")
>> public MyResource {
>> @GET
>> public String myMethod(@QueryParam("foo") int foo, @HeaderParam("bar")
>> double bar) {
>> }
>> }
>>
>> have something like,
>>
>> @Path("/myResource")
>> public MyResource {
>> @GET
>> public String myMethod(@ComplexType CustomType customType) {
>> }
>> }
>>
>> public class CustomType {
>> @QueryParam("foo") protected int foo;
>> @HeaderParam("bar") protected double foo;
>> }
>>
>> @ComplexType is a custom annotation I have introduced. I thought one way
>> to do this was to introduce a custom message reader, and had some success in
>> getting it working. However, I have run into two issues,
>>
>> 1. If the HTTP method is set to GET, Jersey throws an error stating custom
>> entities are not allowed with GET
>> 2. The message reader interface provides access only to the HTTP headers
>> and the message body. So I cant access any query or path parameters.
>>
>> I would hugely appreciate if someone could please point me to what I am
>> doing wrong.
>>
>> Ta
>> Meeraj
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>