geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Proposal to remove processing of geronimo-service.xml files in dependencies
Date Sat, 25 Dec 2004 18:09:52 GMT
First of all, I misunderstood the extent of the code yesterday.  What 
it does is recursively add dependencies, not gbeans or includes, when a 
dependency mentioned in a service plan (not any j2ee plan) is deployed. 
  At this point I don't know how (or if) the jetty gbeans were getting 
deployed from the embedded geronimo-service.xml, since I have 
eradicated all copies of that file from my system.

I find the current behavior intolerably confusing.  I can see 3 choices:

1. eliminate it, so all deployments use one plan, either in the module 
being deployed or supplied separately

2. extend it so that:
- it is triggered by a separate tag rather than recycling the 
dependency tag
- it can fully deploy any deployable artifact, including j2ee modules
- it can accept an external plan

3. keep this functionality but use a different element for it so it 
cannot be confused with a simple dependency.

I vote for (1).

On Dec 25, 2004, at 8:41 AM, Jacek Laskowski wrote:

> David Jencks wrote:
>> I've located the code in service-builder that loads gbeans defined in 
>> embedded plans named geronimo-service.xml in dependencies referred to 
>> from gbean config plans.
> That's exactly the feature which prevented me from including 
> geronimo-service.xml in the tomcat module! You found it! I didn't 
> forget about it and want to enable it to simplify the deployment (and 
> leverage the concept of Jeremy where people could download their 
> configuration and inject it into a running Geronimo instance).

I don't think this feature will help you in any way to do that, but I 
could misunderstand what you are trying to do.  I think what you are 
mentioning is the ability to load configurations into a running server, 
which is a capability at a different level of functionality than this.
>> I would like to remove this capability.  My experience with its 
>> former use to configure parts of jetty was that it successfully 
>> concealed from me, for weeks, how many of the gbeans were getting 
>> configured.  Since I prefer to be able to find configurations through 
>> an explicit path, I would prefer to prevent any other such use of 
>> this feature.
>> Are there any objections to my removing this capability?
> Isn't it similar in concept to the way Maven should be working, but it 
> isn't at the moment. Every time you include project X jars as 
> dependencies you'll have to figure out what projects the project X 
> jars rely upon. It simply leads to a nightmare to configure a 
> project's dependencies, which is a PITA. I'm not convinced if removing 
> the feature will bring any simplicity. Yeah, your use case suggests it 
> will, but mine shows end users will face more complexity. We'll shift 
> it from the developers (us) to end users (also us, but I think about 
> the less familiar with the internals).
> Moreover, I think it will also break what I have aforementioned above 
> - the ability to configure Geronimo on-the-fly (well, I'm not sure if 
> it's a right term for it). What I mean is to create a plan and don't 
> think about the rest dependencies the services (gbeans) rely upon. 
> They'll be downloaded - user won't have to figure it out yourself.

The ability to configure geronimo on the fly is due to the ability to 
load and start configurations into a geronimo server.  The feature 
under discussion is simply a particularly obscure way to extend the 
classpath of some configurations (those specified by a service plan 
rather than a j2ee plan).  However, we have an alternate way to extend 
classpaths, although in sort of the opposite direction: the 
parent-child relationship of configurations.  The parent-child 
relationship of configurations is explicit and easy to detect from the 
child plan.  Use of the feature under discussion is impossible to 
detect from the plan using it, since you have to examine the contents 
of each listed dependency.

Currently "download and run" configurations are not too likely to work 
because most configurations rely on the local geronimo repository for 
large parts of their classpath.  I believe we could make 
download-and-run configurations by using "include" rather than 
"dependency", but this is not supported in most plan types and the 
feature under discussion works only for "dependency".

Many thanks,
david jencks

>> david jencks
> Jacek

View raw message