Hmm........ Normally, we try to make 2.1.(x+1) a drop in replacement for 2.1.x that should work "at least as good". This is definitely not a drop in replacement.
I think I'd actually lean toward reverting this (I'll be happy to do it since it looks like I'll have to anyway, either here or in the Progress FUSE version). However, if we do that, I'd REALLY like to push toward getting 2.2 out ASAP to get a version of CXF that fixes the issues. Basically, for Aegis, if they need the fixes, they would need to migrate to 2.2 or provide a patch for 2.1.x themselves. So, what needs to be done to get 2.2 out? That's a good question. My list: 1) JAX-RS - Sergey is working hard on finishing up the JAX-RS client stuff and fixing other JAX-RS related issues. 2) WS-Security/Trust/SecureConversation stuff - I SHOULD have WS-SC serverside stuff working this week and hopefully the Trust server side part next week. Then it's just a matter of documenting it (which I could do while voting is running) and creating an example of three for in the kit (possibly could copy the interopfest stuff as is, with checkstyle/header cleanups, as the demo. Maybe Glen's doubleit stuff, etc...) 3) Benchmarking - I want to know the affect of turning on the policy framework by default so that (2) works "out of the box" with out a bunch of config to turn on the policy framework. If the affect is negligible, then definitely make it the default. 4) Migration guide - obviously the Aegis thing would need to go in. If the policy framework is on by default, that needs to go in. Basically, I'd LIKE to try and get 2.2 built possibly on the 16th of March. Possibly aggressive, but I think doable. Another reason for that is that I'll be giving some presentations at TSS and EmergingTech conferences on the 20th and 27th and it would be good to have a "released" version to point people at. What do people think? Dan On Fri February 20 2009 6:42:24 pm Benson Margulies wrote: > I want to drag a thread of conversation from CXF-2044 to this list. > > History: > > Aegis, since it's inception in XFire, used JDOM as a representation > for XML Schema. The classes that represent types were invited to > contribute to the schema by directly manipulating the schema in JDom. > This was in turn connected to Jaxen, since Jaxen is the provider of > XPath for JDom. > > A motion was made to reduce the dependency on JDom and Jaxen. It came > from the D-OSGi folks, who had technical (and, I think, IP) issues > with the JDom/Jaxen stuff. > > So, for 2.2, I wiped out the JDom usage, connecting Aegis directly to > XmlSchema. This is consistent with some overall direction in CXF of > centering on XmlSchema as a representation for, ahem, XML Schema. It > also goes well with Dan and my status as Xml Schema committers and my > status of being the only person with the time and strong stomach to > work on it at the moment. > > Brian Relph then reported one of the many rather ugly problems that > existed in the JDom-based universe. It's just really hard to ensure > consistency amongst multiple XML Schema documents by multiple > unrelated classes doing surgery on their individual schemas via JDom. > > After some consideration on this list, I want ahead and backported > that work to 2.1.x. What none of us savored in that discussion is that > this: The Aegis API for defining new types is essentially a public > API, and now we've got an incompatible change between 2.1.4 and 2.1.5. > > Pro: ok, we have an incompatible change that effects some number of > brave souls who implemented custom types, in return for otherwise > hard-to-achieve fixes for everybody. > > Con: it's incompatible, and, not everyone is happy to find that the > tooth fairy has left the XmlSchema API on their pillow overnight. > > Dan asks if it's possible to offer any sort of half-way house here. I > doubt it for any level of effort I'm likely to produce really soon. > The Aegis API doesn't just involve the Type building a brand new JDom > Element; rather, it is making any number additions to the overall > schema document. > > We have the option of rolling back the port and leaving the bugs. I > can't say that I would approach that effort with great enthusiasm, but > perhaps someone with better SVN chops than mine could tell me how to > do it fairly easily. -- Daniel Kulp [email protected] http://www.dankulp.com/blog
