geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Management API
Date Sun, 17 Jul 2005 01:26:20 GMT
I think it might be possible to divide this proposal into several 
pieces, and have different opinions about different aspects of them.

1).  supply "management interfaces" for our important gbeans.  these 
are java interfaces that are exposed by the gbean through its gbean 
info.  These would be used by the web console and other tools to avoid 
the invoke(opname, paramlist) style.  We'd find some way of turning 
these into gbean proxies.

I think this is a great idea, and that it has to be done with 
considerable care.  One of the major projects I think we need to start 
is deciding and documenting just what parts of geronimo we intend to 
support for more than 5 minutes :-).  I think interfaces like this form 
an ideal way of documenting a large fraction of the stuff we would be 
willing to keep stable.

On the other hand, one of the features of jsr-77 is that it is 
accessible to just about anything, and the entire interface involves 
only very simple objects.  I think we have to be really careful to 
avoid introducing lots of complex objects into these interfaces.  This 
brings us to...

2).  navigation and getting instances of these proxies.  jsr-77 doesn't 
give you instances, just names, and you navigate using names.  As soon 
as you translate list of names >> list of objects you start getting 
problems.  First of all, you've now introduced complex objects into 
your interface.  Second, it's unclear how you could get back anything 
other than a list of "lowest common denominator" proxies that would be 
useless.  Third, these interfaces no longer actually reflect jsr-77.

One way to sidestep these issues would be to provide a method for 
turning a name into a proxy.  I'm not sure how we would figure out what 
the proxy interface was, since the client probably wouldn't know 
exactly what to expect.  Maybe we could add something to the gbean 
info??? a defaultInterface attribute??????

Also, it's important to me that the system be extensible, so that as 
people write new gbeans they can be integrated rather easily. This 
leads to

3) package structure.  I think the interfaces should go with the gbeans 
that expose them.  First of all, this keeps related bits together.  
Second of all, it reduces leakage between unrelated modules.  For 
instance, suppose you deploy just web support, without ejb or 
connector.   Why should the ejb and resource interfaces even be in your 
classpath?

So, that's my first impression.  As I started with, I think making 
interfaces for our important gbeans to implement is a great idea for 
quite a few reasons, and also I think it would provide most of the 
value in this proposal.

Thanks
david jencks

On Jul 16, 2005, at 5:33 PM, Aaron Mulder wrote:

> 	So after looking at the web console code and the JSR-77 spec, I
> got the idea in my head that we could use a management API made up of
> actual classes and interfaces, instead of object names and attribute
> names.  This is not meant to replace JSR-77 as a portable interface 
> across
> servers and protocols, and not meant to replace GBeans and the Kernel 
> as a
> method to inspect and tweak every last property of any object 
> available in
> any Geronimo configuration.
>
> 	It is meant to make it easier to develop management tools (such as
> the web console) against the common case of the Geronimo J2EE server.
>
> 	Anyway, since I've gotten trouble over long e-mails before, I
> wrote up what I have in mind and why I think it's a good idea (compared
> to the management options we have now) on the Wiki:
>
> http://wiki.apache.org/geronimo/Geronimo_Management_API
>
> 	Please take a look and let me know what you think.  I think this
> could really jump start things like the web console, by letting those
> efforts focus on the UI not on how to correctly talk to the underlying
> server components.
>
> Thanks,
> 	Aaron
>


Mime
View raw message