cxf-dev mailing list archives

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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message