You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Benson Margulies <bi...@gmail.com> on 2008/07/31 15:47:35 UTC
Aegis versus jaxrs
If I'm reading the JAX-RS code correctly, which I'm probably not, it doesn't
use the JAXB DataBinding object. It interacts class-by-class with JAXB.
I think I can do likewise for Aegis, sort of, but it could get ugly. Does
JAX-RS give us no ability to configure a data binding at the level of the
entire service?
RE: Aegis versus jaxrs
Posted by Sergey Beryozkin <sb...@progress.com>.
Hi,
You may want to check in those methods if the passed in media type
argument is application/xml or at the least it is some form of */xml.
MediaType class has all the getters.
Additionally, in case of JAXB it's checked if the class to be
(un)narshalled has some sort of JAXB annotation, but in case of Aegis
it's not clear what else to check for. MediaType check should be
sufficient...
Cheers, Sergey
-----Original Message-----
From: Benson Margulies [mailto:bimargulies@gmail.com]
Sent: 14 October 2008 23:11
To: dev@cxf.apache.org
Subject: Re: Aegis versus jaxrs
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
<sb...@progress.com> 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:bimargulies@gmail.com]
> 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
> <sb...@progress.com> 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:bimargulies@gmail.com]
>> 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
>> <sb...@progress.com> 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:bimargulies@gmail.com]
>>> 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
>>> <se...@iona.com> 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
>>>>> <se...@iona.com> 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
>>>>
>>>
>>
>
Re: Aegis versus jaxrs
Posted by Benson Margulies <bi...@gmail.com>.
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
<sb...@progress.com> 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:bimargulies@gmail.com]
> 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
> <sb...@progress.com> 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:bimargulies@gmail.com]
>> 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
>> <sb...@progress.com> 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:bimargulies@gmail.com]
>>> 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
>>> <se...@iona.com> 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
>>>>> <se...@iona.com> 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
>>>>
>>>
>>
>
RE: Aegis versus jaxrs
Posted by Sergey Beryozkin <sb...@progress.com>.
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:bimargulies@gmail.com]
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
<sb...@progress.com> 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:bimargulies@gmail.com]
> 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
> <sb...@progress.com> 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:bimargulies@gmail.com]
>> 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
>> <se...@iona.com> 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
>>>> <se...@iona.com> 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
>>>
>>
>
Re: Aegis versus jaxrs
Posted by Benson Margulies <bi...@gmail.com>.
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 <sb...@progress.com> 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:bimargulies@gmail.com]
> 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
> <sb...@progress.com> 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:bimargulies@gmail.com]
>> 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
>> <se...@iona.com> 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
>>>> <se...@iona.com> 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
>>>
>>
>
RE: Aegis versus jaxrs
Posted by Sergey Beryozkin <sb...@progress.com>.
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:bimargulies@gmail.com]
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
<sb...@progress.com> 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:bimargulies@gmail.com]
> 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
> <se...@iona.com> 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
>>> <se...@iona.com> 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
>>
>
Re: Aegis versus jaxrs
Posted by Benson Margulies <bi...@gmail.com>.
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 <sb...@progress.com> 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:bimargulies@gmail.com]
> 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
> <se...@iona.com> 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
>>> <se...@iona.com> 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
>>
>
RE: Aegis versus jaxrs
Posted by Sergey Beryozkin <sb...@progress.com>.
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:bimargulies@gmail.com]
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
<se...@iona.com> 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
>> <se...@iona.com> 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
>
Re: Aegis versus jaxrs
Posted by Benson Margulies <bi...@gmail.com>.
Schema: what's with the .xsd files? Does it ever let JAXB generate schema?
How would it ever aggregate across all the individual classes?
On Sun, Oct 12, 2008 at 7:13 AM, Benson Margulies <bi...@gmail.com> wrote:
> 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
> <se...@iona.com> 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
>>> <se...@iona.com> 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
>>
>
Re: Aegis versus jaxrs
Posted by Benson Margulies <bi...@gmail.com>.
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
<se...@iona.com> 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
>> <se...@iona.com> 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
>
Re: Aegis versus jaxrs
Posted by Sergey Beryozkin <se...@iona.com>.
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
> <se...@iona.com> 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
Re: Aegis versus jaxrs
Posted by Benson Margulies <bi...@gmail.com>.
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.' I've not been having the time to do more for CXF
than to address users with their hair on fire, but that might change.
--benson
On Fri, Oct 10, 2008 at 11:44 AM, Sergey Beryozkin
<se...@iona.com> 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
>
Re: Aegis versus jaxrs
Posted by Sergey Beryozkin <se...@iona.com>.
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
Re: Aegis versus jaxrs
Posted by Benson Margulies <bi...@gmail.com>.
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?
Re: Aegis versus jaxrs
Posted by Sergey Beryozkin <se...@iona.com>.
Hi
> When a CXF service offers JAX-RS, some CXF-specific configuration is
> involved, no? So, could we not have some properties at the service level
> which the ProviderFactory consumes-if-provided? Aegis in particular has a
> set of configuration options, it would be very cumbersome to force those to
> be configured per-MessageBodyProvider.
if you look at the JSONElementProvider, you can see it has setProperties(), and this provider
instance can pick all the required properties when it's configured using Spring.
Aegis configuration properties would be specific to an Aegis provider only so I'm not sure what your concern
is...
>
> My proposal is that the JAXRSServerFactoryBean could be given DataBinding
> objects, and the ProviderFactory would use them. If there aren't any, it
> would do what it does now.
I'm sorry, I'm not following :-).
For, here's a typical method a JAX-RS can handle :
Customer doIt(@QueryParam("bar") String bar, Customer customer);
I don't understand how your proposal would make it easier to handle the conversion of the InputStream into an instance of Customer.
Please explain. In other words why can't an AegisProvider reuse the code from the DataBinding directly ?
ProviderFactory's job is to create providers based on the asked media types and classes
>
> On a more detailed note, how would you propose that the ProviderFactory
> arbitrate between using JAXB and Aegis? They support the same annotations on
> the code. Isn't this another reason to have a Server Factory configuration,
> to specify which data binding to use by default? Or is some other mechanism
> at work here that I haven't comprehended?
ProviderFactory does not need to arbitrate in this case it's this the JAX-RS runtime itself which will do it indirectly.
Suppose we have a Customer which either a JAXBProvider or AegisProvider can handle. Explictly configuring AegisProvider as one of
the providers to be used in the spring config for jaxrs:server would ensure that it'll be given a chance to serialize/deserialize
before a JAXBProvider will be asked to do the same....
Thanks for starting to look into it anyway, I'm sure we'll a have a cool JAX-RS AegisProvider eventually :-)
Cheers, Sergey
P.S. I'll be on holidays for the most part of August, so I won't be able to contribute to this thread during the next month
>
>
>
> On Thu, Jul 31, 2008 at 10:23 AM, Sergey Beryozkin <
> sergey.beryozkin@iona.com> wrote:
>
>> Hi
>>
>> If I'm reading the JAX-RS code correctly, which I'm probably not, it
>>> doesn't
>>> use the JAXB DataBinding object. It interacts class-by-class with JAXB.
>>>
>>
>> At the moment yes, and this is a reson I excluded a jaxb-databinding
>> module, just to minimize the size of the cxf-jaxrs bundle. I think jaxb api
>> is picked up recursively from some other module, I actually didn't check
>> from which one.
>>
>>
>>> I think I can do likewise for Aegis, sort of, but it could get ugly.
>>>
>>
>> If you'd like to do an Aegis Provider and a jaxb binding module would help
>> you then please do include it in the pom again.
>>
>> Does
>>> JAX-RS give us no ability to configure a data binding at the level of the
>>> entire service?
>>>
>>>
>> In JAX-RS, it's individual MessageBodyProviders which are responsible for
>> (un)marshalling. So probably, not...
>> Perhaps the default JAXBProvider can be updated to reuse some of the code
>> from a jaxb binding, not sure
>>
>> 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
Re: Aegis versus jaxrs
Posted by Benson Margulies <bi...@gmail.com>.
When a CXF service offers JAX-RS, some CXF-specific configuration is
involved, no? So, could we not have some properties at the service level
which the ProviderFactory consumes-if-provided? Aegis in particular has a
set of configuration options, it would be very cumbersome to force those to
be configured per-MessageBodyProvider.
My proposal is that the JAXRSServerFactoryBean could be given DataBinding
objects, and the ProviderFactory would use them. If there aren't any, it
would do what it does now.
On a more detailed note, how would you propose that the ProviderFactory
arbitrate between using JAXB and Aegis? They support the same annotations on
the code. Isn't this another reason to have a Server Factory configuration,
to specify which data binding to use by default? Or is some other mechanism
at work here that I haven't comprehended?
On Thu, Jul 31, 2008 at 10:23 AM, Sergey Beryozkin <
sergey.beryozkin@iona.com> wrote:
> Hi
>
> If I'm reading the JAX-RS code correctly, which I'm probably not, it
>> doesn't
>> use the JAXB DataBinding object. It interacts class-by-class with JAXB.
>>
>
> At the moment yes, and this is a reson I excluded a jaxb-databinding
> module, just to minimize the size of the cxf-jaxrs bundle. I think jaxb api
> is picked up recursively from some other module, I actually didn't check
> from which one.
>
>
>> I think I can do likewise for Aegis, sort of, but it could get ugly.
>>
>
> If you'd like to do an Aegis Provider and a jaxb binding module would help
> you then please do include it in the pom again.
>
> Does
>> JAX-RS give us no ability to configure a data binding at the level of the
>> entire service?
>>
>>
> In JAX-RS, it's individual MessageBodyProviders which are responsible for
> (un)marshalling. So probably, not...
> Perhaps the default JAXBProvider can be updated to reuse some of the code
> from a jaxb binding, not sure
>
> Cheers, Sergey
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
>
Re: Aegis versus jaxrs
Posted by Sergey Beryozkin <se...@iona.com>.
Hi
> If I'm reading the JAX-RS code correctly, which I'm probably not, it doesn't
> use the JAXB DataBinding object. It interacts class-by-class with JAXB.
At the moment yes, and this is a reson I excluded a jaxb-databinding module, just to minimize the size of the
cxf-jaxrs bundle. I think jaxb api is picked up recursively from some other module, I actually didn't check from which one.
>
> I think I can do likewise for Aegis, sort of, but it could get ugly.
If you'd like to do an Aegis Provider and a jaxb binding module would help you then please do include it in the pom again.
> Does
> JAX-RS give us no ability to configure a data binding at the level of the
> entire service?
>
In JAX-RS, it's individual MessageBodyProviders which are responsible for (un)marshalling. So probably, not...
Perhaps the default JAXBProvider can be updated to reuse some of the code from a jaxb binding, not sure
Cheers, Sergey
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland