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: Poll: Resolve configId Versions for 1.0.1
Date Wed, 25 Jan 2006 09:02:03 GMT

On Jan 24, 2006, at 5:50 PM, John Sisson wrote:

> Aaron Mulder wrote:
>> If you're deploying a JMS resource, whether at the top level of the
>> server or as part of the application, isn't it best to put a  
>> parent of
>> geronimo/activemq-broker/1.0/car?  I would certainly think so
>> (definitely want the broker started before the app!).  The same may
>> not be true for JDBC (if you're not using Derby), but I think it  
>> would
>> be true for anything that ultimately depends on LDAP (such as a
>> security relam) using the embedded Directory server.  I'm not so sure
>> about CORBA.  We dodged this on ServiceMix by separating that out for
>> the time being.  But we currently also have the issues in GBean  
>> names,
>> so any GBeans with references to things like ServerInfo will also  
>> have
>> the problem.
>>
>> I guess I might be willing to be dragged kicking and screaming into
>> 1.0.1 without a fix for this, but I sure wouldn't feel good about  
>> it. This seems to me to be similar to changing our deployment plan  
>> schemas
>> and saying "well, you know, the elements we removed weren't used that
>> much anyway."  I know if we were going to do that we'd have a
>> converter in place so that old plans wouldn't actually break.
>>
>>
> I also would prefer this issue being resolved in 1.0.1 (even if we  
> need to push the release back a bit).  Users should not have to  
> change their existing plans to use 1.0.1.

I think it's unlikely we can find a solution that we will like that  
will let plans with a hardcoded geronimo 1.0 version in them continue  
to work.  What we might be able to do is find a way that we think  
1.0.1 compatible plans will remain usable at least until 2.0 and  
hopefully farther.

thanks
david jencks

> John
>> Thanks,
>>     Aaron
>>
>> On 1/24/06, David Jencks <david_jencks@yahoo.com> wrote:
>>
>>> On Jan 24, 2006, at 3:59 PM, Aaron Mulder wrote:
>>>
>>>
>>>> On 1/24/06, Alan D. Cabrera <list@toolazydogs.com> wrote:
>>>>
>>>>> Why do the version numbers change for patches?  Shouldn't this be
>>>>> backward compatible?
>>>>>
>>>> That the first option in the poll -- to make the configIds  
>>>> retain the
>>>> version number 1.0 even though the rest of the server marches on to
>>>> 1.0.1.  Currently, the version for each configId is based on the
>>>> Geronimo version number, so everything was incremented to
>>>> 1.0.1-SNAPSHOT (and ultimately 1.0.1) together.
>>>>
>>>> However, even if we select this as the short term (1.0.1)  
>>>> solution, I
>>>> don't think it's a general solution.  I don't think people  
>>>> should have
>>>> to change their plans to go from 1.0.x to 1.1x or even to 2.x  
>>>> unless
>>>> we actually change the schemas in a non-backward-compatible way  
>>>> (and
>>>> even if we did that we'd usually provide a converter to silently
>>>> update a plan using the old format to the new format, but the  
>>>> schema
>>>> converters don't currently touch embedded data like configIds).
>>>>
>>>> My 2 cents is that the long-term solution should somehow involve  
>>>> the
>>>> version number being optional, so you can use it if you feel  
>>>> strongly
>>>> about it (running big server farm, want to force everything to be
>>>> identical) and omit it if you would prefer to maximize  
>>>> compatibility.
>>>>
>>> I think we might be able to remove /car from the configId: it's
>>> optional IIUC in the maven format and I think we can always infer it
>>> from the context.
>>>
>>> Making the version optional in plan references (parentId but not
>>> configId) might work.  If we do, we have to decide when the version
>>> is resolved: at deploy time or at runtime.  Deploy time will give
>>> fewer chances for runtime class mismatches but runtime will require
>>> fewer redeployments.
>>>
>>> Any change of configId format is going to require a very painful
>>> change of all the J2eeModule keys in gbean references in our plans.
>>> In my experience it takes several days and iterations to find and
>>> change all of them.
>>>
>>> If we make the version optional we are going to have to change the
>>> jsr-77 names for every gbean so that the xxxModule is something like
>>> groupId/artifactId and presumably supply a separate key for version.
>>> We might be able to just change the xxxModule key and leave the
>>> version for later, thus preventing anyone from running 2 versions of
>>> the same app at the same time using just differently versioned  
>>> plans.
>>>
>>> I still think it might be wiser to spend our time in 1.0.1 removing
>>> excess parentIds and trying to eliminate cases when you need to
>>> specify them.  I think that might well result in an overall improved
>>> user experience.
>>>
>>> For instance, some of the uses mentioned recently are:
>>> jdbc.  A user app should not be using the system database, so
>>> deploying the connector with the app is a better solution
>>>
>>> jms Similarly, I think the amq connector is an example and  
>>> perhaps we
>>> should not be deploying it by default.  I would expect any actual  
>>> use
>>> of jms to use its own amq plan, probably deployed with the app.  In
>>> any case it would not be versioned with geronimo and should not need
>>> any geronimo versions in the plan
>>>
>>> corba config I have come to realize that the sample corba configs we
>>> ship are pretty much a mistake.  Any real usage is going to require
>>> configuring tss and css beans with the actual security the app  
>>> needs,
>>> not the toy stuff we supply configured by default.  The tss and css
>>> beans should really go with the app using them.
>>>
>>> thanks
>>> david jencks
>>>
>>>
>>>
>>>> Thanks,
>>>>     Aaron
>>>>
>>>
>>
>>
>


Mime
View raw message