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 >>> >> >
