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.
