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