Patch Added: https://issues.apache.org/jira/browse/CXF-1425
Barry 2008/2/8 Jervis Liu <[EMAIL PROTECTED]>: > 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 > > >
