Paul Sandoz wrote:
>
>
> 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.
>
Jersey implementation detail... Even in this case, it looks like
ContextResolver is going to have to support @ProduceMime, @ConsumeMime
as you might want a different JAXBContext for XML and JSON for the same
type. I'm sure there will be more usecases you'll find you'll need a
different @Provider SPI for.
> 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;
>
Untrue. You have to know that Jersey providers use ContextResolver to
obtain very specific configuration information.
> 2) whether such provides are shipped with a JAX-RS implementation or
> are shipped by some third party; and
>
ContextResolver solves this particular usecase portably, but what about
other types of configuration?
> 3) a specific IoC container.
>
Well, the beauty of IoC is that you don't need a container as you can
just hand code it yourself, which is why I suggested ApplicationConfig
have object based as well as class based methods.
> I have not looked but my guess is the same mechanism could be useful for
> XMLBeans or JiBX related configuration as well.
>
Sure, they could, but I'm also sure that @Providers will need other
types of injectable configurable information. We will end up
standardizing specific ad-hoc configuration mechanisms for those
different use cases too? Like for instance, maybe I want to inject
contextual information based on an annotation value. Maybe I want to
inject contextual information based on a specific header. Maybe I want
my org.w3c.Document @Provider to configurably turn off XML validation
based on schema type. Maybe I want a JAXB provider that caches based on
ETag and CacheControl settings and I want runtime control over that
cache. I hope you see what I'm getting at now.
Again, I believe Web Beans, Spring, or Guice is a better solution to
fill in these gaps here.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com