Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v619)
In-Reply-To: <41CDC47D.7040106@gluecode.com>
References: <557A0E8C-564C-11D9-8400-000D93361CAA@gluecode.com>
 <41CDC47D.7040106@gluecode.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <0E2FEE50-56B3-11D9-8400-000D93361CAA@gluecode.com>
Content-Transfer-Encoding: 7bit
From: David Jencks <djencks@gluecode.com>
Subject: Re: Proposal to remove processing of geronimo-service.xml files in
 dependencies
Date: Sat, 25 Dec 2004 12:25:02 -0800
To: dev@geronimo.apache.org


On Dec 25, 2004, at 11:50 AM, Jeremy Boynes 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.
>> 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?
>
> The intention here was to allow a service archive to declare its own 
> dependencies so that people did not have to try and figure it out for 
> themselves. For example, to use the geronimo-jetty jar I would need to 
> ensure that a suitable version of Jetty was available to it - how do I 
> know what those dependencies are?

At present, by looking in the plan that includes the jetty server gbean 
config.  This now includes all the dependencies needed to run jetty, 
such as the jasper components.  Can you explain how separating the list 
of dependencies from the gbean instance definitions would actually be 
helpful?  IIRC when I asked about removing the dependency list from the 
geronimo-jetty.jar and putting the dependencies in the plan everyone 
thought it was a good idea.
>
> Another intention, which never really materialized as we went away 
> from XML, was to allow GBeanInfo to be declared in this file rather 
> than in the code - that way you could annotate the archive without 
> having any Geronimo references in the actual code. Remember, this was 
> GBeanInfo metadata describing the classes, not GBeanData defining 
> instances (as then the archive would be reserving specific instance 
> ids (names) which would lead to reuse problems). I don't know where 
> you GBean instances were getting defined but it should not have been 
> from this mechanism.

After some more thought I realized that only dependencies were getting 
included, not gbeans.
>
> I would contend that some of the confusion here stems from viewing 
> this as a deployment plan rather than as a definition of the GBean 
> types that the module provides and depends on. It could be because the 
> descriptor has not evolved with the rest of the architecture and 
> perhaps a better name would be less confusing - would gbean-info.xml 
> be clearer?
>
> Until we resolve issue about knowing what the nested dependencies are 
> I am reluctant to remove this feature - after all, if you don't need 
> it you don't have to use it.

Well, it was sort of in my way, although I can continue to support it 
fairly easily.

At the moment as far as I can tell it says nothing about what gbean 
types are available, and only provides a hidden way to include more 
dependencies.  I still don't see any use for it, but if anyone can find 
one I suggest we require a different element to be used in the plan to 
clearly distinguish dependencies with this recursive behavior from 
normal jar files.

thanks
david jencks
>
> --
> Jeremy
>