geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Poll: Resolve configId Versions for 1.0.1
Date Wed, 25 Jan 2006 00:33:47 GMT

On Jan 24, 2006, at 3:59 PM, Aaron Mulder wrote:

> On 1/24/06, Alan D. Cabrera <> 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.

david jencks

> Thanks,
>     Aaron

View raw message