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>.
BTW, its true that ContextResolver came about to allow app developers
to supply a custom JAXBContext to the default JAXB provider. We
genericized (if that's a word) it since it seemed like it could useful
to other types of providers but its possible we obscured the original
intent when we did that.
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.