geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <joe.b...@earthlink.net>
Subject Re: Poll: Resolve configId Versions for 1.0.1
Date Wed, 25 Jan 2006 14:34:48 GMT
I've used this approach on another project with some (although not 
perfect) success.  The benefit of the approach is that it allows a 
"using" component to specify a version of a component upon which it is 
dependent with certainty.  The dependent component then can make the 
call if it will be compatible with lower level versions of itself.

The tricky part gets to be what some components might consider to be 
compatible or not.  A change that seems safe can cause problems for some 
users.  This approach can be slightly extended to provide the "using" 
component with an additional attribute to indicate if it is willing to 
accept a "compatible" version or it if requires an exact match.

This may or may not be possible for the 1.0.1 release, but I think we 
will eventually have to consider something along these lines.

Joe

Paul McMahan wrote:
> FWIW I responded to Aaron's earlier thread on this topic with an idea 
> that would allow Geronimo 1.0.1 (and onward) to support applications 
> that reference the Geronimo 1.0 components.   The idea is to basically 
> add support for a new tag, <isCompatibleWith>, that we would add to 
> Geronimo components as we bump their configIds.
> 
> So an application developed using Geronimo 1.0 that looks like this:
> <configuration configId="MyApplication"
>    parentId="geronimo/j2ee-server/1.0/car"
>    xmlns="...">
> 
> Would still work (unchanged) in Geronimo 1.0.1 because we would use the 
> new tag as follows:
> <configuration configId="geronimo/j2ee-server/1.0.1/car"
>   xmlns="...">
>     
> <isCompatibleWith><uri>geronimo/j2ee-server/1.0/car</uri></isCompatibleWith>
> 
> As we move on releasing more versions of Geronimo we continue to declare 
> backwards compatibility by extending this tag:
> <configuration configId="geronimo/j2ee-server/1.1/car"
>   xmlns="...">
>     <isCompatibleWith>
>         <uri>geronimo/j2ee-server/1.0/car</uri>
>         <uri>geronimo/j2ee-server/1.0.1/car</uri>
>     </isCompatibleWith>
> 
> This idea may be half baked, but in case there is some merit to it I 
> wanted to chime in while there's still time.  During a brief chat on IRC 
> one (valid) criticism is that the <isCompatibleWith> tag might look 
> pretty scary by the time we reach version, say, 3.4.17.  But that effect 
> could be lessened by using the tag judiciously (perhaps only within 
> major release boundaries) or by adding support for wildcards in the tag 
> (i.e. making the Geronimo developers understand/use the special wildcard 
> syntax, not the app developers ;-)
> 
> Best wishes,
> Paul
> 
> On 1/25/06, *David Jencks* <david_jencks@yahoo.com 
> <mailto:david_jencks@yahoo.com>> wrote:
> 
> 
>     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
>     <mailto: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
>     <mailto: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
>      >>>>
>      >>>
>      >>
>      >>
>      >
> 
> 

-- 
Joe Bohn
joe.bohn at earthlink.net

"He is no fool who gives what he cannot keep, to gain what he cannot 
lose."   -- Jim Elliot

Mime
View raw message