You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Jencks <dj...@gluecode.com> on 2004/12/25 09:09:43 UTC
Proposal to remove processing of geronimo-service.xml files in dependencies
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?
thanks
david jencks
Re: Lets make recursive dependencies obvious rather than hidden. [was Re: Proposal to remove processing of geronimo-service.xml files in dependencies]
Posted by Dain Sundstrom <ds...@gluecode.com>.
I dislike this because it requires intimate knowledge of the dependency
archive. For example, if you are using a module and it decides to use
nested dependencies then you will have to modify all plans.
As we have seen with war archives, users just want a single file that
Just Works (sm).
-dain
On Dec 27, 2004, at 12:08 PM, David Jencks wrote:
> I think I am completely failing to communicate my concern. Perhaps
> the problem is that the subject header is now completely misleading.
>
> I agree 100% that the external dependency list, now called
> geronimo-service.xml, is a good idea and should be kept under some
> name and syntax, and that we should spiff up the maven stuff so it
> gets its dependency versions set during the build. I don't care what
> we name it.
>
> What I would like is that by looking at the top level plan containing
> gbean instance definitions, you can easily see whether a dependency is
> a plain jar or if it contains more information such as a
> geronimo-service.xml. I suggested some syntax for this:
>
> <dependency>
> <uri>foo/jars/foo-1.0.jar</uri>
> <pom>foo/poms/geronimo-service.xml</pom>
> </dependency>
>
> for external dependency lists or
>
> <dependency>
> <uri>foo/jars/foo-1.0.jar</uri>
> <embedded-pom/>
> </dependency>
>
> Then, including just
>
> <dependency>
> <uri>foo/jars/foo-1.0.jar</uri>
> </dependency>
> would result in an embedded dependency list being ignored.
>
> Obviously, pom is the wrong name, but I haven't figured out a better
> one.
>
> thanks
> david jencks
Lets make recursive dependencies obvious rather than hidden. [was Re: Proposal to remove processing of geronimo-service.xml files in dependencies]
Posted by David Jencks <dj...@gluecode.com>.
I think I am completely failing to communicate my concern. Perhaps the
problem is that the subject header is now completely misleading.
I agree 100% that the external dependency list, now called
geronimo-service.xml, is a good idea and should be kept under some name
and syntax, and that we should spiff up the maven stuff so it gets its
dependency versions set during the build. I don't care what we name
it.
What I would like is that by looking at the top level plan containing
gbean instance definitions, you can easily see whether a dependency is
a plain jar or if it contains more information such as a
geronimo-service.xml. I suggested some syntax for this:
<dependency>
<uri>foo/jars/foo-1.0.jar</uri>
<pom>foo/poms/geronimo-service.xml</pom>
</dependency>
for external dependency lists or
<dependency>
<uri>foo/jars/foo-1.0.jar</uri>
<embedded-pom/>
</dependency>
Then, including just
<dependency>
<uri>foo/jars/foo-1.0.jar</uri>
</dependency>
would result in an embedded dependency list being ignored.
Obviously, pom is the wrong name, but I haven't figured out a better
one.
thanks
david jencks
On Dec 27, 2004, at 11:48 AM, Dain Sundstrom wrote:
> On Dec 27, 2004, at 11:31 AM, Jeremy Boynes wrote:
>
>> David Jencks wrote:
>>> After thinking about this some more I think the major issue is that
>>> one cannot tell from the top level plan whether a dependency is a
>>> plain jar or if it includes a 570-node tree of recursive
>>> sub-dependencies. Renaming and autogenerating the xml config file,
>>> while good ideas, won't help with this problem.
>>
>> The 570 nodes are still there - it comes down to do you want the user
>> to have to figure all that out by hand and explicitly put them in the
>> plan, or do you want the deployer to figure it out as it is building
>> the configuration.
>
> +1 As a user I frankly don't care what a module depends on, I just
> want want it installed. This is why wars contain a lib directory
> (which has it's own sucky problems).
>
>
>> I don't want to do it by hand so would opt to have the deployer do
>> it. Having a tool that told me what I needed put in the repo would be
>> useful though.
>
> Maybe our deployment tool could have an info operation that dumps
> "interesting" stuff about a module. Of course determining what is
> interesting maybe very difficult, and most likely requires asking the
> deployer gbeans on the server :)
>
> -dain
>
Re: Proposal to remove processing of geronimo-service.xml files in dependencies
Posted by Dain Sundstrom <ds...@gluecode.com>.
On Dec 27, 2004, at 11:31 AM, Jeremy Boynes wrote:
> David Jencks wrote:
>> After thinking about this some more I think the major issue is that
>> one cannot tell from the top level plan whether a dependency is a
>> plain jar or if it includes a 570-node tree of recursive
>> sub-dependencies. Renaming and autogenerating the xml config file,
>> while good ideas, won't help with this problem.
>
> The 570 nodes are still there - it comes down to do you want the user
> to have to figure all that out by hand and explicitly put them in the
> plan, or do you want the deployer to figure it out as it is building
> the configuration.
+1 As a user I frankly don't care what a module depends on, I just want
want it installed. This is why wars contain a lib directory (which has
it's own sucky problems).
> I don't want to do it by hand so would opt to have the deployer do it.
> Having a tool that told me what I needed put in the repo would be
> useful though.
Maybe our deployment tool could have an info operation that dumps
"interesting" stuff about a module. Of course determining what is
interesting maybe very difficult, and most likely requires asking the
deployer gbeans on the server :)
-dain
Re: Proposal to remove processing of geronimo-service.xml files in
dependencies
Posted by Jeremy Boynes <jb...@gluecode.com>.
David Jencks wrote:
> After thinking about this some more I think the major issue is that one
> cannot tell from the top level plan whether a dependency is a plain jar
> or if it includes a 570-node tree of recursive sub-dependencies.
> Renaming and autogenerating the xml config file, while good ideas, won't
> help with this problem.
>
The 570 nodes are still there - it comes down to do you want the user to
have to figure all that out by hand and explicitly put them in the plan,
or do you want the deployer to figure it out as it is building the
configuration.
I don't want to do it by hand so would opt to have the deployer do it.
Having a tool that told me what I needed put in the repo would be useful
though.
--
Jeremy
Re: Proposal to remove processing of geronimo-service.xml files in dependencies
Posted by David Jencks <dj...@gluecode.com>.
After thinking about this some more I think the major issue is that one
cannot tell from the top level plan whether a dependency is a plain jar
or if it includes a 570-node tree of recursive sub-dependencies.
Renaming and autogenerating the xml config file, while good ideas,
won't help with this problem.
thanks
david jencks
On Dec 27, 2004, at 10:47 AM, Jeremy Boynes wrote:
> Dain Sundstrom wrote:
>> 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
>
> I agree on renaming but would suggest something like
> geronimo-module.xml for the name to reflect that it might contain more
> than just dependency information (although that is all we do right
> now).
>
>> 2. Auto generate the file using a properties tag on the depend
>> element in the project.xml file
>> <dependency>
>> <groupId>jetty</groupId>
>> <artifactId>org.mortbay.jetty</artifactId>
>> <version>${jetty_version}</version>
>> <properties>
>> <geronimo.dependency>true</geronimo.dependency>
>> </properties>
>> </dependency>
>
> +1 - presumably this would be a modification to the plugin to generate
> the current file. In the future the plugin could also scan for gbean
> metadata in the source tree and fill out the other elements.
>
> --
> Jeremy
>
Re: Proposal to remove processing of geronimo-service.xml files in
dependencies
Posted by Jeremy Boynes <jb...@gluecode.com>.
Dain Sundstrom wrote:
> 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
I agree on renaming but would suggest something like geronimo-module.xml
for the name to reflect that it might contain more than just dependency
information (although that is all we do right now).
> 2. Auto generate the file using a properties tag on the depend element
> in the project.xml file
>
> <dependency>
> <groupId>jetty</groupId>
> <artifactId>org.mortbay.jetty</artifactId>
> <version>${jetty_version}</version>
> <properties>
> <geronimo.dependency>true</geronimo.dependency>
> </properties>
> </dependency>
>
+1 - presumably this would be a modification to the plugin to generate
the current file. In the future the plugin could also scan for gbean
metadata in the source tree and fill out the other elements.
--
Jeremy
Re: Proposal to remove processing of geronimo-service.xml files in dependencies
Posted by Dain Sundstrom <ds...@gluecode.com>.
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
<dependency>
<groupId>jetty</groupId>
<artifactId>org.mortbay.jetty</artifactId>
<version>${jetty_version}</version>
<properties>
<geronimo.dependency>true</geronimo.dependency>
</properties>
</dependency>
-dain
--
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
>>
Re: Proposal to remove processing of geronimo-service.xml files in dependencies
Posted by David Blevins <db...@gluecode.com>.
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:
>>>> 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.
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
>>
Re: Proposal to remove processing of geronimo-service.xml files in dependencies
Posted by David Jencks <dj...@gluecode.com>.
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
>
Re: Proposal to remove processing of geronimo-service.xml files in
dependencies
Posted by Jeremy Boynes <jb...@gluecode.com>.
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.
--
Jeremy
Re: Proposal to remove processing of geronimo-service.xml files in dependencies
Posted by David Jencks <dj...@gluecode.com>.
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
>
Re: Proposal to remove processing of geronimo-service.xml files in
dependencies
Posted by Jeremy Boynes <jb...@gluecode.com>.
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
Re: Proposal to remove processing of geronimo-service.xml files in dependencies
Posted by David Jencks <dj...@gluecode.com>.
First of all, I misunderstood the extent of the code yesterday. What
it does is recursively add dependencies, not gbeans or includes, when a
dependency mentioned in a service plan (not any j2ee plan) is deployed.
At this point I don't know how (or if) the jetty gbeans were getting
deployed from the embedded geronimo-service.xml, since I have
eradicated all copies of that file from my system.
I find the current behavior intolerably confusing. I can see 3 choices:
1. eliminate it, so all deployments use one plan, either in the module
being deployed or supplied separately
2. extend it so that:
- it is triggered by a separate tag rather than recycling the
dependency tag
- it can fully deploy any deployable artifact, including j2ee modules
- it can accept an external plan
3. keep this functionality but use a different element for it so it
cannot be confused with a simple dependency.
I vote for (1).
On Dec 25, 2004, at 8:41 AM, Jacek Laskowski 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.
>
> That's exactly the feature which prevented me from including
> geronimo-service.xml in the tomcat module! You found it! I didn't
> forget about it and want to enable it to simplify the deployment (and
> leverage the concept of Jeremy where people could download their
> configuration and inject it into a running Geronimo instance).
I don't think this feature will help you in any way to do that, but I
could misunderstand what you are trying to do. I think what you are
mentioning is the ability to load configurations into a running server,
which is a capability at a different level of functionality than this.
>
>> 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?
>
> Isn't it similar in concept to the way Maven should be working, but it
> isn't at the moment. Every time you include project X jars as
> dependencies you'll have to figure out what projects the project X
> jars rely upon. It simply leads to a nightmare to configure a
> project's dependencies, which is a PITA. I'm not convinced if removing
> the feature will bring any simplicity. Yeah, your use case suggests it
> will, but mine shows end users will face more complexity. We'll shift
> it from the developers (us) to end users (also us, but I think about
> the less familiar with the internals).
>
> Moreover, I think it will also break what I have aforementioned above
> - the ability to configure Geronimo on-the-fly (well, I'm not sure if
> it's a right term for it). What I mean is to create a plan and don't
> think about the rest dependencies the services (gbeans) rely upon.
> They'll be downloaded - user won't have to figure it out yourself.
The ability to configure geronimo on the fly is due to the ability to
load and start configurations into a geronimo server. The feature
under discussion is simply a particularly obscure way to extend the
classpath of some configurations (those specified by a service plan
rather than a j2ee plan). However, we have an alternate way to extend
classpaths, although in sort of the opposite direction: the
parent-child relationship of configurations. The parent-child
relationship of configurations is explicit and easy to detect from the
child plan. Use of the feature under discussion is impossible to
detect from the plan using it, since you have to examine the contents
of each listed dependency.
Currently "download and run" configurations are not too likely to work
because most configurations rely on the local geronimo repository for
large parts of their classpath. I believe we could make
download-and-run configurations by using "include" rather than
"dependency", but this is not supported in most plan types and the
feature under discussion works only for "dependency".
Many thanks,
david jencks
>
>> david jencks
>
> Jacek
>
Re: Proposal to remove processing of geronimo-service.xml files in
dependencies
Posted by Jacek Laskowski <jl...@apache.org>.
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.
That's exactly the feature which prevented me from including
geronimo-service.xml in the tomcat module! You found it! I didn't forget
about it and want to enable it to simplify the deployment (and leverage
the concept of Jeremy where people could download their configuration
and inject it into a running Geronimo instance).
> 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?
Isn't it similar in concept to the way Maven should be working, but it
isn't at the moment. Every time you include project X jars as
dependencies you'll have to figure out what projects the project X jars
rely upon. It simply leads to a nightmare to configure a project's
dependencies, which is a PITA. I'm not convinced if removing the feature
will bring any simplicity. Yeah, your use case suggests it will, but
mine shows end users will face more complexity. We'll shift it from the
developers (us) to end users (also us, but I think about the less
familiar with the internals).
Moreover, I think it will also break what I have aforementioned above -
the ability to configure Geronimo on-the-fly (well, I'm not sure if it's
a right term for it). What I mean is to create a plan and don't think
about the rest dependencies the services (gbeans) rely upon. They'll be
downloaded - user won't have to figure it out yourself.
> david jencks
Jacek
Re: Proposal to remove processing of geronimo-service.xml files in
dependencies
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Works for me.
Aaron
On Sat, 25 Dec 2004, 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?
>
> thanks
> david jencks
>
>