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 2005/07/25 04:43:16 UTC
GBeans: Saving Changes
So the console can write to persistent attributes of GBeans -- and
I think they're taking effect (you can log out and log back in and see the
changed value, at any rate). However, if you restart the server, the
values reset to their initially generated values.
I thought we had a mechanism in place to store the state of a
GBean after a change at runtime -- which I assume would include storing
new values for persistent attributes as well as storing the data for new
GBeans added to a Configuration at runtime (for example, if you add a new
network connector to the web container).
I'm not sure whether this was never implemented, was implemented
but is not working, is working but something needs to be called manually
to execute the save, or is totally working and I'm misinterpreting what
I'm seeing in the console.
Any thoughts?
Thanks,
Aaron
Re: GBeans: Saving Changes
Posted by Jeremy Boynes <jb...@apache.org>.
Aaron Mulder wrote:
> Use case: Server ships with HTTPS or AJP disabled. You want to enable it.
> You go to the console, fill in a form, click a button, it is now running.
Implementation: you set the magic "enabled" attribute causing the
disabled bean to be started. New value of the property is saved in the
database[1]. This is already possible.
No modification to the o/a/g/Server configuration is required.
Use case: You want to add a second HTTP connector. On the console you
fill in a form describing the usage pattern of the new interface
Implementation: using knowledge of the container in use and data from
the form the console selects a suitable connector configuration from its
catalog and adds it into the list of running configurations.
No modification to the o/a/g/Server configuration is required.
This is already possible with the degree of sophistication varying based
on how the console locates the template configuration; a rudimentary
implementation could just be code in the console (which IIRC is how JMS
queues get added)
>
> Use case: server ships with HTTPS pointing to a self-signed cert. You
> want to point it to a real cert, which requires the server to use a
> password different than "secret". You go to the console, fill out a form,
> and the GBean property is changed to use the correct password.
>
Implementation: property value is saved in the database
No modification to the o/a/g/Server configuration is required.
> As for your implementation thoughts, I thought this is essentially what
> was implemented -- that saved state was saved to a different place than
> original state. I do not think we need the scope creep of creating
> another database just for this.
>
[1] Database in this case is the dump of persistent attribute values
that is currently held inside the config store. This implementation has
problems (like no way to merge in modified values when a new version of
a configuration is installed) but those are a separate discussion.
--
Jeremy
Re: GBeans: Saving Changes
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
All of those are broken today if you change the properties of the
GBeans using the setAttribute calls, right?
Aaron
On Tue, 26 Jul 2005, Jeremy Boynes wrote:
> The ability to build a configuration on one machine and have it run
> reliably on another.
>
> The ability for the packaging plugin to use artifacts from the Maven
> repo (using Maven's dependency system) rather than having to contact an
> online server.
>
> The ability to reliably run a worker server without a runtime deployment
> system.
Re: GBeans: Saving Changes
Posted by Jeremy Boynes <jb...@apache.org>.
Aaron Mulder wrote:
> Okay, I think we're getting to the root of this. You believe I am
> proposing breaking a current feature. I believe I am proposing only
> adding new features without breaking anything.
>
> If we add the ability to add/remove GBeans to a configuration at
> runtime, then based on the current HEAD, which feature will that break?
>
The ability to build a configuration on one machine and have it run
reliably on another.
The ability for the packaging plugin to use artifacts from the Maven
repo (using Maven's dependency system) rather than having to contact an
online server.
The ability to reliably run a worker server without a runtime deployment
system.
--
Jeremy
Re: What's a bundle?, was: GBeans: Saving Changes
Posted by Joe Bohn <jo...@earthlink.net>.
Thanks Jeremy. That helps a lot. I think it also helps me understand
how potentially different types of configuration data might be organized
and managed (which I'd also like to hear some thoughts on too).
IIUC then, any configuration that changes a GBean's persistent state in
the server or other configuration data that is not part of the GBean
dependency definitions is fine. However, any changes that would result
in the addition/removal of a GBean within the server bundle or
modification of a GBean's dependencies would not be permitted in an
immutable server. That scopes the type of configuration changes then
that would cause potential problems from an admin console to a much
smaller set. Can we get more specific on those types of changes?
<crazy thinking>
A follow up question on the bundles and GBeans. Has there been thought
given to defining a type of GBean and/or bundle that can act as an
interface? Something such that o/a/g/server could have a dependency on
a Servlet Container GBean/bundle but not necessarily on a particular
implementation. Multiple implementation of the interface could be
included in the image and the appropriate one would could be loaded
based upon configuration choices.
Another possibility (although this clobbers the notion of what a GBean
is and so I expect is just crazy :-) ) could be to define less granular
GBeans for these types of dependencies and the behavior of the GBean
would vary based upon configuration choices (ie. a Servlet Container
GBean that contains the necessary logic/classes for several containers
but only activates one based upon some more "dynamic" configuration data).
These would handle the case of server dependencies that must be
fulfilled by a single implementation but don't address the case where
multiple instances of the same type are required simultaneously by
applications (such as with connectors). However, are these really part
of the o/a/g/server or are they additive to the solution (just like
applications even if not bundled directly with the applications as
already proposed earlier in this thread)?
</crazy thinking>
Jeremy Boynes wrote:
> Joe Bohn wrote:
>
>>
>> One final question I'll toss out (and possibly show my ignorance ...
>> but at least I'll learn the answer :-) ) ... Aren't the applications
>> that are deployed themselves represented by Gbeans in the bundle and
>> therefore the bundle is already mutable in that sense? I read an
>> article in JAX that indicated this was the case (
>> http://jaxmag.com/itr/online_artikel/psecom,id,690,nodeid,147.html
>> ). Is that correct or was the author mistaken?
>>
>
> I just read the article and Srinath focuses more on GBeans themselves
> than on the bundle mechanism.
>
> There's a concept in Geronimo of a configuration bundle represented by
> an org.apache.geronimo.kernel.Configuration. What this represents is a
> collection of closely-coupled co-operating components that work
> together to provide a service.
>
> The server runtime is built up by assembling multiple bundles together
> to provide a coherent set of services that support a given programming
> model such as J2EE.
>
> In detail, a bundle comprises:
> * a set of dependencies which define the codebase for the bundle
> These dependencies, including a parent, define the set of classes
> available to the bundle and are used to define a ClassLoader for it.
> There are limitations to what is currently implemented and some well
> known improvements that should be made.
>
> * the set of components that are pre-wired to provide a specific service
> This is basically a list of GBeans based on their names and references
> between them
>
> * the default state for all those service providers
> This is basically the initial attribute values for those beans
>
> The bundle concept comes from recognizing that some services (like the
> HTTPS connector I described elsewhere) may be built up from multiple
> components. Users of the service don't want to know all the wiring
> details, they just want to deal with the service as a whole.
>
> What any particular runtime is doing is determined by which bundles
> are running. So we run a J2EE server by having it run a set of bundles
> that provide a J2EE environment - System, Server, SystemDatabase, ...
> One problem that we have is that the Server bundle is monolithic
> providing too many services; for example, it includes the web
> container and now we have two different implementations of that
> service (Jetty and Tomcat) they should be broken out into separate
> bundles.
>
> The runtime does not know anything about applications - all it deals
> with is how to run bundles (including setting up the environment a
> bundle needs to run (currently just its codebase dependencies)).
>
> What the deployer does is convert application level artifacts such as
> an EAR file into a bundle that the runtime can handle. So using hints
> from the deployment plan, it takes that EAR file, constructs GBeans
> for the individual components that it contains (like Servlets or
> EJBs), wires them together and packages them all up as a bundle.
> When/where you want to run that application, we load the bundle into
> the appropriate server instance and start it up.
>
> Each application running in the server is a separate bundle so we
> never mutate them.
>
> --
> Jeremy
>
>
--
Joe Bohn
joe.bohn@earthlink.net
"He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
What's a bundle?, was: GBeans: Saving Changes
Posted by Jeremy Boynes <jb...@apache.org>.
Joe Bohn wrote:
>
> One final question I'll toss out (and possibly show my ignorance ... but
> at least I'll learn the answer :-) ) ... Aren't the applications that
> are deployed themselves represented by Gbeans in the bundle and
> therefore the bundle is already mutable in that sense? I read an
> article in JAX that indicated this was the case (
> http://jaxmag.com/itr/online_artikel/psecom,id,690,nodeid,147.html ).
> Is that correct or was the author mistaken?
>
I just read the article and Srinath focuses more on GBeans themselves
than on the bundle mechanism.
There's a concept in Geronimo of a configuration bundle represented by
an org.apache.geronimo.kernel.Configuration. What this represents is a
collection of closely-coupled co-operating components that work together
to provide a service.
The server runtime is built up by assembling multiple bundles together
to provide a coherent set of services that support a given programming
model such as J2EE.
In detail, a bundle comprises:
* a set of dependencies which define the codebase for the bundle
These dependencies, including a parent, define the set of classes
available to the bundle and are used to define a ClassLoader for it.
There are limitations to what is currently implemented and some well
known improvements that should be made.
* the set of components that are pre-wired to provide a specific service
This is basically a list of GBeans based on their names and references
between them
* the default state for all those service providers
This is basically the initial attribute values for those beans
The bundle concept comes from recognizing that some services (like the
HTTPS connector I described elsewhere) may be built up from multiple
components. Users of the service don't want to know all the wiring
details, they just want to deal with the service as a whole.
What any particular runtime is doing is determined by which bundles are
running. So we run a J2EE server by having it run a set of bundles that
provide a J2EE environment - System, Server, SystemDatabase, ... One
problem that we have is that the Server bundle is monolithic providing
too many services; for example, it includes the web container and now we
have two different implementations of that service (Jetty and Tomcat)
they should be broken out into separate bundles.
The runtime does not know anything about applications - all it deals
with is how to run bundles (including setting up the environment a
bundle needs to run (currently just its codebase dependencies)).
What the deployer does is convert application level artifacts such as an
EAR file into a bundle that the runtime can handle. So using hints from
the deployment plan, it takes that EAR file, constructs GBeans for the
individual components that it contains (like Servlets or EJBs), wires
them together and packages them all up as a bundle. When/where you want
to run that application, we load the bundle into the appropriate server
instance and start it up.
Each application running in the server is a separate bundle so we never
mutate them.
--
Jeremy
Re: GBeans: Saving Changes
Posted by Joe Bohn <jo...@earthlink.net>.
I'm listening to this discussion and trying to make sense of it so that
I can understand how it will affect our users. Keep in mind that I'm
still grasping at the fundamentals of Geronimo and G-beans so this may
be off in the weeds (and for which I will apologize for right now).
As I think David Jencks mentioned earlier, are think there are different
types of configuration data? Can we list some of the specific types of
configuration items that we are talking about and group them? Perhaps
that can simplify the problem.
Here's my attempt:
First, there is "configuration" which affects the structure of the
solution itself (let's call it "solution configuration") ... such as
changing the access protocol, changing the J2EE container, changing the
security service, the persistent store, etc.... These are all changes
that have substantial impact on the nature and behavior of the server.
These are things that I would expect of somebody that is building a
complete solution to be concerned with and I don't think it would be a
problem if the changes were "maven-like" and required creating a new
bundle (ie. not hosted in the admin console for runtime changes).
Second, there is "configuration" which affects the behavior of the
solution but not the nature of it (let's call this "server
configuration"). These are more minor changes such as changing ports,
hostnames, thread pool sizes, etc... This is standard end user
configuration and items that I would expect an end user that is running
a solution to have to "tweak" on a regular basis. These are types of
configuration changes where I think it would be useful to be able to
export and then later import the configuration for another server and
that should be persisted apart from the Gbeans. This configuration may
even include the set of deployed applications for the server.
If we consider these items as being fundamentally different types of
configuration with different users then I think it might simplify the
problem. The "server configuration" changes should be available via the
admin console and should not impact any G-Bean configuration as I
understand it. The "solution configuration" would potentially affect
the creation of and dependencies between Gbeans and would not
necessarily require a WYSIWYG mechanism for change such as an admin
console. Of course there will always be items in the "gray" area that
are somewhere between these or may need to be changed by both types of
users. Items in the "gray" area could be addressed on an individual
basis such that it would not necessarily require mutable bundles (such
as by defining both HTTP and HTTPS connectors and enabling or disabling
as appropriate for the configuration).
One final question I'll toss out (and possibly show my ignorance ... but
at least I'll learn the answer :-) ) ... Aren't the applications that
are deployed themselves represented by Gbeans in the bundle and
therefore the bundle is already mutable in that sense? I read an
article in JAX that indicated this was the case (
http://jaxmag.com/itr/online_artikel/psecom,id,690,nodeid,147.html ).
Is that correct or was the author mistaken?
Aaron Mulder wrote:
> We're making progress! :)
>
>On Tue, 26 Jul 2005, Jeremy Boynes wrote:
>
>
>>First caveat - o/a/g/Server is too monolithic which is contributing
>>factor to these discussions. The reasons why this is a problem and how
>>to start to fix it have been discussed elsewhere.
>>
>>
>
> True, though there are certain advantages too (like the ability to
>start and stop all that stuff with one command). Anyway, that's another
>topic.
>
>
>
>>Second caveat, change through the web console is one use case. It
>>applies to small installations (desktop, single server) but is less
>>applicable to larger installations, say with > 10 servers. It also does
>>not apply to "headless" servers which may not be running a web container
>>at all.
>>
>>
>
> Agreed.
>
>
>
>>I have two I've given some thought to although they're not fully thought
>>out - but hey, we're brainstorming right?
>>
>>
>
> Yes.
>
> Of the two, I like option 5 more -- and more than all the
>UUID-based options. I'm not sure the mutability needs to be reflected in
>the configuration name, though -- couldn't we have non-name properties for
>the version and mutability? That way the start/stop command would be the
>same and so on. You would refer to a prerequisite by providing the name
>and version range separately, and perhaps even indicating explicitly
>whether you're willing to depend on a mutable version. If you provide
>nothing but the name, that implies "any version will do".
>
> I'd propose we add a tool that can export one or more
>configurations named on the command line (or all current configs) and
>optionally:
>
> - mark them immutable
> - assign them a specific version or UUID
> - update any references between exported modules to use the new version
> number or UUID
> - include an explicit list of all their repository references if that's
> at all possible (as even locking the configuration contents does not
> prevent them from failing due to missing repository contents).
> - sign the exported file(s)
>
> Then we likewise need an import tool that can do whatever
>name-based validation we want (perhaps prompt or automatically disable any
>other configs with the same name and different version), make sure the
>repository contains all the referenced libs, and load the configurations
>into the config store.
>
> Then the installer could offer a bit more flexibility, and let you
>literally install with nothing but o/a/g/System (for a "slave" node), so
>that you could then use the configuration import tool to get all the
>(immutable or otherwise) content into that server.
>
> We also need the kernel to be aware of Configurations to the level
>that it can ensure a configuration is marked mutable when a change is made
>to any GBean in the configuration.
>
> Finally, I don't have a satisfactory answer to "what if you just
>redeploy from a plan with different contents but the same name". It
>doesn't seem all that different than making changes through the console,
>except the kernel has no way to intercept that if the configuration was
>marked immutable.
>
>Aaron
>
>
>
>>Option 5: We have two different bundle types, mutable and immutable.
>>Mutable ones have a special ID, e.g. containing the word SNAPSHOT so
>>they can be clearly identified; immutable ones have a specific version
>>number e.g. o/a/g/Server/1.0-M5. Any structural modification of the
>>bundle, e.g. adding a GBean, changing a reference pattern etc. makes the
>>bundle mutable. We enhance the configuration manager so that it can
>>handle bundle version ranges so that bundle-to-bundle dependencies are
>>squishier than they are now.
>>
>>So, when the deployer builds the application it could say "this
>>application expects a Jetty bundle with version between 1.0.1 and 1.0.5
>>or a SNAPSHOT." Modifications through the web console that require
>>strucutural change convert the config say o/a/g/Jetty-1.0.2 to
>>o/a/g/Jetty-1.0.2-SNAPSHOT; bundles built with a tolerance for
>>mutability will still run but ones that assume a release version won't.
>>
>>For desktop and small installations we do a default assembly using
>>SNAPSHOT bundles; larger installations will probably build their own
>>assemblies using released versions only.
>>
>>---
>>
>>Option 6: We add a "local" bundle to the runtime that is used to hold
>>"stuff associated with this instance." This would be mutable and contain
>>GBeans associated with this instance e.g. edge components like network
>>listeners.
>>
>>With this model, a second HTTP connector would be added to the "local"
>>bundle rather than o/a/g/Server or o/a/g/Jetty. Deployment does not
>>break for portable applications which only use components from named
>>bundles.
>>
>>For this to work we will need to fix the classloader to provide the
>>import/export mechanism add will need to be able to add imports to the
>>"local" configuration at runtime. We need to be careful about adding
>>multiple GBeans that require classes from conflicting imports.
>>
>>---
>>
>>There may be the possibility of a combination of multiple options e.g.
>>mixing "local" bundles with SNAPSHOTs or UUIDs.
>>
>>--
>>Jeremy
>>
>>
>>
>
>
>
>
--
Joe Bohn
joe.bohn@earthlink.net
"He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
Bundle metadata, was: GBeans: Saving Changes
Posted by Jeremy Boynes <jb...@apache.org>.
Aaron Mulder wrote:
>
> Of the two, I like option 5 more -- and more than all the
> UUID-based options. I'm not sure the mutability needs to be reflected in
> the configuration name, though -- couldn't we have non-name properties for
> the version and mutability? That way the start/stop command would be the
> same and so on. You would refer to a prerequisite by providing the name
> and version range separately, and perhaps even indicating explicitly
> whether you're willing to depend on a mutable version. If you provide
> nothing but the name, that implies "any version will do".
>
<snip>Because I think this is a key issue and drives the rest</snip>
First a chunk of background to establish context, skip to "+++" for the
proposal.
One of the problems we have is that the configuration management system
is very naive - I kept the first version real simple to see how needs
would drive it and, of course, its limitations are now coming back to
bite us.
It works on the assumption that all the information about a bundle can
be captured in its unique id. So no matter how many services a bundle
offers, all a user of those services needs to know is the bundle's id
and if it references that those services will be there.
This allows us to have a very basic system where dependencies get
resolved based on ids alone. It got us this far but I think we're
starting to hit the limitations.
One thing we talked about from the start was a "capability model" where
bundles advertised distinct services (versioned) and dependencies
between bundles were resolved using those rather than just the basic id.
So, for example, a web container could advertise "jetty", "jetty 5",
"jetty 5.1.4", "servlet", "servlet 2.4" etc. An application that needed
a web container could require "servlet 2.4" which would mean it could
run in any instance no matter what implementation of "servlet 2.4" was
present (e.g. either Jetty or Tomcat) or it could require "jetty 5.1.4"
because perhaps it had specific classes that it was using. For example,
a generic webapp may just need the "servlet" bits but one with a custom
Valve would require a Tomcat based version.
The intention was to build up an ever richer set of services that could
be provided and consumed. In the end you would end up with very rich
bundle descriptions such as "I am a bundle that provides Acme Inc. Order
Entry System V7.5.2 tuned for 100 concurrent users at 500ms reponse time
and 40 operations per second on an Acme-4000 Linux system with a Harmony
JVM, 4 4.2Ghz CPUs and 2GB RAM. I provide these web services (...) and
EJBs (...). I need access to a Acme Inc. Order Entry Schema V7 via a
JDBC 3.0 driver on a database tuned for 80 transactions per second and
to the following JMS queues (...) capable of handling 20 messages per
second." This captures not only the physical and logical requirements
needed to run the application but also the environment characteristics
that drive response time and throughput.
With this in place, there starts to be sufficient information for the
configuration manager to start to make intelligent decisions about
where/when to run application bundles in order to meet business level
service agreement targets.
+++
The key to this whole thing is having sufficient metadata in place about
the bundles, which ties back to your point at the start. I think it has
become clear that we have progressed to the point where a simple unique
id is insufficient and we need to start adding metadata. The first bits
relate to temporal stability: adding in a version identifier and adding
in an indicator that a bundle is temporally unstable (i.e. its a SNAPSHOT).
We should add to that metadata about the services that a bundle provides
and consumes. I think that at a minimum that comprises a service id,
version and stablilty flag the same as for bundles themselves.
If we do that first for codebase services (i.e. the classes that a
bundle uses and provides) then we not only get a start on the metadata
description side, we also fix the classloader issues that lead to
monolithic bundles like o/a/g/Server.
--
Jeremy
Re: GBeans: Saving Changes
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
We're making progress! :)
On Tue, 26 Jul 2005, Jeremy Boynes wrote:
> First caveat - o/a/g/Server is too monolithic which is contributing
> factor to these discussions. The reasons why this is a problem and how
> to start to fix it have been discussed elsewhere.
True, though there are certain advantages too (like the ability to
start and stop all that stuff with one command). Anyway, that's another
topic.
> Second caveat, change through the web console is one use case. It
> applies to small installations (desktop, single server) but is less
> applicable to larger installations, say with > 10 servers. It also does
> not apply to "headless" servers which may not be running a web container
> at all.
Agreed.
> I have two I've given some thought to although they're not fully thought
> out - but hey, we're brainstorming right?
Yes.
Of the two, I like option 5 more -- and more than all the
UUID-based options. I'm not sure the mutability needs to be reflected in
the configuration name, though -- couldn't we have non-name properties for
the version and mutability? That way the start/stop command would be the
same and so on. You would refer to a prerequisite by providing the name
and version range separately, and perhaps even indicating explicitly
whether you're willing to depend on a mutable version. If you provide
nothing but the name, that implies "any version will do".
I'd propose we add a tool that can export one or more
configurations named on the command line (or all current configs) and
optionally:
- mark them immutable
- assign them a specific version or UUID
- update any references between exported modules to use the new version
number or UUID
- include an explicit list of all their repository references if that's
at all possible (as even locking the configuration contents does not
prevent them from failing due to missing repository contents).
- sign the exported file(s)
Then we likewise need an import tool that can do whatever
name-based validation we want (perhaps prompt or automatically disable any
other configs with the same name and different version), make sure the
repository contains all the referenced libs, and load the configurations
into the config store.
Then the installer could offer a bit more flexibility, and let you
literally install with nothing but o/a/g/System (for a "slave" node), so
that you could then use the configuration import tool to get all the
(immutable or otherwise) content into that server.
We also need the kernel to be aware of Configurations to the level
that it can ensure a configuration is marked mutable when a change is made
to any GBean in the configuration.
Finally, I don't have a satisfactory answer to "what if you just
redeploy from a plan with different contents but the same name". It
doesn't seem all that different than making changes through the console,
except the kernel has no way to intercept that if the configuration was
marked immutable.
Aaron
> Option 5: We have two different bundle types, mutable and immutable.
> Mutable ones have a special ID, e.g. containing the word SNAPSHOT so
> they can be clearly identified; immutable ones have a specific version
> number e.g. o/a/g/Server/1.0-M5. Any structural modification of the
> bundle, e.g. adding a GBean, changing a reference pattern etc. makes the
> bundle mutable. We enhance the configuration manager so that it can
> handle bundle version ranges so that bundle-to-bundle dependencies are
> squishier than they are now.
>
> So, when the deployer builds the application it could say "this
> application expects a Jetty bundle with version between 1.0.1 and 1.0.5
> or a SNAPSHOT." Modifications through the web console that require
> strucutural change convert the config say o/a/g/Jetty-1.0.2 to
> o/a/g/Jetty-1.0.2-SNAPSHOT; bundles built with a tolerance for
> mutability will still run but ones that assume a release version won't.
>
> For desktop and small installations we do a default assembly using
> SNAPSHOT bundles; larger installations will probably build their own
> assemblies using released versions only.
>
> ---
>
> Option 6: We add a "local" bundle to the runtime that is used to hold
> "stuff associated with this instance." This would be mutable and contain
> GBeans associated with this instance e.g. edge components like network
> listeners.
>
> With this model, a second HTTP connector would be added to the "local"
> bundle rather than o/a/g/Server or o/a/g/Jetty. Deployment does not
> break for portable applications which only use components from named
> bundles.
>
> For this to work we will need to fix the classloader to provide the
> import/export mechanism add will need to be able to add imports to the
> "local" configuration at runtime. We need to be careful about adding
> multiple GBeans that require classes from conflicting imports.
>
> ---
>
> There may be the possibility of a combination of multiple options e.g.
> mixing "local" bundles with SNAPSHOTs or UUIDs.
>
> --
> Jeremy
>
Re: GBeans: Saving Changes
Posted by Jeremy Boynes <jb...@apache.org>.
Aaron Mulder wrote:
> Let me try to propose some alternatives for us to consider. Assume you
> want to make a change to the server configuration, and for whatever
> reason, NOT bundle that with your application. This change involves
> adding or removing a GBean, which is naturally related to the content of
> the o/a/g/Server configuration. You want to make this change at runtime
> via the web console.
>
First caveat - o/a/g/Server is too monolithic which is contributing
factor to these discussions. The reasons why this is a problem and how
to start to fix it have been discussed elsewhere.
This impacts this discussion because of the clause "which is naturally
related to the content of the o/a/g/Server configuration." Let's assume
o/a/g/Server is made more modular; the problem does not change, it just
gets applies to the smaller bundles.
Second caveat, change through the web console is one use case. It
applies to small installations (desktop, single server) but is less
applicable to larger installations, say with > 10 servers. It also does
not apply to "headless" servers which may not be running a web container
at all.
> Do we all agree that this is a use case we wish to support?
I do, but as you can tell from the caveats there are other use cases I
also wish to see supported.
<snip/>
skipping straight to suggestions of other alternatives :-)
>
> If you have any other alternatives to propose, please do so.
>
I have two I've given some thought to although they're not fully thought
out - but hey, we're brainstorming right?
Option 5: We have two different bundle types, mutable and immutable.
Mutable ones have a special ID, e.g. containing the word SNAPSHOT so
they can be clearly identified; immutable ones have a specific version
number e.g. o/a/g/Server/1.0-M5. Any structural modification of the
bundle, e.g. adding a GBean, changing a reference pattern etc. makes the
bundle mutable. We enhance the configuration manager so that it can
handle bundle version ranges so that bundle-to-bundle dependencies are
squishier than they are now.
So, when the deployer builds the application it could say "this
application expects a Jetty bundle with version between 1.0.1 and 1.0.5
or a SNAPSHOT." Modifications through the web console that require
strucutural change convert the config say o/a/g/Jetty-1.0.2 to
o/a/g/Jetty-1.0.2-SNAPSHOT; bundles built with a tolerance for
mutability will still run but ones that assume a release version won't.
For desktop and small installations we do a default assembly using
SNAPSHOT bundles; larger installations will probably build their own
assemblies using released versions only.
---
Option 6: We add a "local" bundle to the runtime that is used to hold
"stuff associated with this instance." This would be mutable and contain
GBeans associated with this instance e.g. edge components like network
listeners.
With this model, a second HTTP connector would be added to the "local"
bundle rather than o/a/g/Server or o/a/g/Jetty. Deployment does not
break for portable applications which only use components from named
bundles.
For this to work we will need to fix the classloader to provide the
import/export mechanism add will need to be able to add imports to the
"local" configuration at runtime. We need to be careful about adding
multiple GBeans that require classes from conflicting imports.
---
There may be the possibility of a combination of multiple options e.g.
mixing "local" bundles with SNAPSHOTs or UUIDs.
--
Jeremy
Re: GBeans: Saving Changes
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Let me try to propose some alternatives for us to consider. Assume you
want to make a change to the server configuration, and for whatever
reason, NOT bundle that with your application. This change involves
adding or removing a GBean, which is naturally related to the content of
the o/a/g/Server configuration. You want to make this change at runtime
via the web console.
Do we all agree that this is a use case we wish to support? If not, I
think we should gather some input on that instead. But assuming we're in
agreement there:
Option 1: alter the o/a/g/Server plan in place. Apps that declare that
configuration as a parent will work unchanged, unless the nature of the
change breaks them (you swapped Jetty for Tomcat and the apps assume that
a particular Tomcat Valve is deployed but it's not). If an app is
deployed on this server, it might not work if sent to a different server
(depending on how that server defines "o/a/g/Server").
Option 2: save a new configuration as o/a/g/Server-UUID, and disable the
old o/a/g/Server configuration. All apps which declared Server as a
parent will refuse to run until their deployment plan is updated. All
apps must incude the correct UUID to function. The UUID must be globally
unique, so a different server didn't have a different change applied and
arrive at the same UUID.
Option 3: disable the relevant GBeans in o/a/g/Server, and create a new
configuration o/a/g/Genered-By-Console-UUID with any previous
o/a/g/Generated-By-Console-[PreviousUUID] as the parent (or the original
o/a/g/Server if this is the first change). All apps which declared Server
as a parent may or may not work and may or may not need to be changed to
refer to a different parent, depending on the nature of the change. If
they do need to reflect the change, their dependency must include the
correct UUID to function.
Option 4: Require that "Server" include some number of disabled GBean
"blanks" for every GBean you might want to add. If you want to add
something, you instead activate a blank, If you want to remove something,
you disable it. If an app is deployed on this server, it might not work
if sent to a different server (depending on which GBeans are or are not
enabled in the "Server" configuration on each, and whether the app relies
on them).
If you have any other alternatives to propose, please do so.
Thanks,
Aaron
Re: GBeans: Saving Changes
Posted by David Jencks <dj...@gluecode.com>.
well...
If the runtime deployer works off of the original configurations,
ignoring any local modifications, it won't break anything, but it also
will be pretty much useless (I think).
If the runtime deployer works off of the locally modified
configuration, then the runtime deployer should not be used to build
configurations you intend to distribute to any other server. If you
do, it breaks the immutability guarantees.
BTW, I don't see how the runtime deployer can avoid using the locally
modified configuration state -- you would have to find a way to load 2
copies of the same configuration at once. If the only changes allowed
are attribute values, this is unlikely to have a really serious effect
on the deployed configuration. Allowing more gbeans in is definitely
going to welcome in all sorts of compatibility problems
I continue to think adding gbeans at runtime will be a big mistake and
that we don't see all the bad consequences yet.
david jencks
On Jul 26, 2005, at 4:48 PM, Aaron Mulder wrote:
> Okay, I think we're getting to the root of this. You believe I am
> proposing breaking a current feature. I believe I am proposing only
> adding new features without breaking anything.
>
> If we add the ability to add/remove GBeans to a configuration at
> runtime, then based on the current HEAD, which feature will that break?
>
> Thanks,
> Aaron
>
> On Tue, 26 Jul 2005, Jeremy Boynes wrote:
>> Aaron Mulder wrote:
>>> FYI, I don't think this is a technical issue, I think this is a
>>> scope issue. You're talking about how to support "build the bundle
>>> on a
>>> master node in a cluster and then automatically push it to worker
>>> nodes"
>>> and how to support features that no other app server has.
>>
>> Yep, that was one of the design goals when we started on this, er, two
>> years ago. And there are other servers that do this kind of thing,
>> WebSphere-ND is one.
>>
>>> I'm talking
>>> about how to provide a usable management environment for ONE server,
>>> which
>>> is something we most definitely need to be competitive. We have to
>>> get
>>> past reasonable 1-server support (plus of course add clustering
>>> support)
>>> before we need the features you're describing.
>>
>> None of these interfere with 1-server support. There's just no need to
>> break N-server support that is already there whilst doing so,
>> especially
>> when people have already stated to talk about adding clustering
>> support.
>>
>>> I feel that we should
>>> proceed with a short-term option and plan to refactor when we are at
>>> a
>>> place where supporting the environment you're describing becomes
>>> feasible.
>>> It doesn't make sense to me to not proceed with any change until we
>>> can
>>> solve every problem we might ever have.
>>>
>>
>> No one is advocating not making any changes so please do not over
>> dramatize the discussion.
>>
>> What doesn't make sense is breaking features we have now for a
>> solution
>> we have already identified has problems, planning on a refactoring say
>> within 6 months to a mode that can't use the interim solution as there
>> is no guarantee of consistency.
>>
>> Why not start the discussion on how to impove what we have e.g. by
>> providing bundle level properties, by separating out management
>> properties into an human-readable database rather than burying them in
>> the config store, by separating manageable attributes from
>> unmanageable
>> ones used for wiring purposes, by adding bundle metadata?
>>
>>> That said, back to the issue:
>>>
>>> On Tue, 26 Jul 2005, Jeremy Boynes wrote:
>>>
>>>> The problem comes with which version of the state is used by things
>>>> like
>>>> the (runtime) deployer to build new configurations.
>>>>
>>>> If it uses the "original" then the new configuration may not run
>>>> with
>>>> the "current" one; if it uses the "current" then it may not run on a
>>>> server using the "original" one.
>>>
>>>
>>> This is true today; if we don't implement add/remove, we still
>>> have the problem. For example, you could deploy an EJB that depends
>>> on a
>>> data source, then go change the password used by the data source to
>>> be
>>> invalid so it doesn't start or function, thereby breaking your EJB.
>>> This
>>> is true of every app server that I've ever used. I don't consider
>>> it to
>>> be a critical flaw of the product. But of course it would be nice
>>> to have
>>> a way around it down the road.
>>>
>>
>> That is a different problem - we didn't "break" your EJB, it failed
>> because it could not connect to the database. The same problem would
>> occur if the DBA changed the database password or took it down for
>> maintenance. This is just a regular operational problem.
>>
>>>
>>>> This may never become apparent if the configurations are never moved
>>>> between servers. However, being able to do that was half the point -
>>>> e.g. build the bundle on a master node in a cluster and then
>>>> automatically push it to worker nodes.
>>>>
>>>> It is also a requirement for offline or in-Maven packaging where the
>>>> deployer will be using the "original" version and not the "current"
>>>> modified one.
>>>
>>>
>>> Why won't the deployer use the current state in offline mode? If it
>>> touches it at all, it should use the same "current" state that the
>>> server
>>> would use if it started. Otherwise, what's the point? This
>>> shouldn't be
>>> at all hard to fix if that's not the way it works today.
>>>
>>
>> Because it may be on a different machine, for example.
>>
>>>
>>>> This is not a question of whether it is technically possible to make
>>>> bundles mutable - the construction phase gets much easier if they
>>>> are.
>>>> It is whether they are usable by anything else after they have been
>>>> mutated.
>>>>
>>>> I think we all agree that modifying attribute values and persisting
>>>> the
>>>> changes is a good idea. David has proposed saving this separately
>>>> from
>>>> the internal structure of the bundle and that seems like an idea
>>>> worth
>>>> exploring. I'd go further and suggest we separate bundle level
>>>> properties from component level ones (at least for this kind of
>>>> management) but that is something we really haven't discussed at
>>>> all.
>>>
>>>
>>> I think this is a fine candidate for later refactoring.
>>>
>>
>> Perhaps we should look at it now - it may make things simpler.
>> Well, after M4 of course :-)
>>
>> --
>> Jeremy
>>
>
Re: GBeans: Saving Changes
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Okay, I think we're getting to the root of this. You believe I am
proposing breaking a current feature. I believe I am proposing only
adding new features without breaking anything.
If we add the ability to add/remove GBeans to a configuration at
runtime, then based on the current HEAD, which feature will that break?
Thanks,
Aaron
On Tue, 26 Jul 2005, Jeremy Boynes wrote:
> Aaron Mulder wrote:
> > FYI, I don't think this is a technical issue, I think this is a
> > scope issue. You're talking about how to support "build the bundle on a
> > master node in a cluster and then automatically push it to worker nodes"
> > and how to support features that no other app server has.
>
> Yep, that was one of the design goals when we started on this, er, two
> years ago. And there are other servers that do this kind of thing,
> WebSphere-ND is one.
>
> > I'm talking
> > about how to provide a usable management environment for ONE server, which
> > is something we most definitely need to be competitive. We have to get
> > past reasonable 1-server support (plus of course add clustering support)
> > before we need the features you're describing.
>
> None of these interfere with 1-server support. There's just no need to
> break N-server support that is already there whilst doing so, especially
> when people have already stated to talk about adding clustering support.
>
> > I feel that we should
> > proceed with a short-term option and plan to refactor when we are at a
> > place where supporting the environment you're describing becomes feasible.
> > It doesn't make sense to me to not proceed with any change until we can
> > solve every problem we might ever have.
> >
>
> No one is advocating not making any changes so please do not over
> dramatize the discussion.
>
> What doesn't make sense is breaking features we have now for a solution
> we have already identified has problems, planning on a refactoring say
> within 6 months to a mode that can't use the interim solution as there
> is no guarantee of consistency.
>
> Why not start the discussion on how to impove what we have e.g. by
> providing bundle level properties, by separating out management
> properties into an human-readable database rather than burying them in
> the config store, by separating manageable attributes from unmanageable
> ones used for wiring purposes, by adding bundle metadata?
>
> > That said, back to the issue:
> >
> > On Tue, 26 Jul 2005, Jeremy Boynes wrote:
> >
> >>The problem comes with which version of the state is used by things like
> >>the (runtime) deployer to build new configurations.
> >>
> >>If it uses the "original" then the new configuration may not run with
> >>the "current" one; if it uses the "current" then it may not run on a
> >>server using the "original" one.
> >
> >
> > This is true today; if we don't implement add/remove, we still
> > have the problem. For example, you could deploy an EJB that depends on a
> > data source, then go change the password used by the data source to be
> > invalid so it doesn't start or function, thereby breaking your EJB. This
> > is true of every app server that I've ever used. I don't consider it to
> > be a critical flaw of the product. But of course it would be nice to have
> > a way around it down the road.
> >
>
> That is a different problem - we didn't "break" your EJB, it failed
> because it could not connect to the database. The same problem would
> occur if the DBA changed the database password or took it down for
> maintenance. This is just a regular operational problem.
>
> >
> >>This may never become apparent if the configurations are never moved
> >>between servers. However, being able to do that was half the point -
> >>e.g. build the bundle on a master node in a cluster and then
> >>automatically push it to worker nodes.
> >>
> >>It is also a requirement for offline or in-Maven packaging where the
> >>deployer will be using the "original" version and not the "current"
> >>modified one.
> >
> >
> > Why won't the deployer use the current state in offline mode? If it
> > touches it at all, it should use the same "current" state that the server
> > would use if it started. Otherwise, what's the point? This shouldn't be
> > at all hard to fix if that's not the way it works today.
> >
>
> Because it may be on a different machine, for example.
>
> >
> >>This is not a question of whether it is technically possible to make
> >>bundles mutable - the construction phase gets much easier if they are.
> >>It is whether they are usable by anything else after they have been mutated.
> >>
> >>I think we all agree that modifying attribute values and persisting the
> >>changes is a good idea. David has proposed saving this separately from
> >>the internal structure of the bundle and that seems like an idea worth
> >>exploring. I'd go further and suggest we separate bundle level
> >>properties from component level ones (at least for this kind of
> >>management) but that is something we really haven't discussed at all.
> >
> >
> > I think this is a fine candidate for later refactoring.
> >
>
> Perhaps we should look at it now - it may make things simpler.
> Well, after M4 of course :-)
>
> --
> Jeremy
>
Re: GBeans: Saving Changes
Posted by Jeremy Boynes <jb...@apache.org>.
Aaron Mulder wrote:
> FYI, I don't think this is a technical issue, I think this is a
> scope issue. You're talking about how to support "build the bundle on a
> master node in a cluster and then automatically push it to worker nodes"
> and how to support features that no other app server has.
Yep, that was one of the design goals when we started on this, er, two
years ago. And there are other servers that do this kind of thing,
WebSphere-ND is one.
> I'm talking
> about how to provide a usable management environment for ONE server, which
> is something we most definitely need to be competitive. We have to get
> past reasonable 1-server support (plus of course add clustering support)
> before we need the features you're describing.
None of these interfere with 1-server support. There's just no need to
break N-server support that is already there whilst doing so, especially
when people have already stated to talk about adding clustering support.
> I feel that we should
> proceed with a short-term option and plan to refactor when we are at a
> place where supporting the environment you're describing becomes feasible.
> It doesn't make sense to me to not proceed with any change until we can
> solve every problem we might ever have.
>
No one is advocating not making any changes so please do not over
dramatize the discussion.
What doesn't make sense is breaking features we have now for a solution
we have already identified has problems, planning on a refactoring say
within 6 months to a mode that can't use the interim solution as there
is no guarantee of consistency.
Why not start the discussion on how to impove what we have e.g. by
providing bundle level properties, by separating out management
properties into an human-readable database rather than burying them in
the config store, by separating manageable attributes from unmanageable
ones used for wiring purposes, by adding bundle metadata?
> That said, back to the issue:
>
> On Tue, 26 Jul 2005, Jeremy Boynes wrote:
>
>>The problem comes with which version of the state is used by things like
>>the (runtime) deployer to build new configurations.
>>
>>If it uses the "original" then the new configuration may not run with
>>the "current" one; if it uses the "current" then it may not run on a
>>server using the "original" one.
>
>
> This is true today; if we don't implement add/remove, we still
> have the problem. For example, you could deploy an EJB that depends on a
> data source, then go change the password used by the data source to be
> invalid so it doesn't start or function, thereby breaking your EJB. This
> is true of every app server that I've ever used. I don't consider it to
> be a critical flaw of the product. But of course it would be nice to have
> a way around it down the road.
>
That is a different problem - we didn't "break" your EJB, it failed
because it could not connect to the database. The same problem would
occur if the DBA changed the database password or took it down for
maintenance. This is just a regular operational problem.
>
>>This may never become apparent if the configurations are never moved
>>between servers. However, being able to do that was half the point -
>>e.g. build the bundle on a master node in a cluster and then
>>automatically push it to worker nodes.
>>
>>It is also a requirement for offline or in-Maven packaging where the
>>deployer will be using the "original" version and not the "current"
>>modified one.
>
>
> Why won't the deployer use the current state in offline mode? If it
> touches it at all, it should use the same "current" state that the server
> would use if it started. Otherwise, what's the point? This shouldn't be
> at all hard to fix if that's not the way it works today.
>
Because it may be on a different machine, for example.
>
>>This is not a question of whether it is technically possible to make
>>bundles mutable - the construction phase gets much easier if they are.
>>It is whether they are usable by anything else after they have been mutated.
>>
>>I think we all agree that modifying attribute values and persisting the
>>changes is a good idea. David has proposed saving this separately from
>>the internal structure of the bundle and that seems like an idea worth
>>exploring. I'd go further and suggest we separate bundle level
>>properties from component level ones (at least for this kind of
>>management) but that is something we really haven't discussed at all.
>
>
> I think this is a fine candidate for later refactoring.
>
Perhaps we should look at it now - it may make things simpler.
Well, after M4 of course :-)
--
Jeremy
Re: GBeans: Saving Changes
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
FYI, I don't think this is a technical issue, I think this is a
scope issue. You're talking about how to support "build the bundle on a
master node in a cluster and then automatically push it to worker nodes"
and how to support features that no other app server has. I'm talking
about how to provide a usable management environment for ONE server, which
is something we most definitely need to be competitive. We have to get
past reasonable 1-server support (plus of course add clustering support)
before we need the features you're describing. I feel that we should
proceed with a short-term option and plan to refactor when we are at a
place where supporting the environment you're describing becomes feasible.
It doesn't make sense to me to not proceed with any change until we can
solve every problem we might ever have.
That said, back to the issue:
On Tue, 26 Jul 2005, Jeremy Boynes wrote:
> The problem comes with which version of the state is used by things like
> the (runtime) deployer to build new configurations.
>
> If it uses the "original" then the new configuration may not run with
> the "current" one; if it uses the "current" then it may not run on a
> server using the "original" one.
This is true today; if we don't implement add/remove, we still
have the problem. For example, you could deploy an EJB that depends on a
data source, then go change the password used by the data source to be
invalid so it doesn't start or function, thereby breaking your EJB. This
is true of every app server that I've ever used. I don't consider it to
be a critical flaw of the product. But of course it would be nice to have
a way around it down the road.
> This may never become apparent if the configurations are never moved
> between servers. However, being able to do that was half the point -
> e.g. build the bundle on a master node in a cluster and then
> automatically push it to worker nodes.
>
> It is also a requirement for offline or in-Maven packaging where the
> deployer will be using the "original" version and not the "current"
> modified one.
Why won't the deployer use the current state in offline mode? If it
touches it at all, it should use the same "current" state that the server
would use if it started. Otherwise, what's the point? This shouldn't be
at all hard to fix if that's not the way it works today.
> This is not a question of whether it is technically possible to make
> bundles mutable - the construction phase gets much easier if they are.
> It is whether they are usable by anything else after they have been mutated.
>
> I think we all agree that modifying attribute values and persisting the
> changes is a good idea. David has proposed saving this separately from
> the internal structure of the bundle and that seems like an idea worth
> exploring. I'd go further and suggest we separate bundle level
> properties from component level ones (at least for this kind of
> management) but that is something we really haven't discussed at all.
I think this is a fine candidate for later refactoring.
Aaron
> Where we still seem to disagree is on whether structural changes to the
> bundle are a good idea. So far I haven't seen any solution that allows
> this and addresses the technical problems raised above and don't think
> we should go down this route until we have consensus.
Re: GBeans: Saving Changes
Posted by Jeremy Boynes <jb...@apache.org>.
Dain Sundstrom wrote:
> On Jul 26, 2005, at 3:36 PM, Jeremy Boynes wrote:
>
>> If it uses the "original" then the new configuration may not run with
>> the "current" one; if it uses the "current" then it may not run on a
>> server using the "original" one.
>
>
> We have this problem regardless. Any mutation in the environment or
> configuration state can cause a service to not start. For example, if
> a users moves an important directory, or changes a service attribute to
> point to a new directory. The proposed change does not solve that
> problem but it doesn't cause that problem either. When someone comes
> up with a solution to this problem, we can change the console also. It
> is *soft*ware after all.
>
There's a difference between not starting and not present. If something
doesn't start because of environmental issues then you have an
operational problem.
If the server says it offers some services (e.g. a Jetty container) but
has incompatibly mutated (e.g. into a Tomcat container) then you have a
much bigger set of problems.
The immutablity is there to solve that.
>> It is also a requirement for offline or in-Maven packaging where the
>> deployer will be using the "original" version and not the "current"
>> modified one.
>
>
> The command line maven tool will load the current state from the server
> configuration store. If the maven plugin doesn't do that I would
> consider that a bug.
>
No, we've been there already (ApacheCon last year). That is coupling
offline deployment to an instance of the online system rather than
allowing it to use the advertised target environment.
The current command line tool in offline mode loads the state from its
internal config store which just happens to point to the same directory.
Ironically, this would be fine if configurations were immutable.
The plugin loads bundles as artifacts from the local maven repo - which
is fine as they are immutable - automatically giving us the ability to
publish bundles online.
--
Jeremy
Re: GBeans: Saving Changes
Posted by Dain Sundstrom <da...@iq80.com>.
On Jul 26, 2005, at 3:36 PM, Jeremy Boynes wrote:
> If it uses the "original" then the new configuration may not run
> with the "current" one; if it uses the "current" then it may not
> run on a server using the "original" one.
We have this problem regardless. Any mutation in the environment or
configuration state can cause a service to not start. For example,
if a users moves an important directory, or changes a service
attribute to point to a new directory. The proposed change does not
solve that problem but it doesn't cause that problem either. When
someone comes up with a solution to this problem, we can change the
console also. It is *soft*ware after all.
> It is also a requirement for offline or in-Maven packaging where
> the deployer will be using the "original" version and not the
> "current" modified one.
The command line maven tool will load the current state from the
server configuration store. If the maven plugin doesn't do that I
would consider that a bug.
-dain
Re: GBeans: Saving Changes
Posted by Jeremy Boynes <jb...@apache.org>.
Aaron Mulder wrote:
>
> Maybe I've been casting this entire discussion in the wrong way.
> Both changes to GBean properties and adds/removes of GBeans can be
> accomplished by adjusting the "current state" saved *in addition to* the
> original state -- so at the end of the day, we're not really altering "the
> configuration", we're preserving the original configuration and altering
> our "current state for the configuration". Perhaps we're in violent
> agreement. :)
>
Almost but not quite.
The problem comes with which version of the state is used by things like
the (runtime) deployer to build new configurations.
If it uses the "original" then the new configuration may not run with
the "current" one; if it uses the "current" then it may not run on a
server using the "original" one.
This may never become apparent if the configurations are never moved
between servers. However, being able to do that was half the point -
e.g. build the bundle on a master node in a cluster and then
automatically push it to worker nodes.
It is also a requirement for offline or in-Maven packaging where the
deployer will be using the "original" version and not the "current"
modified one.
This is not a question of whether it is technically possible to make
bundles mutable - the construction phase gets much easier if they are.
It is whether they are usable by anything else after they have been mutated.
I think we all agree that modifying attribute values and persisting the
changes is a good idea. David has proposed saving this separately from
the internal structure of the bundle and that seems like an idea worth
exploring. I'd go further and suggest we separate bundle level
properties from component level ones (at least for this kind of
management) but that is something we really haven't discussed at all.
Where we still seem to disagree is on whether structural changes to the
bundle are a good idea. So far I haven't seen any solution that allows
this and addresses the technical problems raised above and don't think
we should go down this route until we have consensus.
--
Jeremy
Re: GBeans: Saving Changes
Posted by Jeremy Boynes <jb...@apache.org>.
Dain Sundstrom wrote:
> How is enabling and subsequently configuring a service is substantially
> different then just adding a new one? Simmilary, why is disabling a
> service substantially different then removing it?
>
I'm not a great fan of the "disabled" component option either - I just
used it because Aaron's example referred to a "disabled" connector.
Having said that, there is a big difference between a "disabled" service
and an absent service - you know that is it there and hence can refer to
it. It becomes a placeholder.
--
Jeremy
Re: GBeans: Saving Changes
Posted by David Jencks <dj...@gluecode.com>.
On Jul 26, 2005, at 3:36 PM, Dain Sundstrom wrote:
> How is enabling and subsequently configuring a service is
> substantially different then just adding a new one? Simmilary, why is
> disabling a service substantially different then removing it?
My idea is that live changes should only affect attribute values, not
reference patterns. So, a disabled gbean will still be (potentially)
hooked up to the correct other gbeans, and will have some sort of
attribute values that might possibly be useful. An entirely new gbean
won't have these features.
david jencks
>
> -dain
>
> On Jul 26, 2005, at 3:23 PM, David Jencks wrote:
>
>>
>> On Jul 26, 2005, at 3:06 PM, Dain Sundstrom wrote:
>>
>>
>>> BTW this is already has a JIRA entry GERONIMO-400. I added this
>>> almost a year ago.
>>>
>>
>> No wonder I couldn't find it. I thought I added it :-)
>>
>> 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). 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.
>>
>> thanks
>> david jencks
>>
>>
>>>
>>> -dain
>>>
>>> On Jul 26, 2005, at 3:05 PM, Aaron Mulder wrote:
>>>
>>>
>>>> David,
>>>> I believe we need to be able to make this kind of change to a
>>>> running server. The commercial products we're (at least in theory)
>>>> competing with all support making this kind of change through their
>>>> management console, though for certain types of changes a server
>>>> restart
>>>> is required. Changing the port you're using to connect to the
>>>> console at
>>>> runtime would be a little weird, but I'm strongly opposed to
>>>> requiring
>>>> someone to locate, modify, and redeploy the o/a/g/Server plan in
>>>> order to
>>>> make any change at all.
>>>>
>>>> Jeremy,
>>>> I agree that changing an attribute value does not need to alter
>>>> "the configuration" based on what is implemented today. IIUC, when
>>>> you
>>>> alter a GBean, a new set of config info is written to a separate
>>>> file, and
>>>> next time the configuration is loaded that file is read and the new
>>>> value
>>>> kicks in instead of the original value. So you have both the
>>>> unaltered
>>>> original configuration and the modified "current state", and it just
>>>> happens that future server starts will use that "current state"
>>>> (though I
>>>> suppose we could provide some sort of command to revert a
>>>> configuration to
>>>> its original state). That would actually be a kind of cool option
>>>> in the
>>>> console -- "revert to factory default settings".
>>>>
>>>> Maybe I've been casting this entire discussion in the wrong way.
>>>> Both changes to GBean properties and adds/removes of GBeans can be
>>>> accomplished by adjusting the "current state" saved *in addition
>>>> to* the
>>>> original state -- so at the end of the day, we're not really
>>>> altering "the
>>>> configuration", we're preserving the original configuration and
>>>> altering
>>>> our "current state for the configuration". Perhaps we're in violent
>>>> agreement. :)
>>>>
>>>> Aaron
>>>>
>>>> On Tue, 26 Jul 2005, David Jencks wrote:
>>>>
>>>>
>>>>> IMO both of these are much better done as part of the offline
>>>>> deployment process well before the configuration gets anywhere
>>>>> near a
>>>>> running server. Both of these are reasonable things to do, but
>>>>> again
>>>>> IMO not on a running server.
>>>>>
>>>>> I'm not really sure how the current configuration saving works.
>>>>>
>>>>> thanks
>>>>> david jencks
>>>>> On Jul 26, 2005, at 2:34 PM, Aaron Mulder wrote:
>>>>>
>>>>>
>>>>>
>>>>>> On Tue, 26 Jul 2005, David Jencks wrote:
>>>>>>
>>>>>>
>>>>>>> there are at least 2 aspects to mutable configurations.
>>>>>>>
>>>>>>> 1. adding/ removing gbeans. I don't think there is a valid use
>>>>>>> case
>>>>>>> for this and don't think we should support it, ever. I don't
>>>>>>> think we
>>>>>>> should allow changing reference patterns either for essentially
>>>>>>> the
>>>>>>> same reasons.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Use case: Server ships with HTTPS or AJP disabled. You want to
>>>>>> enable
>>>>>> it.
>>>>>> You go to the console, fill in a form, click a button, it is now
>>>>>> running.
>>>>>> Under the covers, a connector GBean has been added to the
>>>>>> o/a/g/Server
>>>>>> Configuration.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> 2. changing attribute values on pre-existing gbeans. To me this
>>>>>>> is
>>>>>>> less clear. I'm not thrilled with the idea of changing the
>>>>>>> content of
>>>>>>> a configuration jar: I'd prefer to see local modifications saved
>>>>>>> in a
>>>>>>> local database outside the supplied configurations. I can see
>>>>>>> how you
>>>>>>> would want to play with a running server till you like it, then
>>>>>>> save
>>>>>>> and seal a configuration, but I'm reluctant to allow this
>>>>>>> without more
>>>>>>> thought and a clear upgrade path to whatever we decide we want
>>>>>>> to do
>>>>>>> long-term. Still, this seems more reasonable to me than (1).
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Use case: server ships with HTTPS pointing to a self-signed cert.
>>>>>> You
>>>>>> want to point it to a real cert, which requires the server to use
>>>>>> a
>>>>>> password different than "secret". You go to the console, fill
>>>>>> out a
>>>>>> form,
>>>>>> and the GBean property is changed to use the correct password.
>>>>>>
>>>>>> As for your implementation thoughts, I thought this is
>>>>>> essentially what
>>>>>> was implemented -- that saved state was saved to a different
>>>>>> place than
>>>>>> original state. I do not think we need the scope creep of
>>>>>> creating
>>>>>> another database just for this.
>>>>>>
>>>>>> Aaron
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
Re: GBeans: Saving Changes
Posted by Dain Sundstrom <da...@iq80.com>.
How is enabling and subsequently configuring a service is
substantially different then just adding a new one? Simmilary, why
is disabling a service substantially different then removing it?
-dain
On Jul 26, 2005, at 3:23 PM, David Jencks wrote:
>
> On Jul 26, 2005, at 3:06 PM, Dain Sundstrom wrote:
>
>
>> BTW this is already has a JIRA entry GERONIMO-400. I added this
>> almost a year ago.
>>
>
> No wonder I couldn't find it. I thought I added it :-)
>
> 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). 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.
>
> thanks
> david jencks
>
>
>>
>> -dain
>>
>> On Jul 26, 2005, at 3:05 PM, Aaron Mulder wrote:
>>
>>
>>> David,
>>> I believe we need to be able to make this kind of change to a
>>> running server. The commercial products we're (at least in theory)
>>> competing with all support making this kind of change through their
>>> management console, though for certain types of changes a server
>>> restart
>>> is required. Changing the port you're using to connect to the
>>> console at
>>> runtime would be a little weird, but I'm strongly opposed to
>>> requiring
>>> someone to locate, modify, and redeploy the o/a/g/Server plan in
>>> order to
>>> make any change at all.
>>>
>>> Jeremy,
>>> I agree that changing an attribute value does not need to alter
>>> "the configuration" based on what is implemented today. IIUC,
>>> when you
>>> alter a GBean, a new set of config info is written to a separate
>>> file, and
>>> next time the configuration is loaded that file is read and the
>>> new value
>>> kicks in instead of the original value. So you have both the
>>> unaltered
>>> original configuration and the modified "current state", and it just
>>> happens that future server starts will use that "current
>>> state" (though I
>>> suppose we could provide some sort of command to revert a
>>> configuration to
>>> its original state). That would actually be a kind of cool
>>> option in the
>>> console -- "revert to factory default settings".
>>>
>>> Maybe I've been casting this entire discussion in the wrong way.
>>> Both changes to GBean properties and adds/removes of GBeans can be
>>> accomplished by adjusting the "current state" saved *in addition
>>> to* the
>>> original state -- so at the end of the day, we're not really
>>> altering "the
>>> configuration", we're preserving the original configuration and
>>> altering
>>> our "current state for the configuration". Perhaps we're in violent
>>> agreement. :)
>>>
>>> Aaron
>>>
>>> On Tue, 26 Jul 2005, David Jencks wrote:
>>>
>>>
>>>> IMO both of these are much better done as part of the offline
>>>> deployment process well before the configuration gets anywhere
>>>> near a
>>>> running server. Both of these are reasonable things to do, but
>>>> again
>>>> IMO not on a running server.
>>>>
>>>> I'm not really sure how the current configuration saving works.
>>>>
>>>> thanks
>>>> david jencks
>>>> On Jul 26, 2005, at 2:34 PM, Aaron Mulder wrote:
>>>>
>>>>
>>>>
>>>>> On Tue, 26 Jul 2005, David Jencks wrote:
>>>>>
>>>>>
>>>>>> there are at least 2 aspects to mutable configurations.
>>>>>>
>>>>>> 1. adding/ removing gbeans. I don't think there is a valid
>>>>>> use case
>>>>>> for this and don't think we should support it, ever. I don't
>>>>>> think we
>>>>>> should allow changing reference patterns either for
>>>>>> essentially the
>>>>>> same reasons.
>>>>>>
>>>>>>
>>>>>
>>>>> Use case: Server ships with HTTPS or AJP disabled. You want to
>>>>> enable
>>>>> it.
>>>>> You go to the console, fill in a form, click a button, it is now
>>>>> running.
>>>>> Under the covers, a connector GBean has been added to the o/a/g/
>>>>> Server
>>>>> Configuration.
>>>>>
>>>>>
>>>>>
>>>>>> 2. changing attribute values on pre-existing gbeans. To me
>>>>>> this is
>>>>>> less clear. I'm not thrilled with the idea of changing the
>>>>>> content of
>>>>>> a configuration jar: I'd prefer to see local modifications
>>>>>> saved in a
>>>>>> local database outside the supplied configurations. I can see
>>>>>> how you
>>>>>> would want to play with a running server till you like it,
>>>>>> then save
>>>>>> and seal a configuration, but I'm reluctant to allow this
>>>>>> without more
>>>>>> thought and a clear upgrade path to whatever we decide we want
>>>>>> to do
>>>>>> long-term. Still, this seems more reasonable to me than (1).
>>>>>>
>>>>>>
>>>>>
>>>>> Use case: server ships with HTTPS pointing to a self-signed
>>>>> cert. You
>>>>> want to point it to a real cert, which requires the server to
>>>>> use a
>>>>> password different than "secret". You go to the console, fill
>>>>> out a
>>>>> form,
>>>>> and the GBean property is changed to use the correct password.
>>>>>
>>>>> As for your implementation thoughts, I thought this is
>>>>> essentially what
>>>>> was implemented -- that saved state was saved to a different
>>>>> place than
>>>>> original state. I do not think we need the scope creep of
>>>>> creating
>>>>> another database just for this.
>>>>>
>>>>> Aaron
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>
Re: GBeans: Saving Changes
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Tue, 26 Jul 2005, David Jencks wrote:
> I think this is a prime example of where you should use app-centric
> deployment, i.e. put the security gbeans in the application.
What if your developers are not trusted with the production
database or LDAP accounts? Are you arguing that your application
deployment information should need to be changed between final test and
production? I think it's a pretty important feature to be able to have an
unaltered EAR going from test to prod.
> 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.
Okay, now you're arguing that app-centric deployment does not
always work, which I would obviously agree with.
So what if you want to change the compatibility layer? Wouldn't
it be nice if you could do that in the web console instead of be writing
deployment plans and redeploying them? This is what ease of use is all
about to me. We can totally support changing things on the fly in the web
console. Why not give people that option?
> 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.
Again, I support this 100% as an option. I just don't believe it
is the *only* option. I think each approach has its advantages, and
different situations would benefit from each. I believe we should support
both.
Aaron
> 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.
Re: GBeans: Saving Changes
Posted by David Jencks <dj...@gluecode.com>.
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
>
Re: GBeans: Saving Changes
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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
Re: GBeans: Saving Changes
Posted by David Jencks <dj...@gluecode.com>.
On Jul 26, 2005, at 3:06 PM, Dain Sundstrom wrote:
> BTW this is already has a JIRA entry GERONIMO-400. I added this
> almost a year ago.
No wonder I couldn't find it. I thought I added it :-)
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). 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.
thanks
david jencks
>
> -dain
>
> On Jul 26, 2005, at 3:05 PM, Aaron Mulder wrote:
>
>> David,
>> I believe we need to be able to make this kind of change to a
>> running server. The commercial products we're (at least in theory)
>> competing with all support making this kind of change through their
>> management console, though for certain types of changes a server
>> restart
>> is required. Changing the port you're using to connect to the
>> console at
>> runtime would be a little weird, but I'm strongly opposed to requiring
>> someone to locate, modify, and redeploy the o/a/g/Server plan in
>> order to
>> make any change at all.
>>
>> Jeremy,
>> I agree that changing an attribute value does not need to alter
>> "the configuration" based on what is implemented today. IIUC, when
>> you
>> alter a GBean, a new set of config info is written to a separate
>> file, and
>> next time the configuration is loaded that file is read and the new
>> value
>> kicks in instead of the original value. So you have both the
>> unaltered
>> original configuration and the modified "current state", and it just
>> happens that future server starts will use that "current state"
>> (though I
>> suppose we could provide some sort of command to revert a
>> configuration to
>> its original state). That would actually be a kind of cool option in
>> the
>> console -- "revert to factory default settings".
>>
>> Maybe I've been casting this entire discussion in the wrong way.
>> Both changes to GBean properties and adds/removes of GBeans can be
>> accomplished by adjusting the "current state" saved *in addition to*
>> the
>> original state -- so at the end of the day, we're not really altering
>> "the
>> configuration", we're preserving the original configuration and
>> altering
>> our "current state for the configuration". Perhaps we're in violent
>> agreement. :)
>>
>> Aaron
>>
>> On Tue, 26 Jul 2005, David Jencks wrote:
>>
>>> IMO both of these are much better done as part of the offline
>>> deployment process well before the configuration gets anywhere near a
>>> running server. Both of these are reasonable things to do, but again
>>> IMO not on a running server.
>>>
>>> I'm not really sure how the current configuration saving works.
>>>
>>> thanks
>>> david jencks
>>> On Jul 26, 2005, at 2:34 PM, Aaron Mulder wrote:
>>>
>>>
>>>> On Tue, 26 Jul 2005, David Jencks wrote:
>>>>
>>>>> there are at least 2 aspects to mutable configurations.
>>>>>
>>>>> 1. adding/ removing gbeans. I don't think there is a valid use
>>>>> case
>>>>> for this and don't think we should support it, ever. I don't
>>>>> think we
>>>>> should allow changing reference patterns either for essentially the
>>>>> same reasons.
>>>>>
>>>>
>>>> Use case: Server ships with HTTPS or AJP disabled. You want to
>>>> enable
>>>> it.
>>>> You go to the console, fill in a form, click a button, it is now
>>>> running.
>>>> Under the covers, a connector GBean has been added to the
>>>> o/a/g/Server
>>>> Configuration.
>>>>
>>>>
>>>>> 2. changing attribute values on pre-existing gbeans. To me this is
>>>>> less clear. I'm not thrilled with the idea of changing the
>>>>> content of
>>>>> a configuration jar: I'd prefer to see local modifications saved
>>>>> in a
>>>>> local database outside the supplied configurations. I can see how
>>>>> you
>>>>> would want to play with a running server till you like it, then
>>>>> save
>>>>> and seal a configuration, but I'm reluctant to allow this without
>>>>> more
>>>>> thought and a clear upgrade path to whatever we decide we want to
>>>>> do
>>>>> long-term. Still, this seems more reasonable to me than (1).
>>>>>
>>>>
>>>> Use case: server ships with HTTPS pointing to a self-signed cert.
>>>> You
>>>> want to point it to a real cert, which requires the server to use a
>>>> password different than "secret". You go to the console, fill out a
>>>> form,
>>>> and the GBean property is changed to use the correct password.
>>>>
>>>> As for your implementation thoughts, I thought this is essentially
>>>> what
>>>> was implemented -- that saved state was saved to a different place
>>>> than
>>>> original state. I do not think we need the scope creep of creating
>>>> another database just for this.
>>>>
>>>> Aaron
>>>>
>>>>
>>>
>>>
>>
>
Re: GBeans: Saving Changes
Posted by Dain Sundstrom <da...@iq80.com>.
BTW this is already has a JIRA entry GERONIMO-400. I added this
almost a year ago.
-dain
On Jul 26, 2005, at 3:05 PM, Aaron Mulder wrote:
> David,
> I believe we need to be able to make this kind of change to a
> running server. The commercial products we're (at least in theory)
> competing with all support making this kind of change through their
> management console, though for certain types of changes a server
> restart
> is required. Changing the port you're using to connect to the
> console at
> runtime would be a little weird, but I'm strongly opposed to requiring
> someone to locate, modify, and redeploy the o/a/g/Server plan in
> order to
> make any change at all.
>
> Jeremy,
> I agree that changing an attribute value does not need to alter
> "the configuration" based on what is implemented today. IIUC, when
> you
> alter a GBean, a new set of config info is written to a separate
> file, and
> next time the configuration is loaded that file is read and the new
> value
> kicks in instead of the original value. So you have both the
> unaltered
> original configuration and the modified "current state", and it just
> happens that future server starts will use that "current
> state" (though I
> suppose we could provide some sort of command to revert a
> configuration to
> its original state). That would actually be a kind of cool option
> in the
> console -- "revert to factory default settings".
>
> Maybe I've been casting this entire discussion in the wrong way.
> Both changes to GBean properties and adds/removes of GBeans can be
> accomplished by adjusting the "current state" saved *in addition
> to* the
> original state -- so at the end of the day, we're not really
> altering "the
> configuration", we're preserving the original configuration and
> altering
> our "current state for the configuration". Perhaps we're in violent
> agreement. :)
>
> Aaron
>
> On Tue, 26 Jul 2005, David Jencks wrote:
>
>> IMO both of these are much better done as part of the offline
>> deployment process well before the configuration gets anywhere near a
>> running server. Both of these are reasonable things to do, but again
>> IMO not on a running server.
>>
>> I'm not really sure how the current configuration saving works.
>>
>> thanks
>> david jencks
>> On Jul 26, 2005, at 2:34 PM, Aaron Mulder wrote:
>>
>>
>>> On Tue, 26 Jul 2005, David Jencks wrote:
>>>
>>>> there are at least 2 aspects to mutable configurations.
>>>>
>>>> 1. adding/ removing gbeans. I don't think there is a valid use
>>>> case
>>>> for this and don't think we should support it, ever. I don't
>>>> think we
>>>> should allow changing reference patterns either for essentially the
>>>> same reasons.
>>>>
>>>
>>> Use case: Server ships with HTTPS or AJP disabled. You want to
>>> enable
>>> it.
>>> You go to the console, fill in a form, click a button, it is now
>>> running.
>>> Under the covers, a connector GBean has been added to the o/a/g/
>>> Server
>>> Configuration.
>>>
>>>
>>>> 2. changing attribute values on pre-existing gbeans. To me this is
>>>> less clear. I'm not thrilled with the idea of changing the
>>>> content of
>>>> a configuration jar: I'd prefer to see local modifications saved
>>>> in a
>>>> local database outside the supplied configurations. I can see
>>>> how you
>>>> would want to play with a running server till you like it, then
>>>> save
>>>> and seal a configuration, but I'm reluctant to allow this
>>>> without more
>>>> thought and a clear upgrade path to whatever we decide we want
>>>> to do
>>>> long-term. Still, this seems more reasonable to me than (1).
>>>>
>>>
>>> Use case: server ships with HTTPS pointing to a self-signed
>>> cert. You
>>> want to point it to a real cert, which requires the server to use a
>>> password different than "secret". You go to the console, fill out a
>>> form,
>>> and the GBean property is changed to use the correct password.
>>>
>>> As for your implementation thoughts, I thought this is
>>> essentially what
>>> was implemented -- that saved state was saved to a different
>>> place than
>>> original state. I do not think we need the scope creep of creating
>>> another database just for this.
>>>
>>> Aaron
>>>
>>>
>>
>>
>
Re: GBeans: Saving Changes
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
David,
I believe we need to be able to make this kind of change to a
running server. The commercial products we're (at least in theory)
competing with all support making this kind of change through their
management console, though for certain types of changes a server restart
is required. Changing the port you're using to connect to the console at
runtime would be a little weird, but I'm strongly opposed to requiring
someone to locate, modify, and redeploy the o/a/g/Server plan in order to
make any change at all.
Jeremy,
I agree that changing an attribute value does not need to alter
"the configuration" based on what is implemented today. IIUC, when you
alter a GBean, a new set of config info is written to a separate file, and
next time the configuration is loaded that file is read and the new value
kicks in instead of the original value. So you have both the unaltered
original configuration and the modified "current state", and it just
happens that future server starts will use that "current state" (though I
suppose we could provide some sort of command to revert a configuration to
its original state). That would actually be a kind of cool option in the
console -- "revert to factory default settings".
Maybe I've been casting this entire discussion in the wrong way.
Both changes to GBean properties and adds/removes of GBeans can be
accomplished by adjusting the "current state" saved *in addition to* the
original state -- so at the end of the day, we're not really altering "the
configuration", we're preserving the original configuration and altering
our "current state for the configuration". Perhaps we're in violent
agreement. :)
Aaron
On Tue, 26 Jul 2005, David Jencks wrote:
> IMO both of these are much better done as part of the offline
> deployment process well before the configuration gets anywhere near a
> running server. Both of these are reasonable things to do, but again
> IMO not on a running server.
>
> I'm not really sure how the current configuration saving works.
>
> thanks
> david jencks
> On Jul 26, 2005, at 2:34 PM, Aaron Mulder wrote:
>
> > On Tue, 26 Jul 2005, David Jencks wrote:
> >> there are at least 2 aspects to mutable configurations.
> >>
> >> 1. adding/ removing gbeans. I don't think there is a valid use case
> >> for this and don't think we should support it, ever. I don't think we
> >> should allow changing reference patterns either for essentially the
> >> same reasons.
> >
> > Use case: Server ships with HTTPS or AJP disabled. You want to enable
> > it.
> > You go to the console, fill in a form, click a button, it is now
> > running.
> > Under the covers, a connector GBean has been added to the o/a/g/Server
> > Configuration.
> >
> >> 2. changing attribute values on pre-existing gbeans. To me this is
> >> less clear. I'm not thrilled with the idea of changing the content of
> >> a configuration jar: I'd prefer to see local modifications saved in a
> >> local database outside the supplied configurations. I can see how you
> >> would want to play with a running server till you like it, then save
> >> and seal a configuration, but I'm reluctant to allow this without more
> >> thought and a clear upgrade path to whatever we decide we want to do
> >> long-term. Still, this seems more reasonable to me than (1).
> >
> > Use case: server ships with HTTPS pointing to a self-signed cert. You
> > want to point it to a real cert, which requires the server to use a
> > password different than "secret". You go to the console, fill out a
> > form,
> > and the GBean property is changed to use the correct password.
> >
> > As for your implementation thoughts, I thought this is essentially what
> > was implemented -- that saved state was saved to a different place than
> > original state. I do not think we need the scope creep of creating
> > another database just for this.
> >
> > Aaron
> >
>
>
Re: GBeans: Saving Changes
Posted by Dain Sundstrom <da...@iq80.com>.
+1 for adding support for adding services to and removing services
from a configuration
On Jul 26, 2005, at 2:40 PM, David Jencks wrote:
> IMO both of these are much better done as part of the offline
> deployment process well before the configuration gets anywhere near
> a running server. Both of these are reasonable things to do, but
> again IMO not on a running server.
I don't think there is any way to avoid it in the current design.
> I'm not really sure how the current configuration saving works.
Simple. In doStop of the configuration we package up the current
configuration state and then tell the configuration store, the one
from which the configuration was originally loaded, to update the
configuration. The local cofinguration store simply, creates a new
serilized file in the configuration "save.ser". There is only one
save version, so you could conceivably rollback to the original saved
state, but not to a previous revision. Of course we have no
"rollback" logic anywhere in the current code base.
-dain
Re: GBeans: Saving Changes
Posted by David Jencks <da...@yahoo.com>.
IMO both of these are much better done as part of the offline
deployment process well before the configuration gets anywhere near a
running server. Both of these are reasonable things to do, but again
IMO not on a running server.
I'm not really sure how the current configuration saving works.
thanks
david jencks
On Jul 26, 2005, at 2:34 PM, Aaron Mulder wrote:
> On Tue, 26 Jul 2005, David Jencks wrote:
>> there are at least 2 aspects to mutable configurations.
>>
>> 1. adding/ removing gbeans. I don't think there is a valid use case
>> for this and don't think we should support it, ever. I don't think we
>> should allow changing reference patterns either for essentially the
>> same reasons.
>
> Use case: Server ships with HTTPS or AJP disabled. You want to enable
> it.
> You go to the console, fill in a form, click a button, it is now
> running.
> Under the covers, a connector GBean has been added to the o/a/g/Server
> Configuration.
>
>> 2. changing attribute values on pre-existing gbeans. To me this is
>> less clear. I'm not thrilled with the idea of changing the content of
>> a configuration jar: I'd prefer to see local modifications saved in a
>> local database outside the supplied configurations. I can see how you
>> would want to play with a running server till you like it, then save
>> and seal a configuration, but I'm reluctant to allow this without more
>> thought and a clear upgrade path to whatever we decide we want to do
>> long-term. Still, this seems more reasonable to me than (1).
>
> Use case: server ships with HTTPS pointing to a self-signed cert. You
> want to point it to a real cert, which requires the server to use a
> password different than "secret". You go to the console, fill out a
> form,
> and the GBean property is changed to use the correct password.
>
> As for your implementation thoughts, I thought this is essentially what
> was implemented -- that saved state was saved to a different place than
> original state. I do not think we need the scope creep of creating
> another database just for this.
>
> Aaron
>
Re: GBeans: Saving Changes
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Tue, 26 Jul 2005, David Jencks wrote:
> there are at least 2 aspects to mutable configurations.
>
> 1. adding/ removing gbeans. I don't think there is a valid use case
> for this and don't think we should support it, ever. I don't think we
> should allow changing reference patterns either for essentially the
> same reasons.
Use case: Server ships with HTTPS or AJP disabled. You want to enable it.
You go to the console, fill in a form, click a button, it is now running.
Under the covers, a connector GBean has been added to the o/a/g/Server
Configuration.
> 2. changing attribute values on pre-existing gbeans. To me this is
> less clear. I'm not thrilled with the idea of changing the content of
> a configuration jar: I'd prefer to see local modifications saved in a
> local database outside the supplied configurations. I can see how you
> would want to play with a running server till you like it, then save
> and seal a configuration, but I'm reluctant to allow this without more
> thought and a clear upgrade path to whatever we decide we want to do
> long-term. Still, this seems more reasonable to me than (1).
Use case: server ships with HTTPS pointing to a self-signed cert. You
want to point it to a real cert, which requires the server to use a
password different than "secret". You go to the console, fill out a form,
and the GBean property is changed to use the correct password.
As for your implementation thoughts, I thought this is essentially what
was implemented -- that saved state was saved to a different place than
original state. I do not think we need the scope creep of creating
another database just for this.
Aaron
Re: GBeans: Saving Changes
Posted by David Jencks <dj...@gluecode.com>.
there are at least 2 aspects to mutable configurations.
1. adding/ removing gbeans. I don't think there is a valid use case
for this and don't think we should support it, ever. I don't think we
should allow changing reference patterns either for essentially the
same reasons.
2. changing attribute values on pre-existing gbeans. To me this is
less clear. I'm not thrilled with the idea of changing the content of
a configuration jar: I'd prefer to see local modifications saved in a
local database outside the supplied configurations. I can see how you
would want to play with a running server till you like it, then save
and seal a configuration, but I'm reluctant to allow this without more
thought and a clear upgrade path to whatever we decide we want to do
long-term. Still, this seems more reasonable to me than (1).
thanks
david jencks
On Jul 26, 2005, at 2:18 PM, Aaron Mulder wrote:
> FYI, I'm considering this a discussion on our long-term policy.
> In the immediate future, I'm planning to go ahead with mutable
> configurations to support the desired functionality in the web console.
> I'm definitely open to revising that when the time comes and we have a
> more comprehensive strategy around this.
>
> Aaron
>
> On Tue, 26 Jul 2005, Jeremy Boynes wrote:
>> Aaron Mulder wrote:
>>> I don't understand why Jeremy's vision is incompatible with
>>> altering configurations on the fly. That is to say, you change and
>>> change
>>> and change, and when it's right, you (sign and) export
>>> "myconfig-1.3.1.jar". Perhaps that includes a single configuration
>>> (web
>>> container). Perhaps it contains several (J2EE server in a box,
>>> ready to
>>> apply to nodes in a cluster). If anyone else posts
>>> "myconfig-1.3.1.jar"
>>> to your download catalog, then either 1) they're an idiot (just like
>>> if I
>>> posted log4j-1.3.1 full of Aaron code not Log4j code), or 2) it's not
>>> signed with your certificate and can be recognized as a forgery. If
>>> we
>>> package configurations in JARs (and we haven't defined the
>>> "interchange
>>> format" to move configurations between servers / config stores but a
>>> JAR
>>> certainly seems reasonable), then they can be signed using the same
>>> tools
>>> that are normally avialable.
>>>
>>> Having immutable configurations does not affect these issues. I
>>> can name and version my configuration the same as you do even if
>>> they were
>>> both totally unchanged at runtime. Without some sense and/or
>>> signatures,
>>> there's nothing to prevent anything from conflicting. Just like we
>>> could
>>> post an updated set of M4 QA JARs today with the same name but
>>> different
>>> content.
>>>
>>
>> You alude to the problem yourself without realizing it. We have an
>> example of the problem right now with our build system and its use of
>> SNAPSHOT jars.
>>
>> SNAPSHOTs are mutable. Their content varies over time based on
>> whatever
>> happened to be in the source tree when they were built. If you have a
>> SNAPSHOT artifactId you won't know from one build to another that you
>> are using the same code.
>>
>> To the person developing that artifact, that it is a SNAPSHOT doesn't
>> matter - it's output work product to them, what they are using is the
>> source tree.
>>
>> However, to the person using the library it does matter. If they rely
>> on
>> a SNAPSHOT published to a repo they can't rely on getting the same
>> code
>> each time. If they need stability they need to use an explicit
>> version.
>> If the publisher publishes two different codebases under the same
>> version number then, to use your phrasing, "they're an idiot" and as a
>> user you start looking for alternatives. In other words, you want
>> released artifacts to be immutable and versioned.
>>
>> To have a consistent release we can't use mutable SNAPSHOTS and we
>> (primarily John) are going through and replacing them with immutable
>> versions.
>>
>> Putting this in the configuration context, when you start modifying a
>> configuration you are "developing" it - you're tweaking it to do what
>> you want. This is not a problem for you. However, it is a problem for
>> things that "use" that configuration and have certain expectations on
>> its behaviour as it is now doing what you want and not what it
>> advertised that it could do.
>>
>> There are things in the system that "use" your configuration - the
>> config builders and the applications that they build are two examples.
>> If you mutate the Server configuration from using Jetty to using
>> Tomcat,
>> an application that was built against that configuration with the
>> assumption that it was Jetty will no longer work.
>>
>> The HTTP connector example we are so fond of is a bad one as nothing
>> "uses" that bundle - it is a user of other bundles, dispatching
>> requests
>> to them but nothing actually references it. You can mutate it to your
>> heart's content and nothing will notice.
>>
>> As an alternative, consider an example where an application contains a
>> message-link that uses a queue. The application builder can look at
>> the
>> server configuration, see that there is no queue there and decide that
>> it should define one in the application bundle. That bundle can be
>> moved
>> to any instance running that server configuration and will run quite
>> happily as it is taking its queue along with it. However, if the
>> server
>> configuration is mutated on some instances so that it has a queue you
>> now have a conflict: two queues, one from the mutated server, one from
>> the application. Or if the configuration is mutated to use a different
>> message provider then it may not work at all.
>>
>> The challenge we face is finding a balance between the things that can
>> mutate that no-one will notice and things that should be immutable so
>> that they can reliably be used by others.
>>
>> --
>> Jeremy
>>
>
Re: GBeans: Saving Changes
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
FYI, I'm considering this a discussion on our long-term policy.
In the immediate future, I'm planning to go ahead with mutable
configurations to support the desired functionality in the web console.
I'm definitely open to revising that when the time comes and we have a
more comprehensive strategy around this.
Aaron
On Tue, 26 Jul 2005, Jeremy Boynes wrote:
> Aaron Mulder wrote:
> > I don't understand why Jeremy's vision is incompatible with
> > altering configurations on the fly. That is to say, you change and change
> > and change, and when it's right, you (sign and) export
> > "myconfig-1.3.1.jar". Perhaps that includes a single configuration (web
> > container). Perhaps it contains several (J2EE server in a box, ready to
> > apply to nodes in a cluster). If anyone else posts "myconfig-1.3.1.jar"
> > to your download catalog, then either 1) they're an idiot (just like if I
> > posted log4j-1.3.1 full of Aaron code not Log4j code), or 2) it's not
> > signed with your certificate and can be recognized as a forgery. If we
> > package configurations in JARs (and we haven't defined the "interchange
> > format" to move configurations between servers / config stores but a JAR
> > certainly seems reasonable), then they can be signed using the same tools
> > that are normally avialable.
> >
> > Having immutable configurations does not affect these issues. I
> > can name and version my configuration the same as you do even if they were
> > both totally unchanged at runtime. Without some sense and/or signatures,
> > there's nothing to prevent anything from conflicting. Just like we could
> > post an updated set of M4 QA JARs today with the same name but different
> > content.
> >
>
> You alude to the problem yourself without realizing it. We have an
> example of the problem right now with our build system and its use of
> SNAPSHOT jars.
>
> SNAPSHOTs are mutable. Their content varies over time based on whatever
> happened to be in the source tree when they were built. If you have a
> SNAPSHOT artifactId you won't know from one build to another that you
> are using the same code.
>
> To the person developing that artifact, that it is a SNAPSHOT doesn't
> matter - it's output work product to them, what they are using is the
> source tree.
>
> However, to the person using the library it does matter. If they rely on
> a SNAPSHOT published to a repo they can't rely on getting the same code
> each time. If they need stability they need to use an explicit version.
> If the publisher publishes two different codebases under the same
> version number then, to use your phrasing, "they're an idiot" and as a
> user you start looking for alternatives. In other words, you want
> released artifacts to be immutable and versioned.
>
> To have a consistent release we can't use mutable SNAPSHOTS and we
> (primarily John) are going through and replacing them with immutable
> versions.
>
> Putting this in the configuration context, when you start modifying a
> configuration you are "developing" it - you're tweaking it to do what
> you want. This is not a problem for you. However, it is a problem for
> things that "use" that configuration and have certain expectations on
> its behaviour as it is now doing what you want and not what it
> advertised that it could do.
>
> There are things in the system that "use" your configuration - the
> config builders and the applications that they build are two examples.
> If you mutate the Server configuration from using Jetty to using Tomcat,
> an application that was built against that configuration with the
> assumption that it was Jetty will no longer work.
>
> The HTTP connector example we are so fond of is a bad one as nothing
> "uses" that bundle - it is a user of other bundles, dispatching requests
> to them but nothing actually references it. You can mutate it to your
> heart's content and nothing will notice.
>
> As an alternative, consider an example where an application contains a
> message-link that uses a queue. The application builder can look at the
> server configuration, see that there is no queue there and decide that
> it should define one in the application bundle. That bundle can be moved
> to any instance running that server configuration and will run quite
> happily as it is taking its queue along with it. However, if the server
> configuration is mutated on some instances so that it has a queue you
> now have a conflict: two queues, one from the mutated server, one from
> the application. Or if the configuration is mutated to use a different
> message provider then it may not work at all.
>
> The challenge we face is finding a balance between the things that can
> mutate that no-one will notice and things that should be immutable so
> that they can reliably be used by others.
>
> --
> Jeremy
>
Re: GBeans: Saving Changes
Posted by Jeremy Boynes <jb...@apache.org>.
Aaron Mulder wrote:
> I don't understand why Jeremy's vision is incompatible with
> altering configurations on the fly. That is to say, you change and change
> and change, and when it's right, you (sign and) export
> "myconfig-1.3.1.jar". Perhaps that includes a single configuration (web
> container). Perhaps it contains several (J2EE server in a box, ready to
> apply to nodes in a cluster). If anyone else posts "myconfig-1.3.1.jar"
> to your download catalog, then either 1) they're an idiot (just like if I
> posted log4j-1.3.1 full of Aaron code not Log4j code), or 2) it's not
> signed with your certificate and can be recognized as a forgery. If we
> package configurations in JARs (and we haven't defined the "interchange
> format" to move configurations between servers / config stores but a JAR
> certainly seems reasonable), then they can be signed using the same tools
> that are normally avialable.
>
> Having immutable configurations does not affect these issues. I
> can name and version my configuration the same as you do even if they were
> both totally unchanged at runtime. Without some sense and/or signatures,
> there's nothing to prevent anything from conflicting. Just like we could
> post an updated set of M4 QA JARs today with the same name but different
> content.
>
You alude to the problem yourself without realizing it. We have an
example of the problem right now with our build system and its use of
SNAPSHOT jars.
SNAPSHOTs are mutable. Their content varies over time based on whatever
happened to be in the source tree when they were built. If you have a
SNAPSHOT artifactId you won't know from one build to another that you
are using the same code.
To the person developing that artifact, that it is a SNAPSHOT doesn't
matter - it's output work product to them, what they are using is the
source tree.
However, to the person using the library it does matter. If they rely on
a SNAPSHOT published to a repo they can't rely on getting the same code
each time. If they need stability they need to use an explicit version.
If the publisher publishes two different codebases under the same
version number then, to use your phrasing, "they're an idiot" and as a
user you start looking for alternatives. In other words, you want
released artifacts to be immutable and versioned.
To have a consistent release we can't use mutable SNAPSHOTS and we
(primarily John) are going through and replacing them with immutable
versions.
Putting this in the configuration context, when you start modifying a
configuration you are "developing" it - you're tweaking it to do what
you want. This is not a problem for you. However, it is a problem for
things that "use" that configuration and have certain expectations on
its behaviour as it is now doing what you want and not what it
advertised that it could do.
There are things in the system that "use" your configuration - the
config builders and the applications that they build are two examples.
If you mutate the Server configuration from using Jetty to using Tomcat,
an application that was built against that configuration with the
assumption that it was Jetty will no longer work.
The HTTP connector example we are so fond of is a bad one as nothing
"uses" that bundle - it is a user of other bundles, dispatching requests
to them but nothing actually references it. You can mutate it to your
heart's content and nothing will notice.
As an alternative, consider an example where an application contains a
message-link that uses a queue. The application builder can look at the
server configuration, see that there is no queue there and decide that
it should define one in the application bundle. That bundle can be moved
to any instance running that server configuration and will run quite
happily as it is taking its queue along with it. However, if the server
configuration is mutated on some instances so that it has a queue you
now have a conflict: two queues, one from the mutated server, one from
the application. Or if the configuration is mutated to use a different
message provider then it may not work at all.
The challenge we face is finding a balance between the things that can
mutate that no-one will notice and things that should be immutable so
that they can reliably be used by others.
--
Jeremy
Re: GBeans: Saving Changes
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
I don't understand why Jeremy's vision is incompatible with
altering configurations on the fly. That is to say, you change and change
and change, and when it's right, you (sign and) export
"myconfig-1.3.1.jar". Perhaps that includes a single configuration (web
container). Perhaps it contains several (J2EE server in a box, ready to
apply to nodes in a cluster). If anyone else posts "myconfig-1.3.1.jar"
to your download catalog, then either 1) they're an idiot (just like if I
posted log4j-1.3.1 full of Aaron code not Log4j code), or 2) it's not
signed with your certificate and can be recognized as a forgery. If we
package configurations in JARs (and we haven't defined the "interchange
format" to move configurations between servers / config stores but a JAR
certainly seems reasonable), then they can be signed using the same tools
that are normally avialable.
Having immutable configurations does not affect these issues. I
can name and version my configuration the same as you do even if they were
both totally unchanged at runtime. Without some sense and/or signatures,
there's nothing to prevent anything from conflicting. Just like we could
post an updated set of M4 QA JARs today with the same name but different
content.
I'll grant you I could download your configuration and then change
it and then blame you if it doesn't work. But I already said I don't mind
adding a flag of some sort. And really, what are the odds that a
configuration is going to be 100% perfect? What if the web configuration
is totally groovy but aimed at a bigger box so you want to tone down the
accept thread pool? What if you want to change ports? What if you prefer
Jikes? If you must take it entirely without alteration or not at all, I
don't think that will be worth so much.
As far as the volume of "stuff" in a configuration, we can think
of some way to disentangle class loaders from configurations. But we have
(in my poor estimation) probably hundreds of GBeans in a server today, and
I don't think it makes sense to have tens or hundreds of configurations.
That just means that if you want to disable some feature, you have to run
loads of commands instead of one. And if you want to download from a
catalog, you have a lot more individual stuff to download. It might be
useful to separate EJB out from Web and J2EE foundation, but it doesn't
bother me all that much -- we already have JMS and JDBC separate, which is
a fine start. Not a big deal to me either way.
I totally agree with David that it would be great to be able to
deploy more bits as parts of an application. I think it's pretty
desirable to be able to deploy connectors as part of an application, so
you can bundle your DB pool or JMS destinations with your app.
However, I don't at all think it makes sense to claim that
replaces the ability to adjust server configuration at runtime, and I
don't believe that it makes sense to actually bundle web connectors as
part of an application. If nothing else, what happens if you have two
applications that are both going to run via an AJP connection on port
8009? Which gets the connector? What if one app deploys HTTP on 8080 and
another deploys HTTPS on 8080? What if you have developers who prepare
applications, and administrators who do server administration? Does it
make sense to require that admins have the skills and tools to alter the
application plans (potentially damaging the plans that just passed QA)?
In any case, to address the compiled vs interpreted bit, if your
vision of management is that you must always edit a config file and then
run a tool on the config file to replace the old state of the server with
the new state, and the web console will always be read-only, I have to
respectfully disagree (no matter how fast the tool runs).
Thanks,
Aaron
P.S. I think we should ultimately separate some goals from implementation
and agree on things like "would be nice to have portable format for
exchanging configurations, with ability to bundle one or more in a JAR and
sign it" and "would be nice to be able to deploy connectors with apps".
It seems to be the implications we disagree on more than the fundamental
goals.
On Tue, 26 Jul 2005, David Jencks wrote:
> I really like this model and explanation and wonder just how soon we
> can make it a reality.
>
> Last fall I thought we needed the ability to add gbeans to running
> configurations so you could add datasources, queues, etc to the server
> while you were getting ready to deploy an app, using an admin console
> (in fact an earlier version of the one just donated by IBM).
>
> However, I think there's a better way to do this, namely, instead of
> adding bits to the app server to make the environment ready for the
> app, add bits of app server to the application so it brings what it
> needs along with itself. Right now we can do this with plain gbeans
> in all components (such as for security, corba, and web connectors),
> and resource adapters in app clients. I'm planning the ability to add
> at least entire resource adapter configurations into other module
> types, and considering adding the ability to deploy additional complete
> j2ee modules just using the vendor plan.
>
> I can imagine a bit of a ui that analyzes the configurations present in
> a server (i.e. a bunch of deployed configurations) and your application
> and shows you what is unresolved in the application, and guides you
> through either adding more prebuild configs to your server or adding
> additional stuff into your application so everything is pre-resolved
> before you try to deploy for the first time.
>
> I think with this point of view and possibly with such tools most of
> the need to add gbeans to running configurations goes away. As for the
> question of changing and saving gbean attributes in a running
> configuration, I'm not sure what to think. It seems like an
> interpreted vs compiled language debate. Right now our "compiler" is
> decidedly inconvenient for a rapid change cycle: I'm not sure how much
> faster it would need to get before it seemed like a more reasonable
> alternative to live changes.
>
> thanks
> david jencks
>
> On Jul 25, 2005, at 7:09 PM, Jeremy Boynes wrote:
>
> > I'd ask you to set aside traditional thinking and try this out for a
> > bit.
> >
> > When you write code, you edit a couple of source files, compile it,
> > fix the typos, build a jar, test it, decide its good enough and commit
> > the change. After doing this a few times you decide its good enough
> > and do a release, taking the jar file you built and saving for
> > posterity. You then do it all over again.
> >
> > If you're doing this with Maven, it spells out the difference between
> > the jar you are working with (a SNAPSHOT) and the jar you release
> > (something with a version number).
> >
> > Sound familiar?
> >
> > In a large production environment you do the same kind of thing with
> > system configurations. You set up a system the way you want, check
> > that it works, beat the snot out of it (aka stress testing or
> > benchmarking), see how/when it falls over, tweak the config and repeat
> > until it you're happy, then document it, have someone else try the
> > change in your staging environment, check it still works, then beg the
> > change control board to let you move it to production at 3AM on a
> > Sunday morning. You then cross your fingers and hope it really works.
> >
> > A bit different from changing things on a desktop machine or the box
> > that runs the family website, but not unrealistic and the problem the
> > architecture was trying to simplify.
> >
> > [[ to avoid a disgression, is Geronimo ready for this? Who knows; in
> > the end the people doing such things factor in the risks associated
> > with any software no matter how mature and they will make up their own
> > minds ]]
> >
> > The idea behind the configuration bundles is that they are pre-wired
> > sets of closely coupled components that co-ordinate to perform a
> > specific task. A single bundle is *not* meant to represent the entire
> > system assembly - the current o/a/g/Server is an abberation caused by
> > problems in the classloader model (described elsewhere) not example of
> > "best practice."
> >
> > The purpose of a bundle is to allow a knowledgable person to, for
> > example, pre-wire a web container in a way that allows other people to
> > use it just by defining a few characteristics. So, for example,
> > someone can go to a repository and find, for example, a pre-wired
> > version of a Jetty bundle pre-configured for 100 concurrent users at
> > 95% static content with a typical dynamic reponse time of 500ms when
> > running on an Acme-4000 Linux machine.
> >
> > So why does this need to be immutable? Because if you are pulling
> > these things from a catalog then you need to know that you're going to
> > get what you expect and not some version that someone happened to
> > tweak but just forgot to change the name.
> >
> > It would be like having several jar files out there called
> > log4j-1.2.8.jar that were actually different - a recipe for chaos. BTW
> > one reason bundles are JAR files is because it's dead easy to sign
> > them so that you can tell if they have been tweaked.
> >
> > Now, just as in the code development example I gave at the top, these
> > kind of pre-packaged bundles are also going to go through a
> > development process. One reason we didn't version stamp the configIds
> > in the current assembly is that until now all our configurations have
> > really been in development and it didn't make sense to be dealing with
> > new versions all the time. It probably would have been clearer to id
> > them as e.g. o/a/g/Server/1.0-SNAPSHOT but I guess that's water under
> > the bridge now.
> >
> > So, in an ideal world, your user below would just pick a suitable
> > pre-built bundle out of some repo and be happy with what it does. If
> > it doesn't quite do what they want or nothing suitable can be found,
> > they start by building and tweaking my/web/Container/1.0-SNAPSHOT,
> > iterate it a few times and then finalize on my/web/Container/1.0.
> >
> > The problem is identical to a developer not filling up their Maven
> > repo with trivially different versions of a jar they are working on
> > (which is why Maven has SNAPSHOTs in the first place).
> >
> > To pick a bad analogy, we're trying to do with server configuration
> > what Maven did for builds. No, I don't mean trying to make it slow and
> > take forever to start. We're trying to simplify the administration
> > process by allowing a admin to choose from a re-usable set of
> > pre-optimized bundles rather than having to do it all by hand, in the
> > same way Maven uses plugins to replace manually created ant scripts.
> >
> > It's different. It's unusual. It takes some getting used to.
> > But it might just work.
> >
> > --
> > Jeremy
> >
> > Aaron Mulder wrote:
> >> For my part, I'm not convinced that it makes sense for
> >> configurations to be immutable. I think the export/import feature
> >> would be nice -- "I finally got my web container configured 'just
> >> right', now let me export it and load it into my cluster of 30
> >> boxes". I wouldn't even mind giving each configuration a unique hash
> >> or something such that we could eventually down the road add a
> >> feature where you export two related configurations, and one refers
> >> to that specific build of the other. Or even having an immutable
> >> flag on a configuration such that once you've marked one as immutable
> >> it refuses to change in the future.
> >> But to tell me that properties of a configuration shouldn't ever
> >> be changed, or that GBeans shouldn't be added or removed at runtime
> >> and we
> >> should create new child configurations instead... unless I'm
> >> misunderstanding you, that just doesn't work for me. I can't imagine
> >> someone customizing their web container and then after a few revs
> >> they try
> >> to load or unload or export it and discover that they now have
> >> configurations "Server", "Server HTTP v1..v5" "Server HTTPS v1..v3"
> >> "Server AJP v1 & v2" "Server Keystore v1..v4" "Server accept thread
> >> pool
> >> v1" "Server JSP Compiler v1..v3" "Server request log v1..v5", and so
> >> on. Much better IMHO to let them alter the "Server" configuration to
> >> their
> >> heart's content, then let them export it or flag it as locked if they
> >> want
> >> to preserve a snapshot of that state.
> >> Thanks,
> >> Aaron
> >> On Mon, 25 Jul 2005, Jeremy Boynes wrote:
> >>> Configuration bundles are meant to be immutable so you shouldn't be
> >>> adding things to them at runtime. Think of them as being similar to
> >>> library jars or other maven artifacts - things would get very
> >>> confusing if you started adding classes into them as part of a
> >>> build. This allows the configuration to be identified by its ID in
> >>> the same way the artifact id identifies a dependency to maven.
> >>>
> >>> Configuration bundles have attributes (currently modeled by exposing
> >>> the GBeans they contain which is problematic) which pertain to the
> >>> location in which they are being used. The *default* values for
> >>> those attributes are contained inside the bundle; the instance value
> >>> is set by the environment.
> >>>
> >>> There are some implementation issues in Geronimo today (short cuts
> >>> taken for expediency) which obscure some of the subtleties of this
> >>> model. Some of these relate to classloading (the issues on the
> >>> packaging thread), others relate to GBean persistence.
> >>>
> >>> I'll give a couple of examples which I hope highlight a couple of
> >>> the issues.
> >>>
> >>> The first anti-pattern is that configuration ids are not unique - we
> >>> reuse them for different configurations. For example, although
> >>> Tomcat and Jetty based servers are quite different we use the same
> >>> "unique" id (org/apache/geronimo/Server) for both. We also reuse ids
> >>> across versions so it is impossible to tell if an application
> >>> deployed against org/apache/geronimo/Server was built using M1, M2,
> >>> M3 or HEAD. It is like only ever compiling against SNAPSHOT
> >>> dependencies.
> >>>
> >>> Secondly, if configurations are immutable then you should not be
> >>> able to add GBeans to them at runtime (that would be mutating them).
> >>> So how do you add a network connector? The simplest model is to
> >>> separate the web container from its connectors and build them as
> >>> separate bundles (one for the container, one for each of the
> >>> connectors); if you want to add a new connector you add a new
> >>> instance of e.g. the HTTPS bundle.
> >>>
> >>> Finally, there is the issue of instance properties - things in the
> >>> environment of where a configuration is being used that need to
> >>> override the default properties that is has. For example, the
> >>> default for the HTTP connector bundle might be to listen on port
> >>> 8080 but on this server here it needs to be changed to be 8888.
> >>> Right now we do this by mutating the configuration installed in the
> >>> store which is problematic. Instead it would be better to associate
> >>> the state with the runtime and, after the bundle was loaded but
> >>> before it was started, inject those local values into it.
> >>>
> >>> There's a fine line between when you want to override values on a
> >>> per instance basis and when you want to define a new configuration
> >>> for with those values as defaults. There's no right solution to that
> >>> but I think the type of installation plays into it:
> >>> * for a desktop development environment or single server installation
> >>> then you are better just overriding properties as needed
> >>> * for a clustered environment or large scale deployment then you are
> >>> better defining reusable bundles that can be easily moved
> >>> where/when
> >>> they are required
> >>>
> >>> As Geronimo starts being considered for larger installations let's
> >>> not forget what the original config system was designed to do.
> >>>
> >>> --
> >>> Jeremy
> >>>
> >
>
>
Re: GBeans: Saving Changes
Posted by David Jencks <dj...@gluecode.com>.
I really like this model and explanation and wonder just how soon we
can make it a reality.
Last fall I thought we needed the ability to add gbeans to running
configurations so you could add datasources, queues, etc to the server
while you were getting ready to deploy an app, using an admin console
(in fact an earlier version of the one just donated by IBM).
However, I think there's a better way to do this, namely, instead of
adding bits to the app server to make the environment ready for the
app, add bits of app server to the application so it brings what it
needs along with itself. Right now we can do this with plain gbeans
in all components (such as for security, corba, and web connectors),
and resource adapters in app clients. I'm planning the ability to add
at least entire resource adapter configurations into other module
types, and considering adding the ability to deploy additional complete
j2ee modules just using the vendor plan.
I can imagine a bit of a ui that analyzes the configurations present in
a server (i.e. a bunch of deployed configurations) and your application
and shows you what is unresolved in the application, and guides you
through either adding more prebuild configs to your server or adding
additional stuff into your application so everything is pre-resolved
before you try to deploy for the first time.
I think with this point of view and possibly with such tools most of
the need to add gbeans to running configurations goes away. As for the
question of changing and saving gbean attributes in a running
configuration, I'm not sure what to think. It seems like an
interpreted vs compiled language debate. Right now our "compiler" is
decidedly inconvenient for a rapid change cycle: I'm not sure how much
faster it would need to get before it seemed like a more reasonable
alternative to live changes.
thanks
david jencks
On Jul 25, 2005, at 7:09 PM, Jeremy Boynes wrote:
> I'd ask you to set aside traditional thinking and try this out for a
> bit.
>
> When you write code, you edit a couple of source files, compile it,
> fix the typos, build a jar, test it, decide its good enough and commit
> the change. After doing this a few times you decide its good enough
> and do a release, taking the jar file you built and saving for
> posterity. You then do it all over again.
>
> If you're doing this with Maven, it spells out the difference between
> the jar you are working with (a SNAPSHOT) and the jar you release
> (something with a version number).
>
> Sound familiar?
>
> In a large production environment you do the same kind of thing with
> system configurations. You set up a system the way you want, check
> that it works, beat the snot out of it (aka stress testing or
> benchmarking), see how/when it falls over, tweak the config and repeat
> until it you're happy, then document it, have someone else try the
> change in your staging environment, check it still works, then beg the
> change control board to let you move it to production at 3AM on a
> Sunday morning. You then cross your fingers and hope it really works.
>
> A bit different from changing things on a desktop machine or the box
> that runs the family website, but not unrealistic and the problem the
> architecture was trying to simplify.
>
> [[ to avoid a disgression, is Geronimo ready for this? Who knows; in
> the end the people doing such things factor in the risks associated
> with any software no matter how mature and they will make up their own
> minds ]]
>
> The idea behind the configuration bundles is that they are pre-wired
> sets of closely coupled components that co-ordinate to perform a
> specific task. A single bundle is *not* meant to represent the entire
> system assembly - the current o/a/g/Server is an abberation caused by
> problems in the classloader model (described elsewhere) not example of
> "best practice."
>
> The purpose of a bundle is to allow a knowledgable person to, for
> example, pre-wire a web container in a way that allows other people to
> use it just by defining a few characteristics. So, for example,
> someone can go to a repository and find, for example, a pre-wired
> version of a Jetty bundle pre-configured for 100 concurrent users at
> 95% static content with a typical dynamic reponse time of 500ms when
> running on an Acme-4000 Linux machine.
>
> So why does this need to be immutable? Because if you are pulling
> these things from a catalog then you need to know that you're going to
> get what you expect and not some version that someone happened to
> tweak but just forgot to change the name.
>
> It would be like having several jar files out there called
> log4j-1.2.8.jar that were actually different - a recipe for chaos. BTW
> one reason bundles are JAR files is because it's dead easy to sign
> them so that you can tell if they have been tweaked.
>
> Now, just as in the code development example I gave at the top, these
> kind of pre-packaged bundles are also going to go through a
> development process. One reason we didn't version stamp the configIds
> in the current assembly is that until now all our configurations have
> really been in development and it didn't make sense to be dealing with
> new versions all the time. It probably would have been clearer to id
> them as e.g. o/a/g/Server/1.0-SNAPSHOT but I guess that's water under
> the bridge now.
>
> So, in an ideal world, your user below would just pick a suitable
> pre-built bundle out of some repo and be happy with what it does. If
> it doesn't quite do what they want or nothing suitable can be found,
> they start by building and tweaking my/web/Container/1.0-SNAPSHOT,
> iterate it a few times and then finalize on my/web/Container/1.0.
>
> The problem is identical to a developer not filling up their Maven
> repo with trivially different versions of a jar they are working on
> (which is why Maven has SNAPSHOTs in the first place).
>
> To pick a bad analogy, we're trying to do with server configuration
> what Maven did for builds. No, I don't mean trying to make it slow and
> take forever to start. We're trying to simplify the administration
> process by allowing a admin to choose from a re-usable set of
> pre-optimized bundles rather than having to do it all by hand, in the
> same way Maven uses plugins to replace manually created ant scripts.
>
> It's different. It's unusual. It takes some getting used to.
> But it might just work.
>
> --
> Jeremy
>
> Aaron Mulder wrote:
>> For my part, I'm not convinced that it makes sense for
>> configurations to be immutable. I think the export/import feature
>> would be nice -- "I finally got my web container configured 'just
>> right', now let me export it and load it into my cluster of 30
>> boxes". I wouldn't even mind giving each configuration a unique hash
>> or something such that we could eventually down the road add a
>> feature where you export two related configurations, and one refers
>> to that specific build of the other. Or even having an immutable
>> flag on a configuration such that once you've marked one as immutable
>> it refuses to change in the future.
>> But to tell me that properties of a configuration shouldn't ever
>> be changed, or that GBeans shouldn't be added or removed at runtime
>> and we
>> should create new child configurations instead... unless I'm
>> misunderstanding you, that just doesn't work for me. I can't imagine
>> someone customizing their web container and then after a few revs
>> they try
>> to load or unload or export it and discover that they now have
>> configurations "Server", "Server HTTP v1..v5" "Server HTTPS v1..v3"
>> "Server AJP v1 & v2" "Server Keystore v1..v4" "Server accept thread
>> pool
>> v1" "Server JSP Compiler v1..v3" "Server request log v1..v5", and so
>> on. Much better IMHO to let them alter the "Server" configuration to
>> their
>> heart's content, then let them export it or flag it as locked if they
>> want
>> to preserve a snapshot of that state.
>> Thanks,
>> Aaron
>> On Mon, 25 Jul 2005, Jeremy Boynes wrote:
>>> Configuration bundles are meant to be immutable so you shouldn't be
>>> adding things to them at runtime. Think of them as being similar to
>>> library jars or other maven artifacts - things would get very
>>> confusing if you started adding classes into them as part of a
>>> build. This allows the configuration to be identified by its ID in
>>> the same way the artifact id identifies a dependency to maven.
>>>
>>> Configuration bundles have attributes (currently modeled by exposing
>>> the GBeans they contain which is problematic) which pertain to the
>>> location in which they are being used. The *default* values for
>>> those attributes are contained inside the bundle; the instance value
>>> is set by the environment.
>>>
>>> There are some implementation issues in Geronimo today (short cuts
>>> taken for expediency) which obscure some of the subtleties of this
>>> model. Some of these relate to classloading (the issues on the
>>> packaging thread), others relate to GBean persistence.
>>>
>>> I'll give a couple of examples which I hope highlight a couple of
>>> the issues.
>>>
>>> The first anti-pattern is that configuration ids are not unique - we
>>> reuse them for different configurations. For example, although
>>> Tomcat and Jetty based servers are quite different we use the same
>>> "unique" id (org/apache/geronimo/Server) for both. We also reuse ids
>>> across versions so it is impossible to tell if an application
>>> deployed against org/apache/geronimo/Server was built using M1, M2,
>>> M3 or HEAD. It is like only ever compiling against SNAPSHOT
>>> dependencies.
>>>
>>> Secondly, if configurations are immutable then you should not be
>>> able to add GBeans to them at runtime (that would be mutating them).
>>> So how do you add a network connector? The simplest model is to
>>> separate the web container from its connectors and build them as
>>> separate bundles (one for the container, one for each of the
>>> connectors); if you want to add a new connector you add a new
>>> instance of e.g. the HTTPS bundle.
>>>
>>> Finally, there is the issue of instance properties - things in the
>>> environment of where a configuration is being used that need to
>>> override the default properties that is has. For example, the
>>> default for the HTTP connector bundle might be to listen on port
>>> 8080 but on this server here it needs to be changed to be 8888.
>>> Right now we do this by mutating the configuration installed in the
>>> store which is problematic. Instead it would be better to associate
>>> the state with the runtime and, after the bundle was loaded but
>>> before it was started, inject those local values into it.
>>>
>>> There's a fine line between when you want to override values on a
>>> per instance basis and when you want to define a new configuration
>>> for with those values as defaults. There's no right solution to that
>>> but I think the type of installation plays into it:
>>> * for a desktop development environment or single server installation
>>> then you are better just overriding properties as needed
>>> * for a clustered environment or large scale deployment then you are
>>> better defining reusable bundles that can be easily moved
>>> where/when
>>> they are required
>>>
>>> As Geronimo starts being considered for larger installations let's
>>> not forget what the original config system was designed to do.
>>>
>>> --
>>> Jeremy
>>>
>
Re: GBeans: Saving Changes
Posted by Jeremy Boynes <jb...@apache.org>.
I'd ask you to set aside traditional thinking and try this out for a bit.
When you write code, you edit a couple of source files, compile it, fix
the typos, build a jar, test it, decide its good enough and commit the
change. After doing this a few times you decide its good enough and do a
release, taking the jar file you built and saving for posterity. You
then do it all over again.
If you're doing this with Maven, it spells out the difference between
the jar you are working with (a SNAPSHOT) and the jar you release
(something with a version number).
Sound familiar?
In a large production environment you do the same kind of thing with
system configurations. You set up a system the way you want, check that
it works, beat the snot out of it (aka stress testing or benchmarking),
see how/when it falls over, tweak the config and repeat until it you're
happy, then document it, have someone else try the change in your
staging environment, check it still works, then beg the change control
board to let you move it to production at 3AM on a Sunday morning. You
then cross your fingers and hope it really works.
A bit different from changing things on a desktop machine or the box
that runs the family website, but not unrealistic and the problem the
architecture was trying to simplify.
[[ to avoid a disgression, is Geronimo ready for this? Who knows; in the
end the people doing such things factor in the risks associated with any
software no matter how mature and they will make up their own minds ]]
The idea behind the configuration bundles is that they are pre-wired
sets of closely coupled components that co-ordinate to perform a
specific task. A single bundle is *not* meant to represent the entire
system assembly - the current o/a/g/Server is an abberation caused by
problems in the classloader model (described elsewhere) not example of
"best practice."
The purpose of a bundle is to allow a knowledgable person to, for
example, pre-wire a web container in a way that allows other people to
use it just by defining a few characteristics. So, for example, someone
can go to a repository and find, for example, a pre-wired version of a
Jetty bundle pre-configured for 100 concurrent users at 95% static
content with a typical dynamic reponse time of 500ms when running on an
Acme-4000 Linux machine.
So why does this need to be immutable? Because if you are pulling these
things from a catalog then you need to know that you're going to get
what you expect and not some version that someone happened to tweak but
just forgot to change the name.
It would be like having several jar files out there called
log4j-1.2.8.jar that were actually different - a recipe for chaos. BTW
one reason bundles are JAR files is because it's dead easy to sign them
so that you can tell if they have been tweaked.
Now, just as in the code development example I gave at the top, these
kind of pre-packaged bundles are also going to go through a development
process. One reason we didn't version stamp the configIds in the current
assembly is that until now all our configurations have really been in
development and it didn't make sense to be dealing with new versions all
the time. It probably would have been clearer to id them as e.g.
o/a/g/Server/1.0-SNAPSHOT but I guess that's water under the bridge now.
So, in an ideal world, your user below would just pick a suitable
pre-built bundle out of some repo and be happy with what it does. If it
doesn't quite do what they want or nothing suitable can be found, they
start by building and tweaking my/web/Container/1.0-SNAPSHOT, iterate it
a few times and then finalize on my/web/Container/1.0.
The problem is identical to a developer not filling up their Maven repo
with trivially different versions of a jar they are working on (which is
why Maven has SNAPSHOTs in the first place).
To pick a bad analogy, we're trying to do with server configuration what
Maven did for builds. No, I don't mean trying to make it slow and take
forever to start. We're trying to simplify the administration process by
allowing a admin to choose from a re-usable set of pre-optimized bundles
rather than having to do it all by hand, in the same way Maven uses
plugins to replace manually created ant scripts.
It's different. It's unusual. It takes some getting used to.
But it might just work.
--
Jeremy
Aaron Mulder wrote:
> For my part, I'm not convinced that it makes sense for
> configurations to be immutable. I think the export/import feature would
> be nice -- "I finally got my web container configured 'just right', now
> let me export it and load it into my cluster of 30 boxes". I wouldn't
> even mind giving each configuration a unique hash or something such that
> we could eventually down the road add a feature where you export two
> related configurations, and one refers to that specific build of the
> other. Or even having an immutable flag on a configuration such that once
> you've marked one as immutable it refuses to change in the future.
>
> But to tell me that properties of a configuration shouldn't ever
> be changed, or that GBeans shouldn't be added or removed at runtime and we
> should create new child configurations instead... unless I'm
> misunderstanding you, that just doesn't work for me. I can't imagine
> someone customizing their web container and then after a few revs they try
> to load or unload or export it and discover that they now have
> configurations "Server", "Server HTTP v1..v5" "Server HTTPS v1..v3"
> "Server AJP v1 & v2" "Server Keystore v1..v4" "Server accept thread pool
> v1" "Server JSP Compiler v1..v3" "Server request log v1..v5", and so on.
> Much better IMHO to let them alter the "Server" configuration to their
> heart's content, then let them export it or flag it as locked if they want
> to preserve a snapshot of that state.
>
> Thanks,
> Aaron
>
> On Mon, 25 Jul 2005, Jeremy Boynes wrote:
>
>>Configuration bundles are meant to be immutable so you shouldn't be
>>adding things to them at runtime. Think of them as being similar to
>>library jars or other maven artifacts - things would get very confusing
>>if you started adding classes into them as part of a build. This allows
>>the configuration to be identified by its ID in the same way the
>>artifact id identifies a dependency to maven.
>>
>>Configuration bundles have attributes (currently modeled by exposing the
>>GBeans they contain which is problematic) which pertain to the location
>>in which they are being used. The *default* values for those attributes
>>are contained inside the bundle; the instance value is set by the
>>environment.
>>
>>There are some implementation issues in Geronimo today (short cuts taken
>>for expediency) which obscure some of the subtleties of this model. Some
>>of these relate to classloading (the issues on the packaging thread),
>>others relate to GBean persistence.
>>
>>I'll give a couple of examples which I hope highlight a couple of the
>>issues.
>>
>>The first anti-pattern is that configuration ids are not unique - we
>>reuse them for different configurations. For example, although Tomcat
>>and Jetty based servers are quite different we use the same "unique" id
>>(org/apache/geronimo/Server) for both. We also reuse ids across versions
>>so it is impossible to tell if an application deployed against
>>org/apache/geronimo/Server was built using M1, M2, M3 or HEAD. It is
>>like only ever compiling against SNAPSHOT dependencies.
>>
>>Secondly, if configurations are immutable then you should not be able to
>>add GBeans to them at runtime (that would be mutating them). So how do
>>you add a network connector? The simplest model is to separate the web
>>container from its connectors and build them as separate bundles (one
>>for the container, one for each of the connectors); if you want to add a
>>new connector you add a new instance of e.g. the HTTPS bundle.
>>
>>Finally, there is the issue of instance properties - things in the
>>environment of where a configuration is being used that need to override
>>the default properties that is has. For example, the default for the
>>HTTP connector bundle might be to listen on port 8080 but on this server
>>here it needs to be changed to be 8888. Right now we do this by mutating
>>the configuration installed in the store which is problematic. Instead
>>it would be better to associate the state with the runtime and, after
>>the bundle was loaded but before it was started, inject those local
>>values into it.
>>
>>There's a fine line between when you want to override values on a per
>>instance basis and when you want to define a new configuration for with
>>those values as defaults. There's no right solution to that but I think
>>the type of installation plays into it:
>>* for a desktop development environment or single server installation
>> then you are better just overriding properties as needed
>>* for a clustered environment or large scale deployment then you are
>> better defining reusable bundles that can be easily moved where/when
>> they are required
>>
>>As Geronimo starts being considered for larger installations let's not
>>forget what the original config system was designed to do.
>>
>>--
>>Jeremy
>>
RE: GBeans: Saving Changes
Posted by Jeff Genender <jg...@savoirtech.com>.
> -----Original Message-----
> From: Aaron Mulder [mailto:ammulder@alumni.princeton.edu]
> Sent: Monday, July 25, 2005 6:12 PM
> To: dev@geronimo.apache.org
> Subject: Re: GBeans: Saving Changes
>
> As far as the Tomcat/Jetty thing goes, that will be
> interesting to explore as we think over how we should deal
> with interfaces in "some future release". I mean, I think
> our dependencies should ideally be expressed as "I require a
> servlet 2.4-compatible web container" not "I require the
> configuration named o/a/g/Server". Though to Jeremy's point,
> I can also see that if you get everything working "just so"
> with Jetty version X, you may not be all that eager to have
> your production team deploy it onto Tomcat instead just
> because that's a compatible interface.
We can make a compatible interface to a certain degree, but after that we
have to deal with the capabilities of each one. I personally wanted to see
Tomcat in Geronimo because I have a boat load of code that is Tomcat
specific...i.e. Valves and Realms. I could use Jetty for this, but I would
have to rework the code and get it into a Jetty equivalent of a Valve (is
there such an animal?). Given that a majority of the user base (outside of
Geronimo) out there uses Tomcat for a servlet container, we have to be
careful to allow them the option to use their applications on Geronimo w/o
the need to port. For a majority of the web applications, they should work
for both Jetty and Tomcat...no changes needed...pick your poison for a
container, add water, and stir. But for those who have invested time,
money, and energy on a Tomcat technology, we want it to be as simple as
possible to move over to G. This is especially true if we wish to make
porting tools from other app servers.
Both Tomcat and Jetty are awesome containers. I would like to see them both
embraced and allow the user to configure them as they need based on their
comfort level with the technology and any legacy code they are working with.
> I guess we need to put some more thought into exactly what
> use cases we're trying to support.
>
> Aaron
>
> On Mon, 25 Jul 2005, Dain Sundstrom wrote:
>
> > I have been thinking about this issue for months now and
> haven't come
> > to any good solutions. I think it would be cool to have imutable
> > configuration, but just think it is practical at this point. The
> > console and the tomcat/jetty selection issues really show off where
> > our current design falls short. Anyway, I haven't come up with
> > anything to solve the overall problem, but I think allowing
> GBeans to
> > be added and removed from a configuration is better then
> what we have
> > today, so I'm +1 for it.
> >
> > If someone has a better idea we can add in short term 1.x
> timeframe,
> > please speak up. Otherwise, I say make configuration
> mutable and we
> > can make them immutable in 2.x when something better comes along.
> >
> > -dain
> >
> > On Jul 25, 2005, at 4:56 PM, Aaron Mulder wrote:
> >
> > > For my part, I'm not convinced that it makes sense for
> > > configurations to be immutable. I think the
> export/import feature
> > > would be nice -- "I finally got my web container configured 'just
> > > right', now let me export it and load it into my cluster of 30
> > > boxes". I wouldn't even mind giving each configuration a unique
> > > hash or something such that we could eventually down the
> road add a
> > > feature where you export two related configurations, and
> one refers
> > > to that specific build of the other. Or even having an immutable
> > > flag on a configuration such that once you've marked one as
> > > immutable it refuses to change in the future.
> > >
> > > But to tell me that properties of a configuration
> shouldn't ever
> > > be changed, or that GBeans shouldn't be added or removed
> at runtime
> > > and we should create new child configurations instead...
> unless I'm
> > > misunderstanding you, that just doesn't work for me. I can't
> > > imagine someone customizing their web container and then
> after a few
> > > revs they try to load or unload or export it and discover
> that they
> > > now have configurations "Server", "Server HTTP v1..v5"
> "Server HTTPS
> > > v1..v3"
> > > "Server AJP v1 & v2" "Server Keystore v1..v4" "Server
> accept thread
> > > pool v1" "Server JSP Compiler v1..v3" "Server request log
> v1..v5",
> > > and so on.
> > > Much better IMHO to let them alter the "Server" configuration to
> > > their heart's content, then let them export it or flag it
> as locked
> > > if they want to preserve a snapshot of that state.
> > >
> > > Thanks,
> > > Aaron
> > >
> > > On Mon, 25 Jul 2005, Jeremy Boynes wrote:
> > >
> > >> Configuration bundles are meant to be immutable so you
> shouldn't be
> > >> adding things to them at runtime. Think of them as being
> similar to
> > >> library jars or other maven artifacts - things would get very
> > >> confusing if you started adding classes into them as part of a
> > >> build. This allows the configuration to be identified by
> its ID in
> > >> the same way the artifact id identifies a dependency to maven.
> > >>
> > >> Configuration bundles have attributes (currently modeled by
> > >> exposing the GBeans they contain which is problematic) which
> > >> pertain to the location in which they are being used.
> The *default*
> > >> values for those attributes are contained inside the bundle; the
> > >> instance value is set by the environment.
> > >>
> > >> There are some implementation issues in Geronimo today
> (short cuts
> > >> taken for expediency) which obscure some of the
> subtleties of this
> > >> model. Some of these relate to classloading (the issues on the
> > >> packaging thread), others relate to GBean persistence.
> > >>
> > >> I'll give a couple of examples which I hope highlight a
> couple of
> > >> the issues.
> > >>
> > >> The first anti-pattern is that configuration ids are not
> unique -
> > >> we reuse them for different configurations. For example,
> although
> > >> Tomcat and Jetty based servers are quite different we
> use the same
> > >> "unique" id
> > >> (org/apache/geronimo/Server) for both. We also reuse ids across
> > >> versions so it is impossible to tell if an application deployed
> > >> against org/apache/geronimo/Server was built using M1, M2, M3 or
> > >> HEAD. It is like only ever compiling against SNAPSHOT
> dependencies.
> > >>
> > >> Secondly, if configurations are immutable then you should not be
> > >> able to add GBeans to them at runtime (that would be mutating
> > >> them). So how do you add a network connector? The
> simplest model is
> > >> to separate the web container from its connectors and
> build them as
> > >> separate bundles (one for the container, one for each of the
> > >> connectors); if you want to add a new connector you add a new
> > >> instance of e.g. the HTTPS bundle.
> > >>
> > >> Finally, there is the issue of instance properties -
> things in the
> > >> environment of where a configuration is being used that need to
> > >> override the default properties that is has. For example, the
> > >> default for the HTTP connector bundle might be to listen on port
> > >> 8080 but on this server here it needs to be changed to be 8888.
> > >> Right now we do this by mutating the configuration
> installed in the
> > >> store which is problematic.
> > >> Instead
> > >> it would be better to associate the state with the runtime and,
> > >> after the bundle was loaded but before it was started,
> inject those
> > >> local values into it.
> > >>
> > >> There's a fine line between when you want to override
> values on a
> > >> per instance basis and when you want to define a new
> configuration
> > >> for with those values as defaults. There's no right solution to
> > >> that but I think the type of installation plays into it:
> > >> * for a desktop development environment or single server
> installation
> > >> then you are better just overriding properties as needed
> > >> * for a clustered environment or large scale deployment
> then you are
> > >> better defining reusable bundles that can be easily
> moved where/
> > >> when
> > >> they are required
> > >>
> > >> As Geronimo starts being considered for larger
> installations let's
> > >> not forget what the original config system was designed to do.
> > >>
> > >> --
> > >> Jeremy
> > >>
> > >
> >
> >
>
Re: GBeans: Saving Changes
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
As far as the Tomcat/Jetty thing goes, that will be interesting to
explore as we think over how we should deal with interfaces in "some
future release". I mean, I think our dependencies should ideally be
expressed as "I require a servlet 2.4-compatible web container" not "I
require the configuration named o/a/g/Server". Though to Jeremy's point,
I can also see that if you get everything working "just so" with Jetty
version X, you may not be all that eager to have your production team
deploy it onto Tomcat instead just because that's a compatible interface.
I guess we need to put some more thought into exactly what use cases we're
trying to support.
Aaron
On Mon, 25 Jul 2005, Dain Sundstrom wrote:
> I have been thinking about this issue for months now and haven't come
> to any good solutions. I think it would be cool to have imutable
> configuration, but just think it is practical at this point. The
> console and the tomcat/jetty selection issues really show off where
> our current design falls short. Anyway, I haven't come up with
> anything to solve the overall problem, but I think allowing GBeans to
> be added and removed from a configuration is better then what we have
> today, so I'm +1 for it.
>
> If someone has a better idea we can add in short term 1.x timeframe,
> please speak up. Otherwise, I say make configuration mutable and we
> can make them immutable in 2.x when something better comes along.
>
> -dain
>
> On Jul 25, 2005, at 4:56 PM, Aaron Mulder wrote:
>
> > For my part, I'm not convinced that it makes sense for
> > configurations to be immutable. I think the export/import feature
> > would
> > be nice -- "I finally got my web container configured 'just right',
> > now
> > let me export it and load it into my cluster of 30 boxes". I wouldn't
> > even mind giving each configuration a unique hash or something such
> > that
> > we could eventually down the road add a feature where you export two
> > related configurations, and one refers to that specific build of the
> > other. Or even having an immutable flag on a configuration such
> > that once
> > you've marked one as immutable it refuses to change in the future.
> >
> > But to tell me that properties of a configuration shouldn't ever
> > be changed, or that GBeans shouldn't be added or removed at runtime
> > and we
> > should create new child configurations instead... unless I'm
> > misunderstanding you, that just doesn't work for me. I can't imagine
> > someone customizing their web container and then after a few revs
> > they try
> > to load or unload or export it and discover that they now have
> > configurations "Server", "Server HTTP v1..v5" "Server HTTPS v1..v3"
> > "Server AJP v1 & v2" "Server Keystore v1..v4" "Server accept thread
> > pool
> > v1" "Server JSP Compiler v1..v3" "Server request log v1..v5", and
> > so on.
> > Much better IMHO to let them alter the "Server" configuration to their
> > heart's content, then let them export it or flag it as locked if
> > they want
> > to preserve a snapshot of that state.
> >
> > Thanks,
> > Aaron
> >
> > On Mon, 25 Jul 2005, Jeremy Boynes wrote:
> >
> >> Configuration bundles are meant to be immutable so you shouldn't be
> >> adding things to them at runtime. Think of them as being similar to
> >> library jars or other maven artifacts - things would get very
> >> confusing
> >> if you started adding classes into them as part of a build. This
> >> allows
> >> the configuration to be identified by its ID in the same way the
> >> artifact id identifies a dependency to maven.
> >>
> >> Configuration bundles have attributes (currently modeled by
> >> exposing the
> >> GBeans they contain which is problematic) which pertain to the
> >> location
> >> in which they are being used. The *default* values for those
> >> attributes
> >> are contained inside the bundle; the instance value is set by the
> >> environment.
> >>
> >> There are some implementation issues in Geronimo today (short cuts
> >> taken
> >> for expediency) which obscure some of the subtleties of this
> >> model. Some
> >> of these relate to classloading (the issues on the packaging thread),
> >> others relate to GBean persistence.
> >>
> >> I'll give a couple of examples which I hope highlight a couple of the
> >> issues.
> >>
> >> The first anti-pattern is that configuration ids are not unique - we
> >> reuse them for different configurations. For example, although Tomcat
> >> and Jetty based servers are quite different we use the same
> >> "unique" id
> >> (org/apache/geronimo/Server) for both. We also reuse ids across
> >> versions
> >> so it is impossible to tell if an application deployed against
> >> org/apache/geronimo/Server was built using M1, M2, M3 or HEAD. It is
> >> like only ever compiling against SNAPSHOT dependencies.
> >>
> >> Secondly, if configurations are immutable then you should not be
> >> able to
> >> add GBeans to them at runtime (that would be mutating them). So
> >> how do
> >> you add a network connector? The simplest model is to separate the
> >> web
> >> container from its connectors and build them as separate bundles (one
> >> for the container, one for each of the connectors); if you want to
> >> add a
> >> new connector you add a new instance of e.g. the HTTPS bundle.
> >>
> >> Finally, there is the issue of instance properties - things in the
> >> environment of where a configuration is being used that need to
> >> override
> >> the default properties that is has. For example, the default for the
> >> HTTP connector bundle might be to listen on port 8080 but on this
> >> server
> >> here it needs to be changed to be 8888. Right now we do this by
> >> mutating
> >> the configuration installed in the store which is problematic.
> >> Instead
> >> it would be better to associate the state with the runtime and, after
> >> the bundle was loaded but before it was started, inject those local
> >> values into it.
> >>
> >> There's a fine line between when you want to override values on a per
> >> instance basis and when you want to define a new configuration for
> >> with
> >> those values as defaults. There's no right solution to that but I
> >> think
> >> the type of installation plays into it:
> >> * for a desktop development environment or single server installation
> >> then you are better just overriding properties as needed
> >> * for a clustered environment or large scale deployment then you are
> >> better defining reusable bundles that can be easily moved where/
> >> when
> >> they are required
> >>
> >> As Geronimo starts being considered for larger installations let's
> >> not
> >> forget what the original config system was designed to do.
> >>
> >> --
> >> Jeremy
> >>
> >
>
>
Re: GBeans: Saving Changes
Posted by Dain Sundstrom <da...@iq80.com>.
I have been thinking about this issue for months now and haven't come
to any good solutions. I think it would be cool to have imutable
configuration, but just think it is practical at this point. The
console and the tomcat/jetty selection issues really show off where
our current design falls short. Anyway, I haven't come up with
anything to solve the overall problem, but I think allowing GBeans to
be added and removed from a configuration is better then what we have
today, so I'm +1 for it.
If someone has a better idea we can add in short term 1.x timeframe,
please speak up. Otherwise, I say make configuration mutable and we
can make them immutable in 2.x when something better comes along.
-dain
On Jul 25, 2005, at 4:56 PM, Aaron Mulder wrote:
> For my part, I'm not convinced that it makes sense for
> configurations to be immutable. I think the export/import feature
> would
> be nice -- "I finally got my web container configured 'just right',
> now
> let me export it and load it into my cluster of 30 boxes". I wouldn't
> even mind giving each configuration a unique hash or something such
> that
> we could eventually down the road add a feature where you export two
> related configurations, and one refers to that specific build of the
> other. Or even having an immutable flag on a configuration such
> that once
> you've marked one as immutable it refuses to change in the future.
>
> But to tell me that properties of a configuration shouldn't ever
> be changed, or that GBeans shouldn't be added or removed at runtime
> and we
> should create new child configurations instead... unless I'm
> misunderstanding you, that just doesn't work for me. I can't imagine
> someone customizing their web container and then after a few revs
> they try
> to load or unload or export it and discover that they now have
> configurations "Server", "Server HTTP v1..v5" "Server HTTPS v1..v3"
> "Server AJP v1 & v2" "Server Keystore v1..v4" "Server accept thread
> pool
> v1" "Server JSP Compiler v1..v3" "Server request log v1..v5", and
> so on.
> Much better IMHO to let them alter the "Server" configuration to their
> heart's content, then let them export it or flag it as locked if
> they want
> to preserve a snapshot of that state.
>
> Thanks,
> Aaron
>
> On Mon, 25 Jul 2005, Jeremy Boynes wrote:
>
>> Configuration bundles are meant to be immutable so you shouldn't be
>> adding things to them at runtime. Think of them as being similar to
>> library jars or other maven artifacts - things would get very
>> confusing
>> if you started adding classes into them as part of a build. This
>> allows
>> the configuration to be identified by its ID in the same way the
>> artifact id identifies a dependency to maven.
>>
>> Configuration bundles have attributes (currently modeled by
>> exposing the
>> GBeans they contain which is problematic) which pertain to the
>> location
>> in which they are being used. The *default* values for those
>> attributes
>> are contained inside the bundle; the instance value is set by the
>> environment.
>>
>> There are some implementation issues in Geronimo today (short cuts
>> taken
>> for expediency) which obscure some of the subtleties of this
>> model. Some
>> of these relate to classloading (the issues on the packaging thread),
>> others relate to GBean persistence.
>>
>> I'll give a couple of examples which I hope highlight a couple of the
>> issues.
>>
>> The first anti-pattern is that configuration ids are not unique - we
>> reuse them for different configurations. For example, although Tomcat
>> and Jetty based servers are quite different we use the same
>> "unique" id
>> (org/apache/geronimo/Server) for both. We also reuse ids across
>> versions
>> so it is impossible to tell if an application deployed against
>> org/apache/geronimo/Server was built using M1, M2, M3 or HEAD. It is
>> like only ever compiling against SNAPSHOT dependencies.
>>
>> Secondly, if configurations are immutable then you should not be
>> able to
>> add GBeans to them at runtime (that would be mutating them). So
>> how do
>> you add a network connector? The simplest model is to separate the
>> web
>> container from its connectors and build them as separate bundles (one
>> for the container, one for each of the connectors); if you want to
>> add a
>> new connector you add a new instance of e.g. the HTTPS bundle.
>>
>> Finally, there is the issue of instance properties - things in the
>> environment of where a configuration is being used that need to
>> override
>> the default properties that is has. For example, the default for the
>> HTTP connector bundle might be to listen on port 8080 but on this
>> server
>> here it needs to be changed to be 8888. Right now we do this by
>> mutating
>> the configuration installed in the store which is problematic.
>> Instead
>> it would be better to associate the state with the runtime and, after
>> the bundle was loaded but before it was started, inject those local
>> values into it.
>>
>> There's a fine line between when you want to override values on a per
>> instance basis and when you want to define a new configuration for
>> with
>> those values as defaults. There's no right solution to that but I
>> think
>> the type of installation plays into it:
>> * for a desktop development environment or single server installation
>> then you are better just overriding properties as needed
>> * for a clustered environment or large scale deployment then you are
>> better defining reusable bundles that can be easily moved where/
>> when
>> they are required
>>
>> As Geronimo starts being considered for larger installations let's
>> not
>> forget what the original config system was designed to do.
>>
>> --
>> Jeremy
>>
>
Re: GBeans: Saving Changes
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
For my part, I'm not convinced that it makes sense for
configurations to be immutable. I think the export/import feature would
be nice -- "I finally got my web container configured 'just right', now
let me export it and load it into my cluster of 30 boxes". I wouldn't
even mind giving each configuration a unique hash or something such that
we could eventually down the road add a feature where you export two
related configurations, and one refers to that specific build of the
other. Or even having an immutable flag on a configuration such that once
you've marked one as immutable it refuses to change in the future.
But to tell me that properties of a configuration shouldn't ever
be changed, or that GBeans shouldn't be added or removed at runtime and we
should create new child configurations instead... unless I'm
misunderstanding you, that just doesn't work for me. I can't imagine
someone customizing their web container and then after a few revs they try
to load or unload or export it and discover that they now have
configurations "Server", "Server HTTP v1..v5" "Server HTTPS v1..v3"
"Server AJP v1 & v2" "Server Keystore v1..v4" "Server accept thread pool
v1" "Server JSP Compiler v1..v3" "Server request log v1..v5", and so on.
Much better IMHO to let them alter the "Server" configuration to their
heart's content, then let them export it or flag it as locked if they want
to preserve a snapshot of that state.
Thanks,
Aaron
On Mon, 25 Jul 2005, Jeremy Boynes wrote:
> Configuration bundles are meant to be immutable so you shouldn't be
> adding things to them at runtime. Think of them as being similar to
> library jars or other maven artifacts - things would get very confusing
> if you started adding classes into them as part of a build. This allows
> the configuration to be identified by its ID in the same way the
> artifact id identifies a dependency to maven.
>
> Configuration bundles have attributes (currently modeled by exposing the
> GBeans they contain which is problematic) which pertain to the location
> in which they are being used. The *default* values for those attributes
> are contained inside the bundle; the instance value is set by the
> environment.
>
> There are some implementation issues in Geronimo today (short cuts taken
> for expediency) which obscure some of the subtleties of this model. Some
> of these relate to classloading (the issues on the packaging thread),
> others relate to GBean persistence.
>
> I'll give a couple of examples which I hope highlight a couple of the
> issues.
>
> The first anti-pattern is that configuration ids are not unique - we
> reuse them for different configurations. For example, although Tomcat
> and Jetty based servers are quite different we use the same "unique" id
> (org/apache/geronimo/Server) for both. We also reuse ids across versions
> so it is impossible to tell if an application deployed against
> org/apache/geronimo/Server was built using M1, M2, M3 or HEAD. It is
> like only ever compiling against SNAPSHOT dependencies.
>
> Secondly, if configurations are immutable then you should not be able to
> add GBeans to them at runtime (that would be mutating them). So how do
> you add a network connector? The simplest model is to separate the web
> container from its connectors and build them as separate bundles (one
> for the container, one for each of the connectors); if you want to add a
> new connector you add a new instance of e.g. the HTTPS bundle.
>
> Finally, there is the issue of instance properties - things in the
> environment of where a configuration is being used that need to override
> the default properties that is has. For example, the default for the
> HTTP connector bundle might be to listen on port 8080 but on this server
> here it needs to be changed to be 8888. Right now we do this by mutating
> the configuration installed in the store which is problematic. Instead
> it would be better to associate the state with the runtime and, after
> the bundle was loaded but before it was started, inject those local
> values into it.
>
> There's a fine line between when you want to override values on a per
> instance basis and when you want to define a new configuration for with
> those values as defaults. There's no right solution to that but I think
> the type of installation plays into it:
> * for a desktop development environment or single server installation
> then you are better just overriding properties as needed
> * for a clustered environment or large scale deployment then you are
> better defining reusable bundles that can be easily moved where/when
> they are required
>
> As Geronimo starts being considered for larger installations let's not
> forget what the original config system was designed to do.
>
> --
> Jeremy
>
Re: GBeans: Saving Changes
Posted by Jeremy Boynes <jb...@apache.org>.
Aaron Mulder wrote:
>
> I thought we had a mechanism in place to store the state of a
> GBean after a change at runtime -- which I assume would include storing
> new values for persistent attributes as well as storing the data for new
> GBeans added to a Configuration at runtime (for example, if you add a new
> network connector to the web container).
>
Configuration bundles are meant to be immutable so you shouldn't be
adding things to them at runtime. Think of them as being similar to
library jars or other maven artifacts - things would get very confusing
if you started adding classes into them as part of a build. This allows
the configuration to be identified by its ID in the same way the
artifact id identifies a dependency to maven.
Configuration bundles have attributes (currently modeled by exposing the
GBeans they contain which is problematic) which pertain to the location
in which they are being used. The *default* values for those attributes
are contained inside the bundle; the instance value is set by the
environment.
There are some implementation issues in Geronimo today (short cuts taken
for expediency) which obscure some of the subtleties of this model. Some
of these relate to classloading (the issues on the packaging thread),
others relate to GBean persistence.
I'll give a couple of examples which I hope highlight a couple of the
issues.
The first anti-pattern is that configuration ids are not unique - we
reuse them for different configurations. For example, although Tomcat
and Jetty based servers are quite different we use the same "unique" id
(org/apache/geronimo/Server) for both. We also reuse ids across versions
so it is impossible to tell if an application deployed against
org/apache/geronimo/Server was built using M1, M2, M3 or HEAD. It is
like only ever compiling against SNAPSHOT dependencies.
Secondly, if configurations are immutable then you should not be able to
add GBeans to them at runtime (that would be mutating them). So how do
you add a network connector? The simplest model is to separate the web
container from its connectors and build them as separate bundles (one
for the container, one for each of the connectors); if you want to add a
new connector you add a new instance of e.g. the HTTPS bundle.
Finally, there is the issue of instance properties - things in the
environment of where a configuration is being used that need to override
the default properties that is has. For example, the default for the
HTTP connector bundle might be to listen on port 8080 but on this server
here it needs to be changed to be 8888. Right now we do this by mutating
the configuration installed in the store which is problematic. Instead
it would be better to associate the state with the runtime and, after
the bundle was loaded but before it was started, inject those local
values into it.
There's a fine line between when you want to override values on a per
instance basis and when you want to define a new configuration for with
those values as defaults. There's no right solution to that but I think
the type of installation plays into it:
* for a desktop development environment or single server installation
then you are better just overriding properties as needed
* for a clustered environment or large scale deployment then you are
better defining reusable bundles that can be easily moved where/when
they are required
As Geronimo starts being considered for larger installations let's not
forget what the original config system was designed to do.
--
Jeremy
Re: GBeans: Saving Changes
Posted by Jeremy Boynes <jb...@apache.org>.
Starting a new sub-thread...
One of the examples we use all the time when talking about bundles is
that of a web connector. However, this is bad example to take because it
is too simple to highlight some of the issues.
* it only contains one GBean
* that bean has a couple of fairly simple properties
* nothing references that GBean so it has little impact on other bundles
I think the last issue there is systemic to this kind of component: it
is an edge component that takes something from the outside world (i.e.
an inbound socket connection) and hands it off to other services inside
the server. So in Jetty, the HTTPConnector references the JettyContainer
but not the other way around. The same can be said for other edge
connectors such as the EJB Daemon, the ORB, the JMX Connector ...
The first two issues also cloud things because they simplify the
connector to a degenerate case. Things would be more interesting if we
considered a HTTPS connector that split the functionality into three
components: a socket listener, a thread pool and an SSL keystore.
Then, when the user wanted to add an HTTPS port we would need to create
three GBeans and wire them together properly. Bear in mind that
depending on the runtime, the user may want the thread pool and SSL
keystore to be bundled with the connector or may want to use ones from
other bundles.
Other things that may seem quite simple to the user may require several
GBeans be constructed - this is what we do when we package an
application, we create a new bundle with a bucket load of GBeans in it
(e.g. servlet holders, ejb containers, admin objects, ...). Simplicity
comes from not exposing all this detail to the user.
--
Jeremy
Re: GBeans: Saving Changes
Posted by Dain Sundstrom <da...@iq80.com>.
There is a mechanism to save out he current state of GBeans on a
clean shutdown of the configuration (i.e., when you stop the
configuration). If it is not running, then there is a bug. The code
is in org.apache.geronimo.kernel.config.Configuration.doStop();
-dain
On Jul 24, 2005, at 7:43 PM, Aaron Mulder wrote:
> So the console can write to persistent attributes of GBeans -- and
> I think they're taking effect (you can log out and log back in and
> see the
> changed value, at any rate). However, if you restart the server, the
> values reset to their initially generated values.
>
> I thought we had a mechanism in place to store the state of a
> GBean after a change at runtime -- which I assume would include
> storing
> new values for persistent attributes as well as storing the data
> for new
> GBeans added to a Configuration at runtime (for example, if you add
> a new
> network connector to the web container).
>
> I'm not sure whether this was never implemented, was implemented
> but is not working, is working but something needs to be called
> manually
> to execute the save, or is totally working and I'm misinterpreting
> what
> I'm seeing in the console.
>
> Any thoughts?
>
> Thanks,
> Aaron
>