What's a bundle?, was: GBeans: Saving Changes

[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: What's a bundle?, was: GBeans: Saving Changes

[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