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 >
