geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <>
Subject Re: Poll: Resolve configId Versions for 1.0.1
Date Thu, 26 Jan 2006 20:33:46 GMT
I believe the problem only affects Geronimo deployment plans written
by users.  Either for their own J2EE applications, or for custom
Geronimo services.  (And "users" includes "vendors writing Geronimo
extensions or Geronimo-based products").  So if a user writes a plan
with any "1.0" in it and then tries to deploy under 1.0.1 or 1.1 or
whatever, it won't work.

Within the plans, the main thing not in your list is GBean references.
 If a custom GBean refers to a Geronimo GBean, it typically has to
include the target GBean's module name (= configId).  I think
ServerInfo is the most likely to be used in this way, but any Geronimo
GBean you want to refer to would have the issue.

Other GBean references in the plans include:

References to a WorkManager from a connector plan.  That is an
arbitrary GBean reference, and if you use the long form, you may need
to include the owning GBean's module name.  Most likely you can avoid
it by either using <gbean-link> or referring to a custom deployed

References to a TSS/CSS from a CORBA EJB or client, or a
ResourceAdapter from a MDB, or a JDBC pool from any component...  I'm
sure I'm forgetting a few more.  All are effectively GBean references.
 All of these are probably referring to components you deployed so you
can probably choose not to use a version number in the name or at
least you won't be hit by Geronimo revving our version numbers.

I don't think individually the issues with the GBean references are
super-compelling, but all together they add up to something.


P.S. The console also has some issues, like for an ActiveMQ JMS
deployment it generates a parent/import for
geronimo/activemq-broker/1.0/car, but that URI is in a config file
with variable substitution applied during the build, so it will only
cause trouble if you use the console to generate a plan and then save
that plan separately and later upgrade Geronimo, at which point it's
the same as the user-supplied plan problem.  :)

On 1/26/06, Dain Sundstrom <> wrote:
> I'm having a hard time following this discussion, because I'm not
> sure of the scope of this problem.  Is this a problem that only
> impacts our xml configs, and does it only impact the following:
> o parentId attribute
> o import short form element
> o import long form
> If there are more places we need to address this problem, I'd like to
> get them on the table now.
> -dain
> On Jan 24, 2006, at 11:52 AM, Aaron Mulder wrote:
> > All,
> >
> > There was some IRC talk but not a lot of list response to the configId
> > versioning issue.  Right now, it's kind of holding up 1.0.1 IMHO
> > because I can't support releasing 1.0.1 until we resolve the
> > compatibility issue somehow, and there's going to be a fair bit of
> > work to get it going one way or another.  Anyway, for the 1.0.1
> > release, please indicate your preference for:
> >
> > [ ] Change all configIds to 1.0 even though it's the 1.0.1 release
> > [ ] Change all references to use no version and make that work
> > [ ] Something else (please explain)
> >
> > For the second option, that means the configId for module would still
> > be geronimo/foo/1.0.1/car but any parentId, import, or GBean reference
> > would look like this:
> >
> > parentId="geronimo/foo//car"
> > <import>geronimo/foo//car</import>
> > <import>
> >   <groupId>geronimo</groupId>
> >   <artifactId>foo</artifactId>
> >   <type>car</type>
> > </import>
> >
> > That is, the version would be omitted from the reference, and we'd
> > somehow interpret that to mean "whatever version is present" or "use
> > most current version".  You still *could* use a specific version, we'd
> > just emphasize the version-less option for maximum compatibility.  I
> > think this alternative would require more work but might be a better
> > fit for a long-term strategy.
> >
> > Thanks,
> >    Aaron

View raw message