Re: JSR311: Re: ContextResolver removal

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Mon, 09 Jun 2008 17:38:35 +0200

Marc Hadley wrote:
> On Jun 9, 2008, at 10:24 AM, Bill Burke wrote:
>> Bill Burke wrote:
>>> It smells like a hack because of JAX-RS's current reliance on
>>> constructing providers and resources from raw classes rather than
>>> letting registering raw classes for Providers and Resources rather
>>> than allowing the application
>> Ugh, let me rewrite this so you can actually understand what I'm
>> trying to say :)
> Tx :-).
>> It smells like a hack because of JAX-RS's reliance on constructing
>> providers and resources from raw classes. Since EE has no real POJO
>> dependency injection you're forced to do hacky things like
>> ContextResolver to initialize and configure your providers/resources.
>> You don't need things like ContextResolver if application developers
>> have control over provider/resource instantiation.
>> For example, the RESTEasy Spring implementation allows you to define
>> JAX-RS annotation POJOs in spring XML and then registers the bean
>> instance with the RESTEASy JAX-RS runtime. For the JAXB
>> ContextResolver usecase described in the specification, this could
>> easily be implemented by letting the app-developer define @Providers
>> using a DI container like spring or Guice (I believe Web Beans could
>> help out with this too).
> But wouldn't that require an app developer to create a JAXB
> MessageBody[Reader|Writer] ? That seems like a much bigger job than
> writing a ContextResolver<JAXBContext>.

There are currently four different JAXB providers in Jersey: XML and
JSON for @XmlElement annotated objects and JAXBElement<T>. It will be
six when i include Fast Infoset. It will be 12 when i include support
for List<T> where T is a JAXB object.

The functionality is modular so that JSON, Fast Infoset or pluralization
dependencies are not required if they are not used.

I have found ContextResolver<JAXBContext> to be a very useful way to
configure JAXB related entity providers without the developer having to
rely on:

   1) the specifics of JAXB entity providers;

   2) whether such provides are shipped with a JAX-RS implementation or
      are shipped by some third party; and

   3) a specific IoC container.

I have not looked but my guess is the same mechanism could be useful for
XMLBeans or JiBX related configuration as well.


| ? + ? = To question
    Paul Sandoz