geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <>
Subject Re: Proposal to remove processing of geronimo-service.xml files in dependencies
Date Sat, 25 Dec 2004 22:13:13 GMT
David Jencks wrote:
> 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.

That's the thing - a plan is a manifestation of an entire configuration 
rather than being specific to just this sub-service/set of components. 
For example, how do I know which dependencies in j2ee-server-plan.xml 
are necessary for geronimo-jetty as opposed to any of the other stuff 
that is in there?

As I remember it, the problem we were facing was that the versions in 
the jar built by the geronimo-jetty module kept getting out of sync with 
those used by the assembly module that was populating the repo. The 
simple solution to that is one we have used elsewhere - to process the 
geronimo-service.xml file with Velocity as part of the build (so it 
includes the same versions listed in the project.xml which are actually 
inherited from the global properties).

There is a clear distinction between "class" level data - such as 
dependencies and GBeanInfo - from "instance" level data such as 
ObjectName (instance id) and attribute values. This is perhaps less 
apparent with something such as the Jetty container that is typically a 
singleton but might be clearer if you consider something like a HTTP 
listener which may well be instantiated multiple times.

BTW, I don't get the "everyone thought it was a good idea" meme as 
justification for doing stuff - typically most people go with the flow 
rather than taking the time to fully consider an issue. A democracy that 
votes that PI equals 3 will have odd shaped wheels and a bumpy ride.

>> 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.  

As I said above, the intention was to allow out-of-code declaration of 
GBeanInfo so that you could annotate classes without having code-level 
dependencies on Geronimo classes. Specifically, it would allow us to 
create a GBeanInfo object for a class during deployment without having 
to have a static block in the code; this would allow the Class to be 
reused outside a Geronimo environment. This has no advantage for 
Geronimo-specific implementations but a lot of benefit to projects such 
as ActiveMQ that are looking to share component implementations between 
container frameworks.

At one point we had that working, but that was before we split "class" 
metadata from "instance" data. As part of that split we kept the 
dependency mechanism because it was useful but lost the class metadata 
stuff because we moved all of it into static code blocks. That was also 
before we had other projects looking at building components for use in 
multiple containers.

> 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.

I think dependency clearly identifies the nature of the relationship - 
this jar file is dependent on other jars for it to work in _exactly_ the 
same way a configuration is dependent on them. It would be better to 
change the schema or root element to indicate more clearly that is this 
a description of a component jar rather than an instance of a configuration.


View raw message