On Apr 27, 2010, at 2:07 PM, ljnelson wrote:
> On Tue, Apr 27, 2010 at 3:58 AM, Paul Sandoz [via Jersey]
> <[hidden email]> 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.
>
Thanks.
> > 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!
>
OK!
> > 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.
>
In this case i think you are the first to really push the MBWs in this
way :-)
We have used MBWs that call other MBWs, for example, JSONWithPadding,
the case of handling empty entities with EntityHolder, Multipart form-
data support and Atom support. But those MBWs were never as generic as
you require.
> > 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.
>
Wow!
> Today I get to improve the performance.
>
JAXBContext classes are very expensive to create, so caching them will
help. Note that Marshaler and Unmarshaler instances are not thread
safe, so you can only cache those in thread local variables.
In general i think there could be lots of improvements to JAXB to
enable better use/reuse/introspection of contexts.
Paul.