On Tue, Apr 27, 2010 at 3:58 AM, Paul Sandoz [via Jersey]
<ml-node+4967419-2034341139-210534_at_n2.nabble.com> wrote:
> This is a limitation in Jersey. A resource class cannot be a provider.
OK; fair enough.
> Can you log an issue, as in this case Jersey should fail to deploy or
> log an error?
Will do.
> But i recommend separating out provider functionality from that of
> resources so you do not mix components that serve different purposes.
Obviously in almost all cases I agree with you; there are some odd
extenuating circumstances here that make it desirable to have as few
classes as possible. But that's fine; this is a case where we will
just have to introduce at least one more.
> 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.
I'm aware of that, and it's mainly due to frantic overworkedness (is
that a word?) on my part. Once this cools down a bit, I'll see if I
can put something together that explains what I'm trying to do in case
there's an obvious solution. Ordinarily, of course, we'd want to do
all of this in the reverse order!
> 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.
OK. I'm sure folks have gently nudged you in the direction of CDI for
dependency injection, and of course I understand with its late
adoption into the EE spec why you didn't have time to go that route.
> 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.
I actually got the whole thing working last night without having to
use Jersey-specific features. I simply rely on the presence,
somewhere, of lots of ContextResolver<Class> instances--that, very
importantly, can be located anywhere on the classpath--to offer up
what the concrete classes should be when abstract classes and
interfaces are encountered by my MBW. Then my MBW constructs a
JAXBContext out of the concrete classes, and everything comes out
fine.
Today I get to improve the performance.
Best,
Laird
--
View this message in context: http://jersey.576304.n2.nabble.com/Once-a-Resource-never-a-Provider-tp4967157p4968215.html
Sent from the Jersey mailing list archive at Nabble.com.