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
