cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Aegis as a client
Date Thu, 12 Mar 2009 02:08:54 GMT
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.

Mime
View raw message