cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Barry Fitzgerald" <>
Subject Re: JAX-RS custom provider spring config
Date Fri, 08 Feb 2008 10:50:04 GMT
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?


On Feb 8, 2008 10:30 AM, Sergey Beryozkin <> 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

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