geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject What's a bundle?, was: GBeans: Saving Changes
Date Wed, 27 Jul 2005 15:28:13 GMT
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

Mime
View raw message