geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@gluecode.com>
Subject Re: Proposal to remove processing of geronimo-service.xml files in dependencies
Date Sat, 25 Dec 2004 19:50:21 GMT
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?

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.

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.

--
Jeremy

Mime
View raw message