geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <ammul...@alumni.princeton.edu>
Subject Re: Poll: Resolve configId Versions for 1.0.1
Date Tue, 24 Jan 2006 22:24:00 GMT
Alan:

If you write a plan like this:

<openejb-jar xmlns=... configId="MyEJBs"
  parentId="geronimo/activemq/1.0/car">
  ...
</openejb-jar>

That works perfectly well for 1.0, and is in fact the recommendad way
to make sure your app always starts after the JMS server, etc..  But
when you try to deploy that on Geronimo 1.0.1 it doesn't work (because
there is no geronimo/activemq/1.0/car in Geronimo 1.0.1).  I don't
believe you should need to rewrite your 1.0 plans to deploy them on
Geronimo 1.0.1 (or even 1.1 or 2.0!) unless you specifically want to
take advantage of some new syntax or something.


David:

Let's say you want to use JMS resources or a JDBC pool.  You must
specify a parent or import to require the configuration holding the
JMS/JDBC resources to start before your application starts.  For JMS,
something ultimately will need to depend on the ActiveMQ broker.  I
don't think this is at all far-fetched.  Likewise, if you have an LDAP
security realm using the embedded Directory, or your application uses
the embedded Derby, or you have a custom GBean that uses ServerInfo or
a thread pool, etc.

We can change documentation to leave out the parentId and imports when
appropriate, but I just don't think your 99% figure is accurate. 
"Never use a Geronimo configuration as a parent ID" doesn't sound that
realistic to me given all the features we bundle in the server.

Thanks,
    Aaron


On 1/24/06, David Jencks <david_jencks@yahoo.com> wrote:
> And another thing :-)
>
> Just how serious is this problem anyway?  99% of j2ee apps should not
> be specifying a parentId themselves at all, and if our documentation
> suggests it that is a bug.  I don't think we are going to have binary
> compatibility between a config built for 1.0 and a config built for
> 1.0.1 anyway, so unless we have a testing program to prove that that
> is likely to work, we are going to ask everyone to redeploy their
> apps on 1.0.1, and if they don't have a parentId IMO that should
> proceed without a plan change.
>
> I think the best thing to do is to make sure that no one is
> specifying parentIds and declare this a non-problem.  Why won't that
> work?
>
> thanks
> david jencks
>
> On Jan 24, 2006, at 12:50 PM, Aaron Mulder wrote:
>
> > OK, I don't mean to encourage "rushing in", but the original goal for
> > 1.0.1 was to freeze around the end of January...
> >
> > Thanks,
> >     Aaron
> >
> > On 1/24/06, David Jencks <david_jencks@yahoo.com> wrote:
> >>
> >> 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:
> >>>
> >>> [+0 ] Change all configIds to 1.0 even though it's the 1.0.1 release
> >>> [-1 ] Change all references to use no version and make that work
> >>> [ +0.5] Something else (please explain)
> >>
> >> I haven't had a chance to think about this thoroughly yet.  I really
> >> really really don't want to rush into a solution that may get us into
> >> trouble later. I prefer the current hard coded version number
> >> solution to removing version entirely.  Offhand I think making
> >> configuration object names have groupId, artifactId, and version keys
> >> might provide a partial solution.
> >>
> >> Fundamentally the problem is that a configuration needs to be able to
> >> say, "I need services X Y and Z, at these levels" and we need to be
> >> able to supply them.  The current hardcoded solution certainly does
> >> this but way too specifically, you have to name the exact
> >> implementation you want and the exact version.  A possible far-off
> >> goal is that your web app configuration says, "I need servlet 2.4
> >> support" and something else configures whether it is jetty or
> >> tomcat.  Ideally I would like to have a plan for how to get to this
> >> particular piece of pie in the sky before starting to change what we
> >> have now: I don't know if this is remotely realistic.
> >>
> >> thanks
> >> david jencks
> >>
> >>
> >>>
> >>> 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
> >>
> >>
>
>

Mime
View raw message