geronimo-scm mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Geronimo Wiki] Update of "Geronimo Management API" by AaronMulder
Date Thu, 21 Jul 2005 22:36:03 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Geronimo Wiki" for change notification.

The following page has been changed by AaronMulder:

The comment on the change is:
Writeup on IRC conversation

- = Proposed Geronimo Management API =
+ = Geronimo Management API =
+ == Current Plans ==
+ Recall that to access an arbitrary GBean, you can call Geronimo methods like
+ Kernel.invoke(!ObjectName, "!MethodName"), you can call JSR-77 methods like
+ MEJB.invoke("!ObjectName", "!MethodName"), or you can create a proxy for the
+ GBean where the proxy implements some interface and under the covers all
+ calls to the proxy methods are converted into calls to the GBean.
+ Currently the web console uses the Kernel.invoke(!ObjectName, "!MethodName")
+ style to communicate with the running GBeans.
+ Dain, David J, and Aaron talked by IRC, and concluded that to improve the options
+ for writing management clients, we should:
+  1. Create interfaces for all important GBeans
+  2. Make GBeans implement their interfaces, and register the interfaces with their G!BeanInfo
+  3. Create an !ObjectName-to-proxy factory, where you pass it an !ObjectName and the interfaces
you're interested in seeing, and it returns a proxy that implements any of those that the
G!BeanInfo says that the GBean under that !ObjectName supports.
+  4. If we want to ease navigation between proxies (say, server to applications deployed
in the server, or application to individual modules within the application) then any logic
for that should be implemented in a helper class.
+  5. GBean framework plumbing supporting certain JSR-77 attributes should be removed, and
the individual GBeans should implement those attributes if they represent JSR-77 objects.
 This will be added to JIRA.
+ === In More Detail ===
+  1. GBean Interfaces -- right now, a GBean can just provide a bunch of attributes and operations
and add them individually to its G!BeanInfo (which effectively controls what management calls
are available).  We plan to add an interface for each GBean defining its management API, and
have the GBean add the whole interface to its GBeanInfo in one shot.  That would let you create
a proxy to the GBean based on that interface.  There may actually be an interface hierarchy,
such that common Tomcat/Jetty fucntions could be encapsulated in `WebContainer` and then there
could still be `JettyWebContainer` and `TomcatWebContainer` extending that.  We intend to
create interfaces representing most JSR-77 concepts, though there will be many interfaces
and GBeans beyond what JSR-77 alone offers.  Any GBeans that represent JSR-77 object must
inherit from `J2EEManagedObject` (the root JSR-77 interface), but other GBean interfaces do
not need to.
+  2. Each GBean will implement its management interface, if for no other reason than to prove
that it actually provides all the necessary methods.  As mentioned above, it should call G!BeanInfoFactory.addInterface(interface)
when constructing its G!BeanInfo.
+  3. Given an !ObjectName, the developer needs some way to create a working proxy from that.
 You can give the !ProxyManager an interface and have it create you a proxy, but you may not
know whether an !ObjectName for a web container represents a `JettyWebContainer` or a `TomcatWebContainer`,
for example.  We will create a factory where you can ask for a proxy implementing certain
mandatory and optional interfaces (in that example, `GenericWebContainer` might be mandatory
and `JettyWebContainer` and `TomcatWebContainer` optional).  It'll give you back a proxy implementing
the mandatory interface(s) and any of the optional interfaces that the underlying GBean actually
supports.  It'll figure this out by getting the G!BeanInfo for the GBean and inspecting its
list of interfaces and comparing that to the list of interfaces you provided.  The developer
will still need to cast, but they can do something like this:
+     {{{
+ WebContainer wc = (WebContainer)Factory.getProxy(objectName,
+                   WebContainer.class, new Class[]{
+                     JettyWebContainer.class, TomcatWebContainer.class});
+ if(wc instanceof TomcatWebContainer) {
+     // do Tomcat stuff
+ } else if(wc instanceof JettyWebContainer) {
+     // do Jetty stuff
+ } else {
+     // do totally generic stuff
+ }
+     }}}
+  4. I might provide a helper class with a method like:
+     {{{
+ public GeronimoApplication getApplications(J2EEServer server);
+     }}}   
+   Under the covers, this would use the factory from setp 3, but it would allow someone unfamiliar
with the classes and interfaces to navigate around without knowing exactly what interfaces
to pass to the factory and cast the result to.  In any case, this would be a helper class
that is (at least for now) outside the core management infrastructure.
+  5. Currently the "GBean framework" will respond to the methods defined in `J2EEManagedObject`
regardless of whether the underlying GBean implements those methods.  This is not actually
desirable.  We'd like to remove that logic from the "GBean framework" and require that GBeans
implement those methods if they should be available.  I'm not sure where the actual code for
that is yet.
+ All together these should make it more viable to write management code based on calling
into interfaces, instead of management code based on passing !ObjectNames and Strings and
casting every result.
+ == Original Proposal ==
  So this comes from looking at JSR-77 and the code that the web console uses to interact
with Geronimo.
@@ -37, +85 @@

  So the code above could be changed to use the ManagementEJB instead of kernel, and it would
be close to portable -- the missing link being that JSR-77 doesn't define {{{$getResource}}}
as a legitimate function of a `JCAManagedConnectionFactory` or `JDBCDataSource` (the closest
JSR-77 objects to the example above).
- == So what's the problem? ==
+ === So what's the problem? ===
  Well, at heart, I don't like code that looks like this:
@@ -56, +104 @@

   * Make it easy to navigate from X to Child-of-X (especially not "get names-of-children,
make cryptic call to get instances-of-children as Objects, then figure out what child types
should be and cast to real child types")
     * Related: Make it easy to learn the API by making it immediately obvious "if I have
a Foo, what child objects does Foo have, and what types do ''they'' have?"
- == So what's the solution? ==
+ === So what's the solution? ===
  I'm imagining an API like this:
@@ -157, +205 @@

  This would give you an entry into the domain and related objects, and also let you navigate
between objects without needing to manually do things based on the !ObjectNames that all the
JSR-77 classes return when you ask about their children.
- == How could this be implemented? ==
+ === How could this be implemented? ===
  We have GBeans that expose all the necessary properties and functions already.  The only
issue is providing an implementation of this API that accesses them.  In many cases, we might
supply interfaces that the GBeans could implement.  Still, here might be some glue code between
the interfaces defined above and the actual GBeans.
@@ -165, +213 @@

  Note that it is not my intention to start a "build the world" project to provide a totally
comprehensive management API for Geronimo.  Instead, I'd plan to start small, and grow it
as tools such as the web console expand into new areas.  "On demand" development of the management
API, I guess.
- == How would this be integrated into Geronimo? ==
+ === How would this be integrated into Geronimo? ===
  Well, at the source level, it would be a Geronimo module.  I don't think it would need much
presence in the server runtime -- mostly it's just an outside wrapper around the GBeans in
the server already.  So a tool would create a new management factory, get an instance connected
to the desired Geronimo server, and then start making calls against the API which would be
translated under the covers into calls against the Geronimo MEJB or kernel and GBeans.
@@ -173, +221 @@

  Still, some methods might return null or 0-length arrays if certain features are disabled.
 For example, if you remove the EJB container from your configuration, then you just wouldn't
be able to navigate to that part of the management API tree.
- == What's the advantage?  Is it worth the trouble? ==
+ === What's the advantage?  Is it worth the trouble? ===
  Well, back to the example at the top of the page.  I'd much rather see it like this (where
JDBC!DataSource is an interface in the management API, based on the JDBC!DataSource definition
in JSR-77):
@@ -197, +245 @@

  I think something like this would make it much easier to develop management tools such as
the web console.  By using this API the tools would end up being specific to Geronimo, but
that's OK for our purposes -- we're trying to make Geronimo more usable not write a console
that can manage any J2EE server.  And if we're going to be reusing code across tools, I would
much rather it be an API layer like this, not copying and pasting kernel invocations with
string arguments and so on.
- == Discussion ==
+ === Discussion ===
  Please confirm that the API:

View raw message