JAX-RS custom provider spring config

[Barry Fitzgerald <ba...@gmail.com>]

Hi,

Just wondering is it possible to register a custom provider to the server
using the spring config?

Thanks,

Barry

Re: JAX-RS custom provider spring config

[Barry Fitzgerald <ba...@gmail.com>]

Hi Jervis,

I think the specifying providers in the Spring config should be a
requirement. People may implement providers that are complex beans that
themselves need to be injected with properties - Off the top of my head  -
an xml provider that can be configured with a max tree depth or any bean
that relies on a environment settings.

Simply loading classes from a dedicated directory will not fulfil this
requirement.

While my patch will support the spring configuration it will also separate
the providers into two lists - user provided and default. Once this is done,
in the future the lists themselves could be populated by any required
method.

Therefore I think regardless of the eventual method/methods of populating
the lists this is a step in the right direction.

Barry


On Feb 8, 2008 11:46 AM, Sergey Beryozkin <se...@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.
>
> 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
>
> Cheers, Sergey
>
>
>
>
>
> ----- Original Message -----
> From: "Jervis Liu" <je...@gmail.com>
> To: <cx...@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 <jl...@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 <se...@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
>

Re: JAX-RS custom provider spring config

[Sergey Beryozkin <se...@iona.com>]

Hi Barry

You might want to do a backmerge as I also modified ProviderFactoryImpl...
Hence I was a bit concerned Jervis would pick up your patch earlier :-)

Cheers, Sergey

----- Original Message ----- 
From: "Barry Fitzgerald" <ba...@gmail.com>
To: <cx...@incubator.apache.org>
Sent: Friday, February 08, 2008 2:53 PM
Subject: Re: JAX-RS custom provider spring config


> Patch Added: https://issues.apache.org/jira/browse/CXF-1425
>
> Barry
>
> 2008/2/8 Jervis Liu <je...@gmail.com>:
>
>> On Feb 8, 2008 7:46 PM, Sergey Beryozkin <se...@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" <je...@gmail.com>
>> > To: <cx...@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 <jl...@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

Re: JAX-RS custom provider spring config

[Barry Fitzgerald <ba...@gmail.com>]

Patch Added: https://issues.apache.org/jira/browse/CXF-1425

Barry

2008/2/8 Jervis Liu <je...@gmail.com>:

> On Feb 8, 2008 7:46 PM, Sergey Beryozkin <se...@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" <je...@gmail.com>
> > To: <cx...@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 <jl...@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
> >
>

Re: CXF JAX-RS Provider for Aegis (Was: JAX-RS custom provider spring config)

[Daniel Kulp <dk...@apache.org>]

One of the issues you may run into with Aegis is that it doesn't really 
create root elements at all as part of it's schema generation.   It 
really just generates types.   The frontend has to handle the global 
element creation stuff.     That's partially why there isn't a 
@AegisXMLRootElement thing.

Dan

On Friday 08 February 2008, Sergey Beryozkin wrote:
> 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" <je...@gmail.com>
> To: <cx...@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 <se...@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" <je...@gmail.com>
> >> To: <cx...@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 <jl...@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
> >> >> > <se...@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



-- 
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog

Re: CXF JAX-RS Provider for Aegis (Was: JAX-RS custom provider spring config)

[Sergey Beryozkin <se...@iona.com>]

Ok...Lets have some annotation on a method

@ProduceMime("application/xml")
@Aegis
public Book getBook() {
}

alternatively we can say, as you suggested earlier :

@ProduceMime("application/xml")
@Provider("org.apache.cxf.jaxrs.AegisProvider")
public Book getBook() {
}

I kind of prefer the first option as it seems simpler for a user to apply, but perhaps the second option is something one can have standardized. 


Cheers, Sergey



----- Original Message ----- 
From: "Jervis Liu" <je...@gmail.com>
To: <cx...@incubator.apache.org>
Sent: Friday, February 08, 2008 12:58 PM
Subject: Re: CXF JAX-RS Provider for Aegis (Was: JAX-RS custom provider spring config)


> On Feb 8, 2008 8:37 PM, Sergey Beryozkin <se...@iona.com> wrote:
>
>> 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 ?
>
>
> Surely you can do this, but then you lost one of advantages of Aegis
> binding, which is "No annotations are needed to expose classes".
>
>
>>
>> Cheers, Sergey
>>
>>
>> ----- Original Message -----
>> From: "Jervis Liu" <je...@gmail.com>
>> To: <cx...@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 <se...@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" <je...@gmail.com>
>> >> To: <cx...@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 <jl...@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
>>
> 

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

Re: CXF JAX-RS Provider for Aegis (Was: JAX-RS custom provider spring config)

[Jervis Liu <je...@gmail.com>]

On Feb 8, 2008 8:37 PM, Sergey Beryozkin <se...@iona.com> wrote:

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


Surely you can do this, but then you lost one of advantages of Aegis
binding, which is "No annotations are needed to expose classes".


>
> Cheers, Sergey
>
>
> ----- Original Message -----
> From: "Jervis Liu" <je...@gmail.com>
> To: <cx...@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 <se...@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" <je...@gmail.com>
> >> To: <cx...@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 <jl...@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
>

CXF JAX-RS Provider for Aegis (Was: JAX-RS custom provider spring config)

[Sergey Beryozkin <se...@iona.com>]

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" <je...@gmail.com>
To: <cx...@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 <se...@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" <je...@gmail.com>
>> To: <cx...@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 <jl...@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 <se...@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

Re: JAX-RS custom provider spring config

[Jervis Liu <je...@gmail.com>]

On Feb 8, 2008 7:46 PM, Sergey Beryozkin <se...@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" <je...@gmail.com>
> To: <cx...@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 <jl...@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 <se...@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
>

Re: JAX-RS custom provider spring config

[Sergey Beryozkin <se...@iona.com>]

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.

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

Cheers, Sergey





----- Original Message ----- 
From: "Jervis Liu" <je...@gmail.com>
To: <cx...@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 <jl...@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 <se...@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

Re: JAX-RS custom provider spring config

[Jervis Liu <je...@gmail.com>]

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 <jl...@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 <se...@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
>

RE: JAX-RS custom provider spring config

["Liu, Jervis" <jl...@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 <se...@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

Re: JAX-RS custom provider spring config

[Sergey Beryozkin <se...@iona.com>]

Hi Barry

I think what you suggest would be the fastest way forward, and possibly the best one. 

This approach would have a global effect, that is all server endpoints will share the custom providers which is likely what would be required in most cases. We can think about optimizing it later on...

Thanks, Sergey 


----- Original Message ----- 
From: "Barry Fitzgerald" <ba...@gmail.com>
To: <cx...@incubator.apache.org>
Sent: Friday, February 08, 2008 10:50 AM
Subject: Re: JAX-RS custom provider spring config


> Hey Sergey,
> 
> I'm convinced! I was just sending an e-mail to say so!
> 
> However my usecase requires me to replace the default JSON providor with a
> badgerfish one.  So I'd like to discuss how to do  1 & 2.
> 
> The spec says:
> 
> "An implementation MUST support application-provided EntityProvider
> implementations and MUST
> use those in preference to its own pre-packaged EntityProvider
> 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 <se...@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

Re: JAX-RS custom provider spring config

[Barry Fitzgerald <ba...@gmail.com>]

Hey Sergey,

I'm convinced! I was just sending an e-mail to say so!

However my usecase requires me to replace the default JSON providor with a
badgerfish one.  So I'd like to discuss how to do  1 & 2.

The spec says:

"An implementation MUST support application-provided EntityProvider
implementations and MUST
use those in preference to its own pre-packaged EntityProvider
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 <se...@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
>

Re: JAX-RS custom provider spring config

[Sergey Beryozkin <se...@iona.com>]

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

Re: JAX-RS custom provider spring config

[Sergey Beryozkin <se...@iona.com>]

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

Re: JAX-RS custom provider spring config

[Sergey Beryozkin <se...@iona.com>]

Hi Barry

Lets move a discussion on
https://issues.apache.org/jira/browse/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 belive we should follow the same practice in this case.

As far as duplicates is concnerned : this is easy, lets just have a Set of full class names for individual providers. That would do for a start.

Thoughts ?

Cheers, Sergey




----- Original Message ----- 
From: "Beryozkin, Sergey" <Se...@iona.com>
To: <cx...@incubator.apache.org>
Sent: Thursday, February 07, 2008 1:20 PM
Subject: RE: JAX-RS custom provider spring config


Hi Barry

This would be a nice addition, so that a collection of providers can be
registered. 

Cheers, Sergey

-----Original Message-----
From: Barry Fitzgerald [mailto:barfitzgerald@gmail.com] 
Sent: 07 February 2008 12:29
To: cxf-user@incubator.apache.org
Subject: JAX-RS custom provider spring config

Hi,

Just wondering is it possible to register a custom provider to the
server
using the spring config?

Thanks,

Barry

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

RE: JAX-RS custom provider spring config

["Beryozkin, Sergey" <Se...@iona.com>]

Hi Barry

This would be a nice addition, so that a collection of providers can be
registered. 

Cheers, Sergey

-----Original Message-----
From: Barry Fitzgerald [mailto:barfitzgerald@gmail.com] 
Sent: 07 February 2008 12:29
To: cxf-user@incubator.apache.org
Subject: JAX-RS custom provider spring config

Hi,

Just wondering is it possible to register a custom provider to the
server
using the spring config?

Thanks,

Barry

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