cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jervis Liu" <jervis...@gmail.com>
Subject Re: JAX-RS custom provider spring config
Date Fri, 08 Feb 2008 11:34:13 GMT
So based on what we have discussed so far, shall we agree on the followings?



1. We do not need a programmatic API or Spring configuration to configure
Providers. Instead, we need to do three enhancements:

a). Rather than hand-coded default (or pre-installed) providers that need to
initialized when CXF JAX-RS starts up, we need to enhance CXF so that CXF
can pick up all pre-installed providers from a dedicated directory.

b). CXF JAX-RS should scan a dedicated directory so that if a new custom
provider is installed or an old one is replaced in this directory, it should
be able to load the provider without rebooting the runtime.

c). The algorithm that decides which provider to use may need some updates
as well.



2. We need the ability to specify an explicit provider to use (probably
using annotations on the resource class or on the resource methods). This
feature is needed once we have more than one data binding providers, i.e.,
JAXBProvider and  AegisProvider etc.



Cheers,

Jervis


2008/2/8 Liu, Jervis <jliu@iona.com>:

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message