cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin" <>
Subject Re: JAX-RS custom provider spring config
Date Fri, 08 Feb 2008 10:30:24 GMT
Hi there

Few more comments.

Jersey allows for external providers be picked up from a classpath using a ServiceProvider
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