geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <ammul...@alumni.princeton.edu>
Subject Re: GBeans: Saving Changes
Date Tue, 26 Jul 2005 22:43:44 GMT
On Tue, 26 Jul 2005, David Jencks wrote:
> Now that how saving configuration works has been explained so even I 
> can understand it, I don't have any problem in saving configuration 
> locally.  I can even imagine a tool to merge a local state with a 
> configuration to produce a new configuration (with a different version 
> number or name).

Great.

> Before we jump into adding gbeans to a running 
> configuration, can we please think about whether the "disabled gbean" 
> approach would work just as well, and, if not, if the "application 
> centered deployment" idea would work better.  IIRC the original 
> motivation behind GERONIMO-400 was to put the admin objects you can add 
> by the admin portal into the original jms configuration rather than 
> making a separate configuration per queue/topic.  If you have the 
> opportunity to add the admin objects  while you are deploying your app 
> that will use them, I can't actually see any reason to support 
> deploying "standalone" admin objects at all, whatever configuration 
> they go into.

RE "disabled GBeans" ("blanks"): The counter-example I gave in JIRA was
security realms, which may use any number of LoginModules.  It doesn't
make sense to me to add "enough" blanks that you're sure no one would ever
want to add more than that, nor to require that someone writing a new plan
for their own purposes add "enough" blanks to accomodate future changes
via the web console.  What number would you tell them?  10?  5?

RE "app-centric deployment": And again, I believe there are cases where
server administrators will be configuring the services in the server, and
will not have the skills or tools to alter embedded XML files in the
application configuration.  This is more realistic for web listen ports,
security realms, databases (where devs may not have prod DB password) or
J2CA connections to back-end services than for admin objects (which I
admit could often be best packaged with an application).  Even without the
administrator vs. developer issue, imagine staging your application from
dev to test to production, where each server has connections to different
databases and back-end services.  It would be much nicer to put that
configuration in the app server, so the application itself can be totally
unchanged when it's migrated between environments.  The application says
"I use a data source called 'DB2'", and the server provides the data
source pointing to a specific database, different in each of the 3 
environments.

I do like the *ability* to deploy data sources with an app -- just not 
making it the only options.

Aaron

Mime
View raw message