On Sun, Sep 15, 2013 at 6:09 PM, <TheCuriousOne_at_centrum.cz> wrote:
> Well, I'm not sure what you mean. Doing "@HeaderParam @MyAnnotation
> Integer providedValue" does not resolve the issue and even if it did, it
> would be preferable (and make more sense) if @MyAnnotation be "header
> param" by default, but I do not know how I could accomplish that.
>
I meant that you should annotate like in example 3.14 (using a BeanParam):
https://jersey.java.net/documentation/latest/jaxrs-resources.html#d0e1433
That shouldn't require any special resolvers, and makes use of @HeaderParam.
In your example the resolver is not scoped to the request, so there is no
http request\servlet context.
Binding has changed in Jersey 2, so i have been following the migration
guide:
https://jersey.java.net/documentation/latest/migration.html#mig-server-inject-custom-objects
But, my point was - you need to let Jersey know that your looking for a
http header as parameter, otherwise (and after you setup a *PerRequest*
binding) by default it will attempt to resolve from the message body.
HTH,
Cam
> ______________________________________________________________
> > Od: Cameron Jones <cmhjones_at_gmail.com>
> > Komu: <users_at_jersey.java.net>
> > Datum: 03.09.2013 13:35
> > Předmět: [Jersey] Re: Custom InjectionResolver and “A HTTP GET method …
> should not consume any entity”
> >
> >Where do you specify that it's a header parameter? I think you need to
> >either annotate with @HeaderParam, @BeanParam or @Context depending on how
> >you want it to be configured...the default with no contextual annotations
> >will attempt to resolve from the message entity body.
> >
> >http://jersey.java.net/documentation/latest/jaxrs-resources.html#d0e1461
> >
> >Cam
> >
> >
> >On Mon, Sep 2, 2013 at 9:12 AM, <TheCuriousOne_at_centrum.cz> wrote:
> >
> >> Hi, thanks for taking your time to reply. I actually only need to access
> >> the headers for my purposes (imagine something like basic auth). And in
> the
> >> provided example I do not access the request at all.
> >>
> >> >You might want to have a look at this SO:
> >> >
> >> >http://stackoverflow.com/questions/978061/http-get-with-request-body
> >> >
> >> >Without trying your gist, i would expect that as HTTP defines GET body
> as
> >> >non-semantic (should not affect response) then Jersey is not parsing it
> >> >(unnecessary overhead). As stated within the SO, this is the conforming
> >> >HTTP definition, and while you are free to parse the body yourself, it
> has
> >> >no meaning within the wider HTTP ecosystem (so no
> tools\caching\support).
> >> >You will be making a purely independent system and forgoing the
> >> >interoperability expected with the protocol.
> >> >
> >> >What exactly is your purpose for using a body with GET? You won't have
> >> >caching working, so where is the benefit over using POST?
> >> >
> >> >Cam
> >> >
> >> >
> >> >On Fri, Aug 30, 2013 at 10:49 AM, <TheCuriousOne_at_centrum.cz> wrote:
> >> >
> >> >> Hello guys, I run into a problem when I was trying to implement my
> own
> >> >> InjectionResolver for my custom annotation. I have asked about it [1]
> >> on SO
> >> >> already, but did not receive any answer yet. This is the code [2]
> that
> >> >> exhibits the problem. The issue is already described in detail in
> the SO
> >> >> post, but to summarize:
> >> >>
> >> >> 1. When I use the custom annotation in a resource method, I get:
> >> "WARNING:
> >> >> The following warnings have been detected: WARNING: A HTTP GET
> method,
> >> >> public java.lang.String
> >> >> com.example.MyResource.get02(java.lang.Integer,java.lang.String),
> should
> >> >> not consume any entity."
> >> >>
> >> >> 2. The resolver's "resolve" method is never executed.
> >> >>
> >> >> 3. The (annotated) parameter the resolver should bind to is null.
> >> >>
> >> >> I would be thankful for any and all input.
> >> >>
> >> >> Cheers.
> >> >>
> >> >> [1]:
> >> >>
> >>
> http://stackoverflow.com/questions/18488622/jersey-2-custom-injectionresolver-and-a-http-get-method-should-not-consu
> >> >> [2]: https://gist.github.com/anonymous/389e1e8064174bdcd102
> >> >>
> >> >
> >>
> >
>