Hi Laird,
This is a limitation in Jersey. A resource class cannot be a provider.
Can you log an issue, as in this case Jersey should fail to deploy or
log an error?
If you want to avoid having multiple class files you can do:
@Path("/")
public class MyResource {
@Provider
public static class MyResolver implements ContextResolver<Foo> {
...
}
}
But i recommend separating out provider functionality from that of
resources so you do not mix components that serve different purposes.
BTW if you shared more of the code, i know i keep hassling you about
that!, i could have identified potentially issues faster for you.
My apologies for leading you a bit around the houses w.r.t. general
MBWs. The situation is a little complex and to do this properly i
think we need to fix a couple of things in the JAX-RS spec.
One solution that would make this a lot clearer, but require a Jersey
specific feature, is to use a Jersey resource filter [1] to adapt the
response entity to a specific wrapper type that is supported by a
specific MBW.
Paul.
On Apr 27, 2010, at 2:22 AM, Laird Nelson wrote:
> I am still doggedly on the trail of getting JAXB to do what I want.
>
> After some earlier messages on this list, I moved my
> ContextResolver<Class> implementation out of an EJB bean class and
> into an existing resource class. I don't want to create more classes
> unless I have to.
>
> It looks like I have to. My resource class is discovered at
> deployment time as a resource, but not as a ContextResolver<Class>
> (even though it's annotated with the @Provider annotation.
>
> Is it true that if you have a resource class, then that resource class
> cannot also be a context provider? Or is there yet another mystery in
> JAX-RS dependency injection going on?
>
> Thanks,
> Laird
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>