Re: Poll: Resolve configId Versions for 1.0.1

[David Jencks]

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 <[EMAIL PROTECTED]> wrote:

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


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