I went ahead and added a separate helper class that detects the bad namespace and switches it to the new one. Unfortunately there's a bit of code in the builder just to detect the plan with a different name, but it should be easy enough to back out later.
Aaron On Sun, 3 Jul 2005, David Jencks wrote: > Rather than adding code to the builders to accept obsolete schema > versions, I would rather provide a standalone tool to update old plans. > I don't want to get into the business of supporting > non-formally-released obsolete formats forever. > > Thoughts? > > thanks > david jencks > > On Jul 3, 2005, at 11:14 PM, David Jencks wrote: > > > > > On Jul 3, 2005, at 8:17 PM, Aaron Mulder wrote: > > > >> Jeremy, > >> No need to exaggerate. You can take a friendly tone and still > >> make your point. No one's saying that altering configuration formats > >> is a > >> "good" thing, just that it will steadily get "worse" the more stable > >> the > >> server gets. And note that an "unstable" release is exactly that -- > >> we > >> need a well-documented Milestone 4 release to direct new users to. > >> In the > >> mean time, I'm trying to set up a weekly build environment here, so > >> hopefully I'll put up a fresh "unstable" release from that tomorrow. > >> > >> Finally, as for the extra mile, I have no idea how to get > >> XMLBeans to accept an XML file that could contain one of two > >> namespaces, > >> but is otherwise identical in content (to handle old Jetty files). > >> Any > >> constructive tips? > > > > I think this is fairly easy to do using an xmlcursor. I do a lot of > > it in SchemaConversionUtils to convert the namespace of the embedded > > naming and security elements to their actual namespaces. > > > > If we add this I think we should print a loud warning that the > > behavior will not be supported forever. > >> > >> I suppose for Tomcat we could implement a schema converter that > >> would turn the Tomcat-specific elements into container-config > >> elements, > >> but this seems like a lot of work. If we get a lot of feedbcak from > >> confused Tomcat users I'll be happy to look into if further. > > > > I would think that the tomcat integration is new enough so we don't > > have to worry about this. > > > > thanks > > david jencks > > > > > >> > >> Aaron > >> > >> P.S. To address Dain's comment, I think he'd agree we need to call a > >> moratorium on config changes once we reach a certain level of pre-1.0 > >> stability -- perhaps RC builds or whatever. > >> > >> On Sun, 3 Jul 2005, Jeremy Boynes wrote: > >>> So let me get this right ... > >>> > >>> * announce to the world we pass the CTS tests and put out an unstable > >>> release > >>> * just when people are looking at the project, change the deployment > >>> plans in an incompatible way > >>> * don't provide any upgrade tool, just tell users they need > >>> to edit all their existing plans > >>> * tell them this is a *good* thing because we're going to keep > >>> changing things until 1.0 finally comes out > >>> > >>> And this is somehow supposed to encourage people to use this > >>> software? > >>> > >>> Aaron, I appreciate what you are trying to do. Please go the extra > >>> mile > >>> and make sure existing plans continue to work - it is not hard to do > >>> and > >>> will avoid putting off a lot of potential users. > >>> > >>> -- > >>> Jeremy > >>> > >>> Dain Sundstrom wrote: > >>>> +100000000 before we release 1.0 is the exactly when we should be > >>>> encouraging this type of drastic change. After 1.0 comes out, I > >>>> doubt > >>>> we will be able to make these type of changes until 2.0. I think > >>>> we > >>>> should review all of our configuration files and make > >>>> usability/consistency changes before we even consider a 1.0. > >>>> > >>>> -dain > >>>> > >>>> On Jul 3, 2005, at 7:25 PM, Aaron Mulder wrote: > >>>> > >>>>> On Sun, 3 Jul 2005, Jeremy Boynes wrote: > >>>>> > >>>>>> Won't this cause a problem for users, having to modify all > >>>>>> existing > >>>>>> plans to accomodate this change? > >>>>>> > >>>>> > >>>>> Sure. But we've already agreed on the need for a single web > >>>>> deployment format, and I don't think it makes sense to support 3 > >>>>> formats > >>>>> to try to ease transition. This is one of many configuration > >>>>> changes > >>>>> that > >>>>> will be necessary in moving from Milestone 3 to Milestone 4. > >>>>> Hopefully we > >>>>> can minimize this kind of thing moving forward into more stable > >>>>> releases, > >>>>> but I'm not sure we're entirely there yet. > >>>>> > >>>>> I'll make sure the Wiki docs are up to date. > >>>>> > >>>>> Aaron > >>>>> > >>>> > >>> > >>> > >> > > > >
