You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Aaron Mulder <am...@alumni.princeton.edu> on 2006/04/23 22:38:48 UTC
SUMMARY OF: Change "configuration" to "module"
So everyone seems to be in favor.
I'm 100% in favor of making this change in our documentation and
presentations and so on.
I'm 95% in favor of changing "configId" to "moduleId" in our plans --
just need to find the time to do it and it'll be an extensive change
to the current plans in Geronimo and the TCK. Even if we silently
upgrade plans using "configId" during deployment I think we want the
plans distributed with the server to use the recommended syntax
wherever possible. Any volunteers?
I'm not necessarily in favor of changing CAR to MAR. That's used so
infrequently (and saying "just apply this MAR to your server" sounds
so dubious) that I think we can just say "it's a just a CAR; it
doesn't stand for anything". Or call them plugins instead. :)
And while it might be nice to change the names of some of the server
guts dealing with configurations (ConfigurationInfo,
ConfigurationData, etc.) I don't feel the urge to do that myself -- if
someone else wants to take a swing at it, be my guest.
Thanks,
Aaron
On 4/23/06, Matt Hogstrom <ma...@hogstrom.org> wrote:
> +1
>
> Aaron Mulder wrote:
> > All,
> >
> > How would you feel about referring to configurations (e.g. a group of
> > GBeans with own ID and classloader) as a "module" instead? It seems
> > like "configuration" can be confusing, as it more traditionally refers
> > to a larger scope like an entire installation. For example, if you
> > say you have two different WebLogic configurations or two different
> > Apache (HTTP) configurations, you're saying either you have two
> > installations, or you have two totally separate product configurations
> > available for the same product installation. You're not saying you
> > have an app and a database pool within one runtime, but that's what
> > "two different configurations" presently would mean in relation to
> > Geronimo.
> >
> > It seems like it would be clearer to say that a Geronimo installation
> > loads many modules, and each module includes many components (GBeans).
> >
> > I'm not proposing that we go changing class names and stuff, but I'm
> > proposing that we make a concerted effort in our documentation and
> > presentations to present the name of the "unit with an ID and
> > classloader holding many components" as a "module".
> >
> > What do you think?
> >
> > Thanks,
> > Aaron
> >
> >
> >
>
Re: SUMMARY OF: Change "configuration" to "module"
Posted by Jeff Genender <jg...@savoirtech.com>.
Aaron Mulder wrote:
> On 4/23/06, Jeff Genender <jg...@savoirtech.com> wrote:
>> Will there be an impact on existing users who have their
>> web/applications using configId? If so will/can we accept both? I
>> would hate to break backwards compatibility on this.
>
> Well, we've changed the syntax dramatically between 1.0 and 1.1 (e.g.
> the configId used to be a single XML attribute and now it's 4 separate
> elements, the parents and imports are handled differently, etc.). Are
> you worried about users who have 1.0 plans, or users who have pre-1.1
> plans?
Yep, I know a couple of companies that are using G in production and are
concerned in particular about this.
> I'm sure we're planning to auto-convert 1.0 plans to the 1.1
> syntax whatever it ends up being. Do you think we need to support the
> older 1.1 syntax if we adopt the newer 1.1 syntax?
Probably, and unfortunately yes. However, if we are going to make a
clean break, can we bridge like we did with the
geronimo-jetty.xml/geronimo-web.xml? i.e. accept the old with a stern
warning? We do have a few core early adopters that will be impacted.
>
> OLD
>
> <web-app configId="group/artifact/version/type"
> parentId="group/artifact/version/type">
>
> CURRENT-PRE-1.1
>
> <web-app>
> <environment>
> <configId>
> <groupId>...</groupId>
> <artifactId>...</artifactId>
> <version>...</version>
> <type>...</type>
> </configId>
> <dependency>
> ...
> </dependency>
> </environment>
>
> PROPOSED-PRE-1.1
>
> <web-app>
> <environment>
> <moduleId>
> <groupId>...</groupId>
> <artifactId>...</artifactId>
> <version>...</version>
> <type>...</type>
> </moduleId>
> <dependency>
> ...
> </dependency>
> </environment>
>
> Thanks,
> Aaron
>
>> Aaron Mulder wrote:
>>> I think we can do it in a night. All we need is a sed script -- the
>>> syntax isn't changing other than literally replacing all occurances of
>>> "configId" with "moduleId" in *.xml files.
>>>
>>> Thanks,
>>> Aaron
>>>
>>> On 4/23/06, Matt Hogstrom <ma...@hogstrom.org> wrote:
>>>> I'm for the change but as I ponder the ramifications to 1.1 I'm afraid the scope of this
>>>> modification is too large. The TCK needs to be updated, lots of hard references, etc.
>>>>
>>>> I vote that we change this in 1.2 and leave them as configId for now. If we take this on I'm
>>>> confident that we'll miss Java One.
>>>>
>>>> -1 for 1.1
>>>> +1 for 1.2
>>>>
>>>> Thoughts?
>>>>
>>>> Matt
>>>>
>>>> Aaron Mulder wrote:
>>>>> So everyone seems to be in favor.
>>>>>
>>>>> I'm 100% in favor of making this change in our documentation and
>>>>> presentations and so on.
>>>>>
>>>>> I'm 95% in favor of changing "configId" to "moduleId" in our plans --
>>>>> just need to find the time to do it and it'll be an extensive change
>>>>> to the current plans in Geronimo and the TCK. Even if we silently
>>>>> upgrade plans using "configId" during deployment I think we want the
>>>>> plans distributed with the server to use the recommended syntax
>>>>> wherever possible. Any volunteers?
>>>>>
>>>>> I'm not necessarily in favor of changing CAR to MAR. That's used so
>>>>> infrequently (and saying "just apply this MAR to your server" sounds
>>>>> so dubious) that I think we can just say "it's a just a CAR; it
>>>>> doesn't stand for anything". Or call them plugins instead. :)
>>>>>
>>>>> And while it might be nice to change the names of some of the server
>>>>> guts dealing with configurations (ConfigurationInfo,
>>>>> ConfigurationData, etc.) I don't feel the urge to do that myself -- if
>>>>> someone else wants to take a swing at it, be my guest.
>>>>>
>>>>> Thanks,
>>>>> Aaron
>>>>>
>>>>> On 4/23/06, Matt Hogstrom <ma...@hogstrom.org> wrote:
>>>>>
>>>>>> +1
>>>>>>
>>>>>> Aaron Mulder wrote:
>>>>>>
>>>>>>> All,
>>>>>>>
>>>>>>> How would you feel about referring to configurations (e.g. a group of
>>>>>>> GBeans with own ID and classloader) as a "module" instead? It seems
>>>>>>> like "configuration" can be confusing, as it more traditionally refers
>>>>>>> to a larger scope like an entire installation. For example, if you
>>>>>>> say you have two different WebLogic configurations or two different
>>>>>>> Apache (HTTP) configurations, you're saying either you have two
>>>>>>> installations, or you have two totally separate product configurations
>>>>>>> available for the same product installation. You're not saying you
>>>>>>> have an app and a database pool within one runtime, but that's what
>>>>>>> "two different configurations" presently would mean in relation to
>>>>>>> Geronimo.
>>>>>>>
>>>>>>> It seems like it would be clearer to say that a Geronimo installation
>>>>>>> loads many modules, and each module includes many components (GBeans).
>>>>>>>
>>>>>>> I'm not proposing that we go changing class names and stuff, but I'm
>>>>>>> proposing that we make a concerted effort in our documentation and
>>>>>>> presentations to present the name of the "unit with an ID and
>>>>>>> classloader holding many components" as a "module".
>>>>>>>
>>>>>>> What do you think?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Aaron
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
Re: SUMMARY OF: Change "configuration" to "module"
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On 4/23/06, Jeff Genender <jg...@savoirtech.com> wrote:
> Will there be an impact on existing users who have their
> web/applications using configId? If so will/can we accept both? I
> would hate to break backwards compatibility on this.
Well, we've changed the syntax dramatically between 1.0 and 1.1 (e.g.
the configId used to be a single XML attribute and now it's 4 separate
elements, the parents and imports are handled differently, etc.). Are
you worried about users who have 1.0 plans, or users who have pre-1.1
plans? I'm sure we're planning to auto-convert 1.0 plans to the 1.1
syntax whatever it ends up being. Do you think we need to support the
older 1.1 syntax if we adopt the newer 1.1 syntax?
OLD
<web-app configId="group/artifact/version/type"
parentId="group/artifact/version/type">
CURRENT-PRE-1.1
<web-app>
<environment>
<configId>
<groupId>...</groupId>
<artifactId>...</artifactId>
<version>...</version>
<type>...</type>
</configId>
<dependency>
...
</dependency>
</environment>
PROPOSED-PRE-1.1
<web-app>
<environment>
<moduleId>
<groupId>...</groupId>
<artifactId>...</artifactId>
<version>...</version>
<type>...</type>
</moduleId>
<dependency>
...
</dependency>
</environment>
Thanks,
Aaron
> Aaron Mulder wrote:
> > I think we can do it in a night. All we need is a sed script -- the
> > syntax isn't changing other than literally replacing all occurances of
> > "configId" with "moduleId" in *.xml files.
> >
> > Thanks,
> > Aaron
> >
> > On 4/23/06, Matt Hogstrom <ma...@hogstrom.org> wrote:
> >> I'm for the change but as I ponder the ramifications to 1.1 I'm afraid the scope of this
> >> modification is too large. The TCK needs to be updated, lots of hard references, etc.
> >>
> >> I vote that we change this in 1.2 and leave them as configId for now. If we take this on I'm
> >> confident that we'll miss Java One.
> >>
> >> -1 for 1.1
> >> +1 for 1.2
> >>
> >> Thoughts?
> >>
> >> Matt
> >>
> >> Aaron Mulder wrote:
> >>> So everyone seems to be in favor.
> >>>
> >>> I'm 100% in favor of making this change in our documentation and
> >>> presentations and so on.
> >>>
> >>> I'm 95% in favor of changing "configId" to "moduleId" in our plans --
> >>> just need to find the time to do it and it'll be an extensive change
> >>> to the current plans in Geronimo and the TCK. Even if we silently
> >>> upgrade plans using "configId" during deployment I think we want the
> >>> plans distributed with the server to use the recommended syntax
> >>> wherever possible. Any volunteers?
> >>>
> >>> I'm not necessarily in favor of changing CAR to MAR. That's used so
> >>> infrequently (and saying "just apply this MAR to your server" sounds
> >>> so dubious) that I think we can just say "it's a just a CAR; it
> >>> doesn't stand for anything". Or call them plugins instead. :)
> >>>
> >>> And while it might be nice to change the names of some of the server
> >>> guts dealing with configurations (ConfigurationInfo,
> >>> ConfigurationData, etc.) I don't feel the urge to do that myself -- if
> >>> someone else wants to take a swing at it, be my guest.
> >>>
> >>> Thanks,
> >>> Aaron
> >>>
> >>> On 4/23/06, Matt Hogstrom <ma...@hogstrom.org> wrote:
> >>>
> >>>> +1
> >>>>
> >>>> Aaron Mulder wrote:
> >>>>
> >>>>> All,
> >>>>>
> >>>>> How would you feel about referring to configurations (e.g. a group of
> >>>>> GBeans with own ID and classloader) as a "module" instead? It seems
> >>>>> like "configuration" can be confusing, as it more traditionally refers
> >>>>> to a larger scope like an entire installation. For example, if you
> >>>>> say you have two different WebLogic configurations or two different
> >>>>> Apache (HTTP) configurations, you're saying either you have two
> >>>>> installations, or you have two totally separate product configurations
> >>>>> available for the same product installation. You're not saying you
> >>>>> have an app and a database pool within one runtime, but that's what
> >>>>> "two different configurations" presently would mean in relation to
> >>>>> Geronimo.
> >>>>>
> >>>>> It seems like it would be clearer to say that a Geronimo installation
> >>>>> loads many modules, and each module includes many components (GBeans).
> >>>>>
> >>>>> I'm not proposing that we go changing class names and stuff, but I'm
> >>>>> proposing that we make a concerted effort in our documentation and
> >>>>> presentations to present the name of the "unit with an ID and
> >>>>> classloader holding many components" as a "module".
> >>>>>
> >>>>> What do you think?
> >>>>>
> >>>>> Thanks,
> >>>>> Aaron
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
>
Re: SUMMARY OF: Change "configuration" to "module"
Posted by Jeff Genender <jg...@savoirtech.com>.
Will there be an impact on existing users who have their
web/applications using configId? If so will/can we accept both? I
would hate to break backwards compatibility on this.
Jeff
Aaron Mulder wrote:
> I think we can do it in a night. All we need is a sed script -- the
> syntax isn't changing other than literally replacing all occurances of
> "configId" with "moduleId" in *.xml files.
>
> Thanks,
> Aaron
>
> On 4/23/06, Matt Hogstrom <ma...@hogstrom.org> wrote:
>> I'm for the change but as I ponder the ramifications to 1.1 I'm afraid the scope of this
>> modification is too large. The TCK needs to be updated, lots of hard references, etc.
>>
>> I vote that we change this in 1.2 and leave them as configId for now. If we take this on I'm
>> confident that we'll miss Java One.
>>
>> -1 for 1.1
>> +1 for 1.2
>>
>> Thoughts?
>>
>> Matt
>>
>> Aaron Mulder wrote:
>>> So everyone seems to be in favor.
>>>
>>> I'm 100% in favor of making this change in our documentation and
>>> presentations and so on.
>>>
>>> I'm 95% in favor of changing "configId" to "moduleId" in our plans --
>>> just need to find the time to do it and it'll be an extensive change
>>> to the current plans in Geronimo and the TCK. Even if we silently
>>> upgrade plans using "configId" during deployment I think we want the
>>> plans distributed with the server to use the recommended syntax
>>> wherever possible. Any volunteers?
>>>
>>> I'm not necessarily in favor of changing CAR to MAR. That's used so
>>> infrequently (and saying "just apply this MAR to your server" sounds
>>> so dubious) that I think we can just say "it's a just a CAR; it
>>> doesn't stand for anything". Or call them plugins instead. :)
>>>
>>> And while it might be nice to change the names of some of the server
>>> guts dealing with configurations (ConfigurationInfo,
>>> ConfigurationData, etc.) I don't feel the urge to do that myself -- if
>>> someone else wants to take a swing at it, be my guest.
>>>
>>> Thanks,
>>> Aaron
>>>
>>> On 4/23/06, Matt Hogstrom <ma...@hogstrom.org> wrote:
>>>
>>>> +1
>>>>
>>>> Aaron Mulder wrote:
>>>>
>>>>> All,
>>>>>
>>>>> How would you feel about referring to configurations (e.g. a group of
>>>>> GBeans with own ID and classloader) as a "module" instead? It seems
>>>>> like "configuration" can be confusing, as it more traditionally refers
>>>>> to a larger scope like an entire installation. For example, if you
>>>>> say you have two different WebLogic configurations or two different
>>>>> Apache (HTTP) configurations, you're saying either you have two
>>>>> installations, or you have two totally separate product configurations
>>>>> available for the same product installation. You're not saying you
>>>>> have an app and a database pool within one runtime, but that's what
>>>>> "two different configurations" presently would mean in relation to
>>>>> Geronimo.
>>>>>
>>>>> It seems like it would be clearer to say that a Geronimo installation
>>>>> loads many modules, and each module includes many components (GBeans).
>>>>>
>>>>> I'm not proposing that we go changing class names and stuff, but I'm
>>>>> proposing that we make a concerted effort in our documentation and
>>>>> presentations to present the name of the "unit with an ID and
>>>>> classloader holding many components" as a "module".
>>>>>
>>>>> What do you think?
>>>>>
>>>>> Thanks,
>>>>> Aaron
>>>>>
>>>>>
>>>>>
>>>
>>>
Re: SUMMARY OF: Change "configuration" to "module"
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
I think we can do it in a night. All we need is a sed script -- the
syntax isn't changing other than literally replacing all occurances of
"configId" with "moduleId" in *.xml files.
Thanks,
Aaron
On 4/23/06, Matt Hogstrom <ma...@hogstrom.org> wrote:
> I'm for the change but as I ponder the ramifications to 1.1 I'm afraid the scope of this
> modification is too large. The TCK needs to be updated, lots of hard references, etc.
>
> I vote that we change this in 1.2 and leave them as configId for now. If we take this on I'm
> confident that we'll miss Java One.
>
> -1 for 1.1
> +1 for 1.2
>
> Thoughts?
>
> Matt
>
> Aaron Mulder wrote:
> > So everyone seems to be in favor.
> >
> > I'm 100% in favor of making this change in our documentation and
> > presentations and so on.
> >
> > I'm 95% in favor of changing "configId" to "moduleId" in our plans --
> > just need to find the time to do it and it'll be an extensive change
> > to the current plans in Geronimo and the TCK. Even if we silently
> > upgrade plans using "configId" during deployment I think we want the
> > plans distributed with the server to use the recommended syntax
> > wherever possible. Any volunteers?
> >
> > I'm not necessarily in favor of changing CAR to MAR. That's used so
> > infrequently (and saying "just apply this MAR to your server" sounds
> > so dubious) that I think we can just say "it's a just a CAR; it
> > doesn't stand for anything". Or call them plugins instead. :)
> >
> > And while it might be nice to change the names of some of the server
> > guts dealing with configurations (ConfigurationInfo,
> > ConfigurationData, etc.) I don't feel the urge to do that myself -- if
> > someone else wants to take a swing at it, be my guest.
> >
> > Thanks,
> > Aaron
> >
> > On 4/23/06, Matt Hogstrom <ma...@hogstrom.org> wrote:
> >
> >>+1
> >>
> >>Aaron Mulder wrote:
> >>
> >>>All,
> >>>
> >>>How would you feel about referring to configurations (e.g. a group of
> >>>GBeans with own ID and classloader) as a "module" instead? It seems
> >>>like "configuration" can be confusing, as it more traditionally refers
> >>>to a larger scope like an entire installation. For example, if you
> >>>say you have two different WebLogic configurations or two different
> >>>Apache (HTTP) configurations, you're saying either you have two
> >>>installations, or you have two totally separate product configurations
> >>>available for the same product installation. You're not saying you
> >>>have an app and a database pool within one runtime, but that's what
> >>>"two different configurations" presently would mean in relation to
> >>>Geronimo.
> >>>
> >>>It seems like it would be clearer to say that a Geronimo installation
> >>>loads many modules, and each module includes many components (GBeans).
> >>>
> >>>I'm not proposing that we go changing class names and stuff, but I'm
> >>>proposing that we make a concerted effort in our documentation and
> >>>presentations to present the name of the "unit with an ID and
> >>>classloader holding many components" as a "module".
> >>>
> >>>What do you think?
> >>>
> >>>Thanks,
> >>> Aaron
> >>>
> >>>
> >>>
> >>
> >
> >
> >
>
Re: SUMMARY OF: Change "configuration" to "module"
Posted by Jeff Genender <jg...@savoirtech.com>.
I would need to agree with Alan and Matt on this...
-1 for 1.1
+1 for 1.2
Alan D. Cabrera wrote:
>
>
> Matt Hogstrom wrote:
>> I'm for the change but as I ponder the ramifications to 1.1 I'm afraid
>> the scope of this modification is too large. The TCK needs to be
>> updated, lots of hard references, etc.
>>
>> I vote that we change this in 1.2 and leave them as configId for now.
>> If we take this on I'm confident that we'll miss Java One.
>>
>> -1 for 1.1
>> +1 for 1.2
>>
>> Thoughts?
>>
> -1 1.1
> +1 1.2
>
>
> Regards,
> Alan
>
Re: SUMMARY OF: Change "configuration" to "module"
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Matt Hogstrom wrote:
> I'm for the change but as I ponder the ramifications to 1.1 I'm afraid
> the scope of this modification is too large. The TCK needs to be
> updated, lots of hard references, etc.
>
> I vote that we change this in 1.2 and leave them as configId for now.
> If we take this on I'm confident that we'll miss Java One.
>
> -1 for 1.1
> +1 for 1.2
>
> Thoughts?
>
-1 1.1
+1 1.2
Regards,
Alan
Re: SUMMARY OF: Change "configuration" to "module"
Posted by Matt Hogstrom <ma...@hogstrom.org>.
I'm for the change but as I ponder the ramifications to 1.1 I'm afraid the scope of this
modification is too large. The TCK needs to be updated, lots of hard references, etc.
I vote that we change this in 1.2 and leave them as configId for now. If we take this on I'm
confident that we'll miss Java One.
-1 for 1.1
+1 for 1.2
Thoughts?
Matt
Aaron Mulder wrote:
> So everyone seems to be in favor.
>
> I'm 100% in favor of making this change in our documentation and
> presentations and so on.
>
> I'm 95% in favor of changing "configId" to "moduleId" in our plans --
> just need to find the time to do it and it'll be an extensive change
> to the current plans in Geronimo and the TCK. Even if we silently
> upgrade plans using "configId" during deployment I think we want the
> plans distributed with the server to use the recommended syntax
> wherever possible. Any volunteers?
>
> I'm not necessarily in favor of changing CAR to MAR. That's used so
> infrequently (and saying "just apply this MAR to your server" sounds
> so dubious) that I think we can just say "it's a just a CAR; it
> doesn't stand for anything". Or call them plugins instead. :)
>
> And while it might be nice to change the names of some of the server
> guts dealing with configurations (ConfigurationInfo,
> ConfigurationData, etc.) I don't feel the urge to do that myself -- if
> someone else wants to take a swing at it, be my guest.
>
> Thanks,
> Aaron
>
> On 4/23/06, Matt Hogstrom <ma...@hogstrom.org> wrote:
>
>>+1
>>
>>Aaron Mulder wrote:
>>
>>>All,
>>>
>>>How would you feel about referring to configurations (e.g. a group of
>>>GBeans with own ID and classloader) as a "module" instead? It seems
>>>like "configuration" can be confusing, as it more traditionally refers
>>>to a larger scope like an entire installation. For example, if you
>>>say you have two different WebLogic configurations or two different
>>>Apache (HTTP) configurations, you're saying either you have two
>>>installations, or you have two totally separate product configurations
>>>available for the same product installation. You're not saying you
>>>have an app and a database pool within one runtime, but that's what
>>>"two different configurations" presently would mean in relation to
>>>Geronimo.
>>>
>>>It seems like it would be clearer to say that a Geronimo installation
>>>loads many modules, and each module includes many components (GBeans).
>>>
>>>I'm not proposing that we go changing class names and stuff, but I'm
>>>proposing that we make a concerted effort in our documentation and
>>>presentations to present the name of the "unit with an ID and
>>>classloader holding many components" as a "module".
>>>
>>>What do you think?
>>>
>>>Thanks,
>>> Aaron
>>>
>>>
>>>
>>
>
>
>
Re: SUMMARY OF: Change "configuration" to "module"
Posted by anita kulshreshtha <a_...@yahoo.com>.
Comments inline..
--- Aaron Mulder <am...@alumni.princeton.edu> wrote:
> So everyone seems to be in favor.
>
> I'm 100% in favor of making this change in our documentation and
> presentations and so on.
>
> I'm 95% in favor of changing "configId" to "moduleId" in our plans --
> just need to find the time to do it and it'll be an extensive change
> to the current plans in Geronimo and the TCK. Even if we silently
> upgrade plans using "configId" during deployment I think we want the
> plans distributed with the server to use the recommended syntax
> wherever possible. Any volunteers?
Count me in. I can do Geronimo. If you have a list of what all is
affected (other than configs/**/plan.xml), I can start from there.
>
> I'm not necessarily in favor of changing CAR to MAR. That's used so
> infrequently (and saying "just apply this MAR to your server" sounds
> so dubious)
I did not like the sound of 'MAR' either, just mentioned it to start
the conversation ;-)
Thanks
Anita
that I think we can just say "it's a just a CAR; it
> doesn't stand for anything". Or call them plugins instead. :)
>
> And while it might be nice to change the names of some of the server
> guts dealing with configurations (ConfigurationInfo,
> ConfigurationData, etc.) I don't feel the urge to do that myself --
> if
> someone else wants to take a swing at it, be my guest.
>
> Thanks,
> Aaron
>
> On 4/23/06, Matt Hogstrom <ma...@hogstrom.org> wrote:
> > +1
> >
> > Aaron Mulder wrote:
> > > All,
> > >
> > > How would you feel about referring to configurations (e.g. a
> group of
> > > GBeans with own ID and classloader) as a "module" instead? It
> seems
> > > like "configuration" can be confusing, as it more traditionally
> refers
> > > to a larger scope like an entire installation. For example, if
> you
> > > say you have two different WebLogic configurations or two
> different
> > > Apache (HTTP) configurations, you're saying either you have two
> > > installations, or you have two totally separate product
> configurations
> > > available for the same product installation. You're not saying
> you
> > > have an app and a database pool within one runtime, but that's
> what
> > > "two different configurations" presently would mean in relation
> to
> > > Geronimo.
> > >
> > > It seems like it would be clearer to say that a Geronimo
> installation
> > > loads many modules, and each module includes many components
> (GBeans).
> > >
> > > I'm not proposing that we go changing class names and stuff, but
> I'm
> > > proposing that we make a concerted effort in our documentation
> and
> > > presentations to present the name of the "unit with an ID and
> > > classloader holding many components" as a "module".
> > >
> > > What do you think?
> > >
> > > Thanks,
> > > Aaron
> > >
> > >
> > >
> >
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com