On Jul 26, 2005, at 3:43 PM, Aaron Mulder wrote:
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?
I think this is a prime example of where you should use app-centric
deployment, i.e. put the security gbeans in the application.
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'd think you'd want to have a compatibility-layer configuration
including all the app specific stuff that needs to be different for
each server. Each environment would get its own compatibility layer,
exposing the same stuff to the application.
I do like the *ability* to deploy data sources with an app -- just not
making it the only options.
I think we might be missing the point to some extent. We all want
geronimo to be easy to use and configure, and scale well to really
large deployments. Obviously we need ways to deploy applications so
they run, and all their needs are met. The questions seem to me to be
"when" (deploy or runtime) and "where" (which configuration). Other
servers AFAIK tend to have monolithic server configurations and limited
application configuration, and a lot of server configuration may have
to be done at runtime. What if we take a step back from what we are
used to doing and think if there is a better way.
One point of view is that if you have to change something on your
running server, your deployment tools weren't good enough: they should
be good enough so when you deploy, everything is there, and it works.
This is sort of like type safety in compiled languages: by the time you
get to running, the system has already eliminated many classes of
errors.
thanks
david jencks
Aaron
