Hi
On Sat, Apr 2, 2011 at 2:45 PM, [email protected] <[email protected]>wrote:
>
> **@PathParam refers to the BoundType, and not to the ValueType (so it e.g.
>>> tries to find a static valueOf() method in the BoundType); this actually
>>> makes no sense, and I think this bug is caused since the processing of
>>> PathParam normally not considers JAXB annotations, since JAXB is only one
>>> possible data binding for REST.
>>>
>>>
>> @PathParams refer to individual URI fragments, JAX-RS MessageBodyReaders
>> are
>> not involved during processing PathParams...
>>
>
> Imagine following annotated parameter:
>
> void methodA(@PathParam("id") @XmlJavaTypeAdapter(XoverY.class) X x) {
> doSomethingWith(x);
> }
>
>
> The expected semantics is that class Y is instantiated by e.g.
> Y.valueOf(id), then the XmlJavaTypeAdapter converts it to an instance of X.
> However the current implementation looks for a valueOf() method in class X
> and not class Y, it just not takes the XmlJavaTypeAdapter annotation into
> account. So I actually end up with a not very elegant workaround:
>
>
> void methodA(@PathParam("id") Y y) {
> X x = new XoverY().unmarshal(y);
> doSomethingWith(x);
> }
>
> I require this glue code in most of my REST methods, so the code looks not
> so nice as it could look, but nevertheless I consider it as a bug.
>
I consider it to be a restriction :-).
Currently you have two options with converting path vars into beans:
1.
void methodA(@PathParam("") Xover x) {
}
all the captured Path variables will be injected into Xover, example, if we
have a path variable 'id' then a Xover.setId method will be invoked.
2. Register a ParameterHandler (as a jaxrs:provider), ex,
XoverParameterHandler<Xover>
Hope it helps
Cheers, Sergey
