geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Unified Tomcat/Jetty Plans
Date Mon, 04 Jul 2005 06:50:55 GMT
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
>>>>>
>>>>
>>>
>>>
>>
>


Mime
View raw message