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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
