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
