I haven't been able to come up with a reason why Aegis would ever say no to isWriteable or isReadable, but I'll study some more.
On Tue, Oct 14, 2008 at 10:52 AM, Sergey Beryozkin <[EMAIL PROTECTED]> wrote: > 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 >>>> >>> >> >
