Aegis as a client

[Benson Margulies <bi...@gmail.com>]

Recently, we have seen more XFire users migrating to CXF and running
into various issues. Using the Aegis databinding on the client side is
one of them.

I've updated  http://cwiki.apache.org/confluence/display/CXF20DOC/Aegis+(2.1)
to carry a clearer warning of the possible pitfalls.

Aegis does not implement a specification. There is no compliance test.
Every time we change anything in Aegis, we are likely to change the
mappings. As a result, the safe policy is to use Aegis as a client
only when the two ends of the connection have exactly the same version
of CXF.

Some readers of this may find this a problematic or irresponsible
point view. They may be right. There are very few of us available to
work on Aegis. Perhaps, more to the point, the transition from XFire
to CXF was rough on Aegis. The basics worked, but many of the more
complex features didn't arrive in CXF in working condition. There were
also a certain number of defect reports out there in XFire.

As a result, the harder we work to make Aegis work right in version X,
the less likely it is that version X is going to interoperate with
version X-n. In some cases, we're stuck: the behavior is a flat-out
bug, and the fix is too complex to backmigrate to an older branch.

If Aegis, like some other things, could read a WSDL at runtime, I
suppose that there is some hypothetical possibility that it could
dynamically remap some of these cases. Again, however, the historical
lack of this capability would leave 'old client, new server' scenarios
in the lurch.

For better or worse, this is what we've got. As always, volunteers are
welcome to attempt to ameliorate it.

Re: Aegis as a client

[Benson Margulies <bi...@gmail.com>]

And this is the point at which I have to make the sad observation that I
work on CXF more as a hobby than as day-job, and your idea, while perfectly
plausible to me, seems beyond what I can pile onto my existing stack.

On Wed, Mar 25, 2009 at 2:03 PM, Sergey Beryozkin <sb...@progress.com>wrote:

> Hi Benson
>
>
>> Aegis does not implement a specification. There is no compliance test.
>> Every time we change anything in Aegis, we are likely to change the
>> mappings. As a result, the safe policy is to use Aegis as a client
>> only when the two ends of the connection have exactly the same version
>> of CXF.
>>
>> Some readers of this may find this a problematic or irresponsible
>> point view. They may be right. There are very few of us available to
>> work on Aegis. Perhaps, more to the point, the transition from XFire
>> to CXF was rough on Aegis. The basics worked, but many of the more
>> complex features didn't arrive in CXF in working condition. There were
>> also a certain number of defect reports out there in XFire.
>>
>> As a result, the harder we work to make Aegis work right in version X,
>> the less likely it is that version X is going to interoperate with
>> version X-n. In some cases, we're stuck: the behavior is a flat-out
>> bug, and the fix is too complex to backmigrate to an older branch.
>>
>> If Aegis, like some other things, could read a WSDL at runtime, I
>> suppose that there is some hypothetical possibility that it could
>> dynamically remap some of these cases. Again, however, the historical
>> lack of this capability would leave 'old client, new server' scenarios
>> in the lurch.
>>
>
> Can aegis properties be enhanced somehow to repersent those missing
> metadata for Aegis, when needed ?
> perhaps they may contain few extra rules such that a client can tell the
> runtime which mapping rules apply ?
>
> Cheers, Sergey
>
>
>
>
>> For better or worse, this is what we've got. As always, volunteers are
>> welcome to attempt to ameliorate it.
>>
>

Re: Aegis as a client

[Sergey Beryozkin <sb...@progress.com>]

Hi Benson

> 
> Aegis does not implement a specification. There is no compliance test.
> Every time we change anything in Aegis, we are likely to change the
> mappings. As a result, the safe policy is to use Aegis as a client
> only when the two ends of the connection have exactly the same version
> of CXF.
> 
> Some readers of this may find this a problematic or irresponsible
> point view. They may be right. There are very few of us available to
> work on Aegis. Perhaps, more to the point, the transition from XFire
> to CXF was rough on Aegis. The basics worked, but many of the more
> complex features didn't arrive in CXF in working condition. There were
> also a certain number of defect reports out there in XFire.
> 
> As a result, the harder we work to make Aegis work right in version X,
> the less likely it is that version X is going to interoperate with
> version X-n. In some cases, we're stuck: the behavior is a flat-out
> bug, and the fix is too complex to backmigrate to an older branch.
> 
> If Aegis, like some other things, could read a WSDL at runtime, I
> suppose that there is some hypothetical possibility that it could
> dynamically remap some of these cases. Again, however, the historical
> lack of this capability would leave 'old client, new server' scenarios
> in the lurch.

Can aegis properties be enhanced somehow to repersent those missing metadata for Aegis, when needed ?
perhaps they may contain few extra rules such that a client can tell the runtime which mapping rules apply ?

Cheers, Sergey


> 
> For better or worse, this is what we've got. As always, volunteers are
> welcome to attempt to ameliorate it.

Re: Aegis as a client

[Sergey Beryozkin <sb...@progress.com>]

Hi Benson

> 
> Aegis does not implement a specification. There is no compliance test.
> Every time we change anything in Aegis, we are likely to change the
> mappings. As a result, the safe policy is to use Aegis as a client
> only when the two ends of the connection have exactly the same version
> of CXF.
> 
> Some readers of this may find this a problematic or irresponsible
> point view. They may be right. There are very few of us available to
> work on Aegis. Perhaps, more to the point, the transition from XFire
> to CXF was rough on Aegis. The basics worked, but many of the more
> complex features didn't arrive in CXF in working condition. There were
> also a certain number of defect reports out there in XFire.
> 
> As a result, the harder we work to make Aegis work right in version X,
> the less likely it is that version X is going to interoperate with
> version X-n. In some cases, we're stuck: the behavior is a flat-out
> bug, and the fix is too complex to backmigrate to an older branch.
> 
> If Aegis, like some other things, could read a WSDL at runtime, I
> suppose that there is some hypothetical possibility that it could
> dynamically remap some of these cases. Again, however, the historical
> lack of this capability would leave 'old client, new server' scenarios
> in the lurch.

Can aegis properties be enhanced somehow to repersent those missing metadata for Aegis, when needed ?
perhaps they may contain few extra rules such that a client can tell the runtime which mapping rules apply ?

Cheers, Sergey


> 
> For better or worse, this is what we've got. As always, volunteers are
> welcome to attempt to ameliorate it.