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 <[email protected]>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. >> >
