I agree with Aaron that 99% is not accurate. This impacts an
application that I have that uses both JDBC and JMS that requires a
parentId in the plans. IMO it isn't acceptable for people to edit
version numbers in plans just so they can redeploy their application on
a later version of Geronimo.
I haven't used MagicGball in a while, but I noticed in the 1.0 branch
that the MagicGball application has a plan that has a parentId of
geronimo/j2ee-server-corba/1.0/car . This is another example of an
application requiring parents. Currently a build of MagicGball in the
1.0 branch can't be deployed to a Geronimo instance built from the 1.0
branch.
The demo application in the 1.0 branch also would have problems as it
has parentId="geronimo/security/1.0/car".
Regards,
John
Aaron Mulder wrote:
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
