Just getting caught up on this thread....
Seems we have two conversations going on. One regarding transitive dependencies and another regarding out-of-code declaration of GBeanInfo. Comments on out-of-code declaration of GBeanInfo below.
On Dec 25, 2004, at 5: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: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.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?
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.
After some more thought I realized that only dependencies were getting included, not gbeans.
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.Well, it was sort of in my way, although I can continue to support it fairly easily.
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.
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.
Right, I gbean-ized a few more things in OpenEJB recently using that exact technique. It works pretty well. I added other methods to those "helper" classes that construct a GBeanData for you, which is primarily for testing. I test those "helpee" classes first by instantiating them directly with an old fashioned "new Foo()" then again in a kernel with GBeanData created using the helper's createGBeanData method which is identical in arguments as it's constructor. It's pretty cool as I can:
- test the helpee as a plain old object
- use the same test code to test the helpee's again as GBeans
- prevent scattering GBeanData (or old GBeanMBean code) throughout all the test cases
- consolidate the GBeanInfo and GBeanData construction code which are just two sides of the same coin
- keep GBean code out of the critical-path code, though it is still in code elsewhere.
This isn't the same as having the GBeanInfo entirely out of code but does go a long way.
-David
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
