cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin" <sergey.beryoz...@iona.com>
Subject CXF JAX-RS Provider for Aegis (Was: JAX-RS custom provider spring config)
Date Fri, 08 Feb 2008 12:37:20 GMT
Hi Jervis

Great, it's good that you agree as well...

I've started a new thread about what CXF JAX-RS can do to support alternative data binding
providers,
like Aegis.

Can we just introduce some annotation which would serve purely as a marker and which our JAX-RS
Aegis provider would recognize ?
Something like @AegisXMLRootElement ?

Cheers, Sergey


----- Original Message ----- 
From: "Jervis Liu" <jervisliu@gmail.com>
To: <cxf-dev@incubator.apache.org>
Sent: Friday, February 08, 2008 12:06 PM
Subject: Re: JAX-RS custom provider spring config


> On Feb 8, 2008 7:46 PM, Sergey Beryozkin <sergey.beryozkin@iona.com> wrote:
>
>> Hi Jervis
>>
>> This seems to be a bit complicated.
>> I think that Barry's proposal is simple and effective.
>>
>> I doubt that we need to put some information or jars for all the default
>> providers be picked up from some directory. That would be similar to the
>> earlier proposal to provide them all in a spring configuration. Lets have
>> defaut providers created as usual, on startup (or dynamically later on,
>> based on a given consume/produce type) and be kept in one map.
>>
>> Lets have custom providers be picked up from either a spring configuration
>> (Barry's patch) or from the classpath using a usual jar's ServiceProvider
>> mechanism (same way as Jersey, this is something we can add later on) and
>> kept them in a second map.
>>
>> Second map is checked first, first map with defaults is checked
>> afterwards. It just works.
>
>
> Agreed. Yes, this should work and it is simpler.
>
>
>>
>> About Aegis : it shoud have some sort of Aegis-specifoic annotations,
>> shouldn't it ? This annotation can server as a hint to an Aegis provider,
>> same was as @XMLRootElement serves as a hint to a JAXBProvider
>>
>
> Aegis binding does not need any annotations on its type class.
>
>>
>> Cheers, Sergey
>>
>>
>>
>>
>>
>> ----- Original Message -----
>> From: "Jervis Liu" <jervisliu@gmail.com>
>> To: <cxf-dev@incubator.apache.org>
>>  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 <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
>> >>
>> >
>>
>> ----------------------------
>> 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