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
[EMAIL PROTECTED]
"He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
