cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Liu, Jervis" <j...@iona.com>
Subject RE: JAX-RS custom provider spring config
Date Fri, 08 Feb 2008 11:14:09 GMT
There are a couple of issues that are covered or not covered yet by the spec. As Barry mentioned,
the use case 1&2 are actually already covered by the spec. I.e, the JAX-RS runtime should
maintain a list of default or pre-installed providers, for any custom providers installed
by the users, they should be ordered before pre-installed providers. Please refer to the spec
on the algorithm of how a provider is selected.

One case which is not covered by the spec I believe, is the ability to explicitly specify
a provider to use on the resource class or resource method. For example, lets say we have
two data binding Providers, one is JAXBProvider, one is AegisProvider. In some cases, I may
need to say explicitly that I want to use Aegis binding to marshal/unmarshal all my data types
other than letting the jax-rs runtime to find the most appropriate provider for me. 

Cheers,
Jervis

> -----Original Message-----
> From: Barry Fitzgerald [mailto:barfitzgerald@gmail.com]
> Sent: 2008年2月8日 18:50
> To: cxf-dev@incubator.apache.org
> Subject: Re: JAX-RS custom provider spring config
> 
> Hey Sergey,
> 
> implementations when either could
> handle the same request."
> 
> I therefore think the best way to handle this is for the providerfactory to
> maintain two lists of providers - user defined and default.
> 
> When deciding how to handle a request it first checks the user defined to
> see if any of these match. If no user defined providers match it the falls
> back to default list. I think this would handle both 1 & 2, implement the
> Spec correctly and would leave the spring syntax the same as I've discussed.
> 
> 
> Whatcha think?
> 
> Barry
> 
> On Feb 8, 2008 10:30 AM, Sergey Beryozkin <sergey.beryozkin@iona.com>
> wrote:
> 
> > Hi there
> >
> > Few more comments.
> >
> > Jersey allows for external providers be picked up from a classpath using a
> > ServiceProvider mechanism.
> > If we compare that approach with using the spring configuration to inject
> > entity providers, then we can see these are
> > just two different paths for external providers to get into the runtime.
> > In both cases there's really no need to specify all the entity providers
> > (message body readers/writers as per the new api) which may be needed
> for a
> > given application to function properly.
> > As I said earlier, JAX-RS requires for a bunch of types like Response,
> > JAXB-annotated ones, primitives, InputStream, Source, etc be supported
> out
> > of the box and after it gets finalized we'll have a TCK which will enforce
> > that a given implementation does provide it all out of the box.
> > Thus, a given user should only worry about external providers when none
> of
> > the shipped providers can go the job. In this case, requiring a user to
> > specify upfront a list of all the providers, including default ones (which
> > can be nested or indeed private classes not intended for the publication),
> > would be problematic IMHO. Among other things, it would limit the
> dynamism
> > of a given application which can have new types/formats introduced after
> it
> > has been started. I can also see users failing to specify the right list for
> > a given application for the first few times and getting frustrated.
> >
> > As far as adding external entity providers is concerned, I believe
> > there're primarily two cases :
> > 1. Runtime does not support the marshalling/unmarshalling of a given
> > custom type. In this case just specifying a custom provider's name would
> do
> > (as in the Barry's proposed patch) and the instance would be just added to
> > the list of existing providers, the runtime will take care of utilizing it,
> > based on its ProduceMime/ConsumeMime annotations and its support for
> a given
> > class type.
> > 2. Customer is not happy how, say, a given default provider works (that
> > is, how, say, it's converted into/from text/plain representations) and would
> > like to replace it with its own highly optimized implementation. JAX-RS
> > requires such custom providers be supported. IMHO, this is not the highest
> > priority issue for the CXF JAX-RS at this moment of time, but it's something
> > which need to be supported. How we do it I'm not sure yet, we could
> > introspect providers properly at the start.
> >
> > For example, lets say we have a default File provider (for all media types
> > */*), as mandated by the spec, this provider just uses older plain File
> > input/output streams wrapped into readers/writers. Customer wants to
> replace
> > it with a nio-based implementation. At the start-up we can check the
> > annotations for a given custom provider class and check if its instance
> > supports any of the types already supported by the runtime and if yes then,
> > for a given JAX-RS server endpoint, assume that a custom provider needs
> to
> > take charge... or perhaps just replace the default instance which will have
> > a global effect for al lthe endpoints. Something like that.
> >
> > Barry, have I convinced you :-) ? Would you be happy for your patch to
> > address an issue 1 above for a start but such that no replacement
> happens ?
> >
> > Thanks, Sergey
> >
> >
> >
> >
> >
> > Hi Barry
> >
> > Lets move a discussion on CXF-1425 to this list.
> >
> > In summary,
> > we're discussing with Barry whether a list of JAX-RS Entity Providers
> > (which know how to marshal/unmarshal given types) as
> > configured in a given spring xml, should override a default list or not.
> >
> > IMHO it should not be the case. It would put a strain on users. Users do
> > not need to know about the fact that a given Book class
> > will only be marshalled if a JAXB-aware provider is installed. If a given
> > set of returned types is large then it will get
> > complicated. User just need to know about the content type,
> XMLRootElement
> > and similar things. Users do not need to know about class
> > names for individual default providers, this will form some sort of a
> > contract between a runtime and a user thus making it more
> > difficult for us to change the things under the hood.
> >
> > For example, we can configure a Jetty handler, say we can add a Jetty
> > handler. When doing it we do not need to specify all other
> > types of handlers jetty may've set up under the hood. I believe we should
> > follow the same practise in this case.
> >
> > As far as duplicates is conncerned : this is easy, lets just have a Set of
> > full class names for individual providers. That would do
> > for a start.
> >
> > Thoughts ?
> >
> > Cheers, Sergey
> >
> > ----------------------------
> > IONA Technologies PLC (registered in Ireland)
> > Registered Number: 171387
> > Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
> >
> > ----------------------------
> > IONA Technologies PLC (registered in Ireland)
> > Registered Number: 171387
> > Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
> >

----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Mime
View raw message