Re: [Springframework-developer] Spring/Geronimo

[<jas...@ma...>]

On 9 Jul 2004, at 14:30, Keith Donald wrote:
> James,
>
> When you get some time, if you could elaborate more on the JMX support 
> in
> Geronimo, and how you see Spring beans being recognized as 
> 'manageable' (via
> configuration metadata I assume?) so they can be appropriately 
> registered in
> an MBeanServer running with in the app server, that would be 
> fantastic...
> Some questions I had:
>
> - Are you planning to support Standard (specifically StandardMBean in 
> JMX
> 1.2), Model, and/or Dynamic MBeans?

Probably Dynamic MBeans but I'm sure we can experiment & support 
pluggable strategies for this stuff


> - If I were to instantiate a POJO in a spring context and associate
> management metadata with it: e.g. metadata that could consist of the 
> class
> of a management interface (for standard mbeans), or a model mbean 
> descriptor
> key (that could be used to lookup mbean metadata from some other 
> source,
> used to instantiate a generic model mbean proxy), along with the JMX 
> object
> name, how do you see that whole process working?  Would we be able to 
> say
> that a particular bean is a "ServiceMBean" for example, were 
> "ServiceMBean"
> is a standard management interface defined as part of the standard
> JSR-77/CIM management hierarchy with well-known keys, attributes and
> operations?  Then you'd be able to query on all beans that were 
> "Services"
> from the MBeanServer?

Right now the code I hacked into Geronimo uses an ObjectName for the 
entire Spring container, then all the names in the spring POJOs are 
used with this ObjectName to make new distinct names - i.e. so they can 
inherit whatever ObjectName domain and so forth you wish to deploy them 
in.

So absolutely you'll be able to do JMX queries for these POJOs - or 
support multiple spring deployments in different domains etc.

How the POJOs are mapped to MBeans is pluggable & we'll probably use 
various strategies but making a dynamic MBean facade is probably the 
first step.

>
> - How will the lifecycle of JMX-managed bean configured in a spring 
> context
> be defined?  For example, let's say I implement a "Service" management
> interface, which extends InitializingBean, adding in support for 
> start() and
> stop() operations.  Will the app server be responsible for registering 
> and
> starting the service on startup, and stopping and de-regisering it on
> shutdown?

Yes. Its not there yet but its our intention to bind all the Spring 
lifecycle methods to the Geronimo GBean (JSR 77/88) lifecycles so all 
this stuff works properly. Its not there yet but its where we're hoping 
to be. JSR 77/88 is hierarchical, so we expect to be able to hotswap 
each spring deployment within the app server while keeping other things 
running.


> - Will relations be supported; e.g I have two services that depend on 
> each
> other, and I want to capture that dependency as a relation between the 
> two
> management clients can then use to reason on.  Or possibly the app 
> server
> itself; for example, for triggering a stop of all dependents services 
> during
> shutdown in the correct order.

I certainly hope so; I'm not yet sure how to extract the relationship 
stuff from Spring so that we can expose it to Geronimo - but certainly 
Geronimo today supports a tree based GBean management stack along the 
JSR 77/88 model with dependencies & references and so forth such that 
complex graphs of components can be started & stopped (& hotswapped) 
cleanly from any point in the graph.

We just need to ensure that we cleanly integrate these features of 
Geronimo to Spring's way of doing things. Shouldn't be that hard to do.

James
-------
http://radio.weblogs.com/0112098/