Hi Sounds good. Have a look, say, at BinaryProvider unit test or at one of the atom providers tests, jaxb providers are poorly unit tested at the moment. Other providers tests might have some useful test methods too.
The things to unit test is that MessageBodyReader.isReadable and MessageBodyWriter.isWriteable can return true/false as expected, and they can readFrom/writeTo input streams. There's also a quite involved JAXBClientServerBookTest. Let me know please when you're ready to start writing a system test and we'll create an Aegis version of this test (will be mostly copy/paste), but we'll additionally register AegisProvider using Spring so that it can take precedence over the default JAXB provider which handles application/xml... Cheers, Sergey -----Original Message----- From: Benson Margulies [mailto:[EMAIL PROTECTED] Sent: 14 October 2008 12:50 To: dev@cxf.apache.org Subject: Re: Aegis versus jaxrs I appreciate the cache. However, the minimum number of contexts is the number of packages! A property that takes a context object would, however, solve all of this for both Aegis and JAXB, so I'm excited. Can you tell me how to make a unit test for my Aegis stuff? On Tue, Oct 14, 2008 at 3:46 AM, Sergey Beryozkin <[EMAIL PROTECTED]> wrote: > Hi, > > Same with the JAX-RS JAXB (and JAXB based JSON) provider - contexts are > cached and can be reused. > If ObjectFactory is available then only a single context will be > created. > At the moment, either a class name or just a package name can serve as a > key in the (two) maps of contexts. > May be for Aegis it's possible to have another key type to have a > context with a scope which wide enough. > Sure, you can do bean-ish properties too. I guess an Aegis provider will > have to be an optional one, otherwise it'll 'clash' with the default > JAXB one (both will serve media types like application/xml). Thus it > will have to be specified as a bean class in the spring config. > Perhaps you can support both options - map of properties and bean-ish > properties. > > Cheers, Sergey > > -----Original Message----- > From: Benson Margulies [mailto:[EMAIL PROTECTED] > Sent: 14 October 2008 01:00 > To: dev@cxf.apache.org; Daniel Kulp > Subject: Re: Aegis versus jaxrs > > OK, now we reach the crux of the matter. JAX-RS creates lots of > JAXBContexts, where 'normal' CXF manages to share one through an > entire service. Am I getting the idea that this is just an inescapable > aspect of the architecture? It could get slow. > > Aegis is just like JAXB. I could create a set of named properties for > the corresponding Aegis options, and add a call like you propose for > JAXB. But now we're going to have scads of Aegis objects. > > In either case, is there any way for the app creator to use Spring > configuration to set all this stuff up? And are we really thrilled to > have it all as (mistake-prone?) name-value pairs, instead of specific > bean-ish properties? > > I've attempted to drag Dan into this discussion so that he can tell me > to stop worrying. > > > On Mon, Oct 13, 2008 at 9:26 AM, Sergey Beryozkin > <[EMAIL PROTECTED]> wrote: >> Hi Benson >> >> Lets add AbstractJAXBProvider.setContextProperties(Map<String, > Object>) >> and pass those props to the JAXBContext creation calls. If none is >> explicitly passed from Spring then a default empty Map can be used >> instead. In fact, I just removed that code in my previous merge as I >> thought there was no use for it. >> About Schema : I presume you ask about the one from > javax.xml.validation >> ? >> I just added it recently to support the optional schema validation... >> >> Cheers, Sergey >> >> -----Original Message----- >> From: Benson Margulies [mailto:[EMAIL PROTECTED] >> Sent: 12 October 2008 12:13 >> To: dev@cxf.apache.org >> Subject: Re: Aegis versus jaxrs >> >> I think I finally have a sensible question by analogy with JAXB. >> >> JAXBContext objects have a variety of options and properties. The >> JAXBDataBinding allows the CXF app to control these items. The user >> can make their own context and inject it into the data binding, or the >> user can set various properties of ours that our code uses to tune the >> context. >> >> If I'm reading the JAX-RS code correctly, AbstractJAXBProvider just >> creates a JAXBContext per package or class and uses it. Any app that >> wanted to customize it would be required to make their own subclass of >> AbstractJAXBProvider, or so it seems to me. Am I missing anything? >> >> Anyway, I'm going to bang something together. >> >> >> On Fri, Oct 10, 2008 at 12:42 PM, Sergey Beryozkin >> <[EMAIL PROTECTED]> wrote: >>> Hi >>> >>>> Sergey, >>>> >>>> I'm not feeling like I'm doing a very good job of explaining myself >>>> here. It's probably true that the best way for me to proceed is to >>>> code something and with some comments that say: 'Sergey, I'm >>>> frustrated HERE.' ... >>> >>> Yea, please do it :-) ! I do hope though that you wouldn't need to > get >> into >>> the details of the actual >>> JAX-RS runtime impl, hopefully you'd be able to craft a basic Aegis >> support >>> inside the 'shell' of the (Aegis) >>> JAX-RS MessageBodyReader/Writer implementation...If we could say > limit >> the >>> support to pure Aegis (that is without it also supporting JAXB - > which >> is >>> something CXF Aegis can do as far as I understand) then it would be >> super... >>> >>> Cheers, Sergey >>> >>>> >>>> --benson >>>> >>>> On Fri, Oct 10, 2008 at 11:44 AM, Sergey Beryozkin >>>> <[EMAIL PROTECTED]> wrote: >>>>> >>>>> Hi Benson >>>>> >>>>> I'm sorry If I'm too slow :-) but I'm still not getting what is it >> that >>>>> you're proposing. >>>>> That said, I believe that may be we should postponse the discussion >> on >>>>> how >>>>> to improve the overall >>>>> JAX-RS implementation until after it reaches 1.0. >>>>> >>>>> In meantime, if we had even a basic JAX-RS Aegis provider such that >>>>> peopple >>>>> could start doing Aegis and REST or indeed combining SOAP and REST >> with >>>>> the >>>>> help of Aegis, then it would be cool IMHO.... >>>>> >>>>> Cheers, Sergey >>>>> >>>>> >>>>> >>>>>> I think I'm beginning to get the idea of what I'm trying to >> complain >>>>>> about. >>>>>> >>>>>> An AegisDatabinding object has input configuration and it has >> state. >>>>>> As it goes along, it constructs mappings for types. >>>>>> >>>>>> I'm having trouble swallowing a situation in which each individual >>>>>> JAX-RS item does this independently, as opposed to all the of the >>>>>> items in a service sharing a single state. Am I just confused? >>>>> >>>>> ---------------------------- >>>>> 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 >>> >> >
