geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <>
Subject Re: Management API
Date Sun, 17 Jul 2005 03:31:37 GMT
On Sat, 16 Jul 2005, David Jencks wrote:
> 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.

	Okay, I'm on board with this.

> 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.

	I don't think "lowest common denominator" is at all useless.  I 
have to use Tomcat and Jetty as the only real concrete example of this.  
But what I think you're going to want to do 99% of the time with these is 
inspect or change the port configuration, and both have similar connectors 
with similar port information.  Each has a SSL connector with pretty much 
the same SSL settings.  It may be that Jetty offers some monitorable 
statistics that Tomcat does not, or vice versa, and you'd need to escape 
the interfaces to get to that.  But if the interface supplies you with the 
ObjectName, or you used the ObjectName to get the interface, you can 
trivially escape if you know what GBean properties you're looking for.  
And if you don't know that, what business do you have trying to escape the 
interfaces?  :)  In the end, if we put together a management console that 
thoroughly covers the lowest commond denominator in every area, that would 
be absolutely fantastic, and then we can go on to worry about how to best 
manage the container-specific extensions.

	As for JSR-77, I'd like to create a core set of interfaces that
contain nothing but the JSR-77 features (including child getters that
return an array of ObjectName strings).  The beginnings of this is present 
already in the j2ee module.

> 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??????

	If we define all the "plain" JSR-77 interfaces, we could inspect
the GBean for interfaces that extend that.  It's cheesy, but workable.  
More on interface extension later.

> 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?

	I think we should define all the JSR-77 interfaces in  We currently have 5 or 6 there, and I don't see 
any reason not to add the rest.  But as the JSR-77 interfaces are pretty 
limited, it seems sensible to me to define extensions to them.  We already 
do that too -- versus

	My preferences would be for the "first round" of extension
interfaces to be centralized too.  I'd like all connector containers or
web containers or EJB containers to use standard properties and naming, if
we get to the point where we have multiple options of each.  I don't think
it's a benefit to have different GBeans wrapping different implementations
of the same feature use different property names for the same thing.  And
the extra 10 interfaces on the class path doesn't bother be in the

	But to go back to the practical for a moment, if we were going to
define a "web container" interface, where do we put it?  It doesn't make
sense to put it in Jetty or Tomcat.  Maybe in web-builder (the new common
web deployment plan module)?  But it's not a plan.  I'd still prefer to
put basic WebContainer and WebConnector interfaces in and then have separate TomcatWebContainer
and JettyWebContainer interfaces that extend the base and live with the
respective GBeans.  Does that sound reasonable?


> 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:
> >
> >
> >
> > 	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
> >

View raw message