Cheers, Sergey
----- Original Message -----
From: "Jervis Liu" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, February 08, 2008 11:34 AM
Subject: Re: JAX-RS custom provider spring config
> 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 <[EMAIL PROTECTED]>:
>
>> 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:[EMAIL PROTECTED]
>> > Sent: 2008年2月8日 18:50
>> > To: [email protected]
>> > 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 <[EMAIL PROTECTED]>
>> > 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
>>
>
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
