Re: JSR311: Re: ContextResolver removal

From: Bill Burke <>
Date: Mon, 09 Jun 2008 11:53:45 -0400

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>.

No. You, as a JAXB @Provider provider (JBoss, Sun, CXF, whoever) writes
a subclassable provider and/or a @Provider with JavaBean style
configuration options.

> 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.

I just think that ContextResolver came out as a result of JAX-RS
painting itself into a corner as far as component model and
configuration goes. Web Beans might be able to help us out here from a
standard EE perspective.


Bill Burke
JBoss, a division of Red Hat