cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin" <sergey.beryoz...@iona.com>
Subject Re: JAX-RS custom provider spring config
Date Fri, 08 Feb 2008 15:01:28 GMT
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" <barfitzgerald@gmail.com>
To: <cxf-dev@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 <jervisliu@gmail.com>:
>
>> On Feb 8, 2008 7:46 PM, Sergey Beryozkin <sergey.beryozkin@iona.com>
>> wrote:
>>
>> > Hi Jervis
>> >
>> > This seems to be a bit complicated.
>> > I think that Barry's proposal is simple and effective.
>> >
>> > I doubt that we need to put some information or jars for all the default
>> > providers be picked up from some directory. That would be similar to the
>> > earlier proposal to provide them all in a spring configuration. Lets
>> have
>> > defaut providers created as usual, on startup (or dynamically later on,
>> > based on a given consume/produce type) and be kept in one map.
>> >
>> > Lets have custom providers be picked up from either a spring
>> configuration
>> > (Barry's patch) or from the classpath using a usual jar's
>> ServiceProvider
>> > mechanism (same way as Jersey, this is something we can add later on)
>> and
>> > kept them in a second map.
>> >
>> > Second map is checked first, first map with defaults is checked
>> > afterwards. It just works.
>>
>>
>> Agreed. Yes, this should work and it is simpler.
>>
>>
>> >
>> > About Aegis : it shoud have some sort of Aegis-specifoic annotations,
>> > shouldn't it ? This annotation can server as a hint to an Aegis
>> provider,
>> > same was as @XMLRootElement serves as a hint to a JAXBProvider
>> >
>>
>> Aegis binding does not need any annotations on its type class.
>>
>> >
>> > Cheers, Sergey
>> >
>> >
>> >
>> >
>> >
>> > ----- Original Message -----
>> > From: "Jervis Liu" <jervisliu@gmail.com>
>> > To: <cxf-dev@incubator.apache.org>
>> >  Sent: Friday, February 08, 2008 11:34 AM
>> > Subject: Re: JAX-RS custom provider spring config
>> >
>> >
>> > > So based on what we have discussed so far, shall we agree on the
>> > followings?
>> > >
>> > >
>> > >
>> > > 1. We do not need a programmatic API or Spring configuration to
>> > configure
>> > > Providers. Instead, we need to do three enhancements:
>> > >
>> > > a). Rather than hand-coded default (or pre-installed) providers that
>> > need to
>> > > initialized when CXF JAX-RS starts up, we need to enhance CXF so that
>> > CXF
>> > > can pick up all pre-installed providers from a dedicated directory.
>> > >
>> > > b). CXF JAX-RS should scan a dedicated directory so that if a new
>> custom
>> > > provider is installed or an old one is replaced in this directory, it
>> > should
>> > > be able to load the provider without rebooting the runtime.
>> > >
>> > > c). The algorithm that decides which provider to use may need some
>> > updates
>> > > as well.
>> > >
>> > >
>> > >
>> > > 2. We need the ability to specify an explicit provider to use
>> (probably
>> > > using annotations on the resource class or on the resource methods).
>> > This
>> > > feature is needed once we have more than one data binding providers,
>> i.e
>> > .,
>> > > JAXBProvider and  AegisProvider etc.
>> > >
>> > >
>> > >
>> > > Cheers,
>> > >
>> > > Jervis
>> > >
>> > >
>> > > 2008/2/8 Liu, Jervis <jliu@iona.com>:
>> > >
>> > >> There are a couple of issues that are covered or not covered yet by
>> the
>> > >> spec. As Barry mentioned, the use case 1&2 are actually already
>> covered
>> > by
>> > >> the spec. I.e, the JAX-RS runtime should maintain a list of default
>> or
>> > >> pre-installed providers, for any custom providers installed by the
>> > users,
>> > >> they should be ordered before pre-installed providers. Please refer
>> to
>> > the
>> > >> spec on the algorithm of how a provider is selected.
>> > >>
>> > >> One case which is not covered by the spec I believe, is the ability
>> to
>> > >> explicitly specify a provider to use on the resource class or
>> resource
>> > >> method. For example, lets say we have two data binding Providers, one
>> > is
>> > >> JAXBProvider, one is AegisProvider. In some cases, I may need to say
>> > >> explicitly that I want to use Aegis binding to marshal/unmarshal all
>> my
>> > data
>> > >> types other than letting the jax-rs runtime to find the most
>> > appropriate
>> > >> provider for me.
>> > >>
>> > >> Cheers,
>> > >> Jervis
>> > >>
>> > >> > -----Original Message-----
>> > >> > From: Barry Fitzgerald [mailto:barfitzgerald@gmail.com]
>> > >> > Sent: 2008年2月8日 18:50
>> > >> > To: cxf-dev@incubator.apache.org
>> > >>  > Subject: Re: JAX-RS custom provider spring config
>> > >> >
>> > >> > Hey Sergey,
>> > >> >
>> > >> > implementations when either could
>> > >> > handle the same request."
>> > >> >
>> > >> > I therefore think the best way to handle this is for the
>> > providerfactory
>> > >> to
>> > >> > maintain two lists of providers - user defined and default.
>> > >> >
>> > >> > When deciding how to handle a request it first checks the user
>> > defined
>> > >> to
>> > >> > see if any of these match. If no user defined providers match
it
>> the
>> > >> falls
>> > >> > back to default list. I think this would handle both 1 & 2,
>> implement
>> > >> the
>> > >> > Spec correctly and would leave the spring syntax the same as I've
>> > >> discussed.
>> > >> >
>> > >> >
>> > >> > Whatcha think?
>> > >> >
>> > >> > Barry
>> > >> >
>> > >> > On Feb 8, 2008 10:30 AM, Sergey Beryozkin <
>> sergey.beryozkin@iona.com>
>> > >> > wrote:
>> > >> >
>> > >> > > Hi there
>> > >> > >
>> > >> > > Few more comments.
>> > >> > >
>> > >> > > Jersey allows for external providers be picked up from a
>> classpath
>> > >> using a
>> > >> > > ServiceProvider mechanism.
>> > >> > > If we compare that approach with using the spring configuration
>> to
>> > >> inject
>> > >> > > entity providers, then we can see these are
>> > >> > > just two different paths for external providers to get into
the
>> > >> runtime.
>> > >> > > In both cases there's really no need to specify all the entity
>> > >> providers
>> > >> > > (message body readers/writers as per the new api) which may
be
>> > needed
>> > >> > for a
>> > >> > > given application to function properly.
>> > >> > > As I said earlier, JAX-RS requires for a bunch of types like
>> > Response,
>> > >> > > JAXB-annotated ones, primitives, InputStream, Source, etc
be
>> > supported
>> > >> > out
>> > >> > > of the box and after it gets finalized we'll have a TCK which
>> will
>> > >> enforce
>> > >> > > that a given implementation does provide it all out of the
box.
>> > >> > > Thus, a given user should only worry about external providers
>> when
>> > >> none
>> > >> > of
>> > >> > > the shipped providers can go the job. In this case, requiring
a
>> > user
>> > >> to
>> > >> > > specify upfront a list of all the providers, including default
>> ones
>> > >> (which
>> > >> > > can be nested or indeed private classes not intended for
the
>> > >> publication),
>> > >> > > would be problematic IMHO. Among other things, it would limit
the
>> > >> > dynamism
>> > >> > > of a given application which can have new types/formats
>> introduced
>> > >> after
>> > >> > it
>> > >> > > has been started. I can also see users failing to specify
the
>> right
>> > >> list for
>> > >> > > a given application for the first few times and getting
>> frustrated.
>> > >> > >
>> > >> > > As far as adding external entity providers is concerned,
I
>> believe
>> > >> > > there're primarily two cases :
>> > >> > > 1. Runtime does not support the marshalling/unmarshalling
of a
>> > given
>> > >> > > custom type. In this case just specifying a custom provider's
>> name
>> > >> would
>> > >> > do
>> > >> > > (as in the Barry's proposed patch) and the instance would
be just
>> > >> added to
>> > >> > > the list of existing providers, the runtime will take care
of
>> > >> utilizing it,
>> > >> > > based on its ProduceMime/ConsumeMime annotations and its
support
>> > for
>> > >> > a given
>> > >> > > class type.
>> > >> > > 2. Customer is not happy how, say, a given default provider
works
>> > >> (that
>> > >> > > is, how, say, it's converted into/from text/plain
>> representations)
>> > and
>> > >> would
>> > >> > > like to replace it with its own highly optimized implementation.
>> > >> JAX-RS
>> > >> > > requires such custom providers be supported. IMHO, this is
not
>> the
>> > >> highest
>> > >> > > priority issue for the CXF JAX-RS at this moment of time,
but
>> it's
>> > >> something
>> > >> > > which need to be supported. How we do it I'm not sure yet,
we
>> could
>> > >> > > introspect providers properly at the start.
>> > >> > >
>> > >> > > For example, lets say we have a default File provider (for
all
>> > media
>> > >> types
>> > >> > > */*), as mandated by the spec, this provider just uses older
>> plain
>> > >> File
>> > >> > > input/output streams wrapped into readers/writers. Customer
wants
>> > to
>> > >> > replace
>> > >> > > it with a nio-based implementation. At the start-up we can
check
>> > the
>> > >> > > annotations for a given custom provider class and check if
its
>> > >> instance
>> > >> > > supports any of the types already supported by the runtime
and if
>> > yes
>> > >> then,
>> > >> > > for a given JAX-RS server endpoint, assume that a custom
provider
>> > >> needs
>> > >> > to
>> > >> > > take charge... or perhaps just replace the default instance
which
>> > will
>> > >> have
>> > >> > > a global effect for al lthe endpoints. Something like that.
>> > >> > >
>> > >> > > Barry, have I convinced you :-) ? Would you be happy for
your
>> patch
>> > to
>> > >> > > address an issue 1 above for a start but such that no replacement
>> > >> > happens ?
>> > >> > >
>> > >> > > Thanks, Sergey
>> > >> > >
>> > >> > >
>> > >> > >
>> > >> > >
>> > >> > >
>> > >> > > Hi Barry
>> > >> > >
>> > >> > > Lets move a discussion on CXF-1425 to this list.
>> > >> > >
>> > >> > > In summary,
>> > >> > > we're discussing with Barry whether a list of JAX-RS Entity
>> > Providers
>> > >> > > (which know how to marshal/unmarshal given types) as
>> > >> > > configured in a given spring xml, should override a default
list
>> or
>> > >> not.
>> > >> > >
>> > >> > > IMHO it should not be the case. It would put a strain on
users.
>> > Users
>> > >> do
>> > >> > > not need to know about the fact that a given Book class
>> > >> > > will only be marshalled if a JAXB-aware provider is installed.
If
>> a
>> > >> given
>> > >> > > set of returned types is large then it will get
>> > >> > > complicated. User just need to know about the content type,
>> > >> > XMLRootElement
>> > >> > > and similar things. Users do not need to know about class
>> > >> > > names for individual default providers, this will form some
sort
>> of
>> > a
>> > >> > > contract between a runtime and a user thus making it more
>> > >> > > difficult for us to change the things under the hood.
>> > >> > >
>> > >> > > For example, we can configure a Jetty handler, say we can
add a
>> > Jetty
>> > >> > > handler. When doing it we do not need to specify all other
>> > >> > > types of handlers jetty may've set up under the hood. I believe
>> we
>> > >> should
>> > >> > > follow the same practise in this case.
>> > >> > >
>> > >> > > As far as duplicates is conncerned : this is easy, lets just
have
>> a
>> > >> Set of
>> > >> > > full class names for individual providers. That would do
>> > >> > > for a start.
>> > >> > >
>> > >> > > Thoughts ?
>> > >> > >
>> > >> > > Cheers, Sergey
>> > >> > >
>> > >> > > ----------------------------
>> > >> > > IONA Technologies PLC (registered in Ireland)
>> > >> > > Registered Number: 171387
>> > >> > > Registered Address: The IONA Building, Shelbourne Road, Dublin
4,
>> > >> Ireland
>> > >> > >
>> > >> > > ----------------------------
>> > >> > > IONA Technologies PLC (registered in Ireland)
>> > >> > > Registered Number: 171387
>> > >> > > Registered Address: The IONA Building, Shelbourne Road, Dublin
4,
>> > >> Ireland
>> > >> > >
>> > >>
>> > >> ----------------------------
>> > >> IONA Technologies PLC (registered in Ireland)
>> > >> Registered Number: 171387
>> > >> Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
>> > Ireland
>> > >>
>> > >
>> >
>> > ----------------------------
>> > IONA Technologies PLC (registered in Ireland)
>> > Registered Number: 171387
>> > Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
>> Ireland
>> >
>>
> 

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