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
