geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Sisson <jrsis...@gmail.com>
Subject Re: Poll: Resolve configId Versions for 1.0.1
Date Tue, 24 Jan 2006 23:31:53 GMT
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 <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