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 >
