geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: Proposal to remove processing of geronimo-service.xml files in dependencies
Date Mon, 27 Dec 2004 18:16:13 GMT
I think we have a geronimo project build problem here.  The specific 
problem we have it the geronimo-service.xml contained in the jetty 
module gets out of sync because it is the only module that uses this 
feature.  The root problems are the file name has a confusing name, and 
the version numbers are hard coded.  Propose we make the to changes to 
address these problems:

1. Rename the file to geronimo-dependencies.xml
2. Auto generate the file using a properties tag on the depend element 
in the project.xml file



Dain Sundstrom
Chief Architect
Gluecode Software
310.536.8355, ext. 26

On Dec 25, 2004, at 3:09 PM, David Jencks wrote:

> OK, I'm willing to agree that recursive lists of dependencies outside 
> a  plan are useful.  However, I still think it is essential that by 
> perusing a plan one can immediately determine whether something is 
> simply a bunch of classes or if it is or includes dependency or other 
> metadata.  More comments inline.
> On Dec 25, 2004, at 2:13 PM, Jeremy Boynes wrote:
>> 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?
> Well, we could deploy the jetty server in its own plan together with 
> its needed dependencies.  This is the best argument I've seen for the 
> feature under discussion.
>> 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).
> That would have fixed the immediate problems.
>> 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.
> Maybe.  I believe you would want to make the additional http listeners 
> children or descendants of the plan that included the jetty classes, 
> to avoid possible duplicate class problems.  Therefore, you would not 
> include any classes in the child plan, but get them all from the 
> parent config.
>> 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.
> True enough.  I could be remembering wrong but I thought there was 
> some enthusiastic support.
>>>> 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 don't remember this ever working, but my memory is not the best.  
> Right now (I think) you can easily gbean-ize other peoples classes 
> without modifying them by, for each class you wish to gbean-ize, 
> writing another that has the GBeanInfo and getGBeanInfo() methods, and 
> using the name of this helper class as the gbean config "class" 
> attribute value.  The helper doesn't have to extend the helpee AFAIK.
>>> 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.
> Changing the schema of the embedded list of dependencies won't help 
> with my main problem with this feature, which is that, by looking at a 
> plan, you can't tell if a dependency is just a jar or if it includes 
> this infinitely recursive tree of dependencies.  For instance, I'd be 
> much happier with something more maven-like where along with the jar 
> files the repo contained something like the pom as a separate file 
> listing the dependency info.  Then the dependency element could be 
> something like:
> <dependency>
>   <uri>foo/jars/foo.jar</uri>
>   <pom>foo/poms/geronimo-service.xml</pom>
> </dependency>
> or maybe for embedded geronimo-service.xml
> <dependency>
>   <uri>foo/jars/foo.jar</uri>
>   <embedded-pom/>
> </dependency>
> pom is obviously a pretty bad name for this but I haven't thought of a 
> better one.
> Many thanks,
> david jencks
>> --
>> Jeremy

View raw message