Hi,

I'm ignant so in lay terms what is it that we have here? A generic server side platform? An IoC container?

Could someone elaborate a lil bit more on the evolution that is taking place or point me to any documentation. It's very interesting and I'm curious about the big picture.

Alex

David Blevins wrote:

Woohooooooo!

-David

On Mon, Dec 06, 2004 at 10:53:59PM -0800, Dain Sundstrom wrote:


Last night I committed the changes to the Kernel to remove the dependencies on JMX. The Kernel still uses ObjectName and MalformedObjectNameException, and those will go when we add GBeanName. My change notes follow:

Kernel is not totally decoupled from JMX. By default the kernel will no longer boot an MBeanServer. The only place we boot the MBean server is when we are booting a full blown long running Geronimo server.

Introduced GBeanRegistry which manages the map ObjectName to GBeanInstance.

Added BasicGBeanRegistry which manages the map with no dependency on JMX.

Added JMXGBeanRegistry which creates an MBeanServer on startup. It mounts a o.a.g.kernel.jmx.GBeanMBean into an MBeanServer for each GBeanInstance registered. The a o.a.g.kernel.jmx.GBeanMBean does not interact directly with GBeanInstances, instead it simply redirects all calls to a GBean. GBeanMBean in the o.a.g.gbean.jmx package is just a proxy for a GBeanData, and should be removed soon.

Added KernelDelegate which replaces the MBeanServerFactory use on the client side to create a proxy to the server side geronimo kernel.

Added MBeanServerDelegate which is used to provide apis such as the JSR 88 MEJB which needs a something that implements MBeanServer. The MBeanServerDelegate only implements the operations of the MBeanServer that easily map to Kernel. All unimplemented methods throw a SecurityException.

Moved Lifecycle* classes to o.a.g.kernel.lifecycle

-dain

--
Dain Sundstrom
Chief Architect
Gluecode Software
310.536.8355, ext. 26








Reply via email to