geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeremy Boynes" <>
Subject RE: [moving-code]* back to core
Date Tue, 19 Aug 2003 01:35:33 GMT

> We have been discussing this for a bit in the JSR77 threads.
> While these classes are not part of the spec API, they are definitely
> part of the spec.  They are implementations of the object models
> defined in the spec.

"Although the diagrams and textual descriptions that specify the managed
object types closely resemble Java classes, they are not specifications of
Java class types or Java class inheritance hierarchies and do not represent
requirements of the class names or class hierarchies of a particular
implementation." [pp 19]

So they are not part of the spec. The spec defines a logical object model
that is implemented in the types of the management framework; Java is one
option (used by JMX) but there are others. This is a very deliberate move by
the spec committee to preserve language independence. It is analogous to an
Open MBean definition.

Note this is very different from the MEJB, which, by definition, is a Java
artifact and can use Java types. It is the MEJB API that the spec defines.

> They have been put into the spec module so that we realize that they
> cannot be changed simply for our own purposes and that their APIs are
> defined by JSR77.

The spec module should provide the API defined by the spec. These are not
part of it; they are our own implementation (even down to the package name);
BEA, IBM, Sun, whoever, will have a different definition of the interfaces.

> If we had them in the core module, then it would be easy for somebody
> to change the APIs for whatever reason and not realize that they are
> breaking the object models of the spec.
> So I don't think they should be moved back.  What is the problem
> having them in the spec module under ?
> (or as you suggest
> Note the package was picked as it was shadowing
> But I don't really care about the package name - just that the classes
> themselves are considered part of the spec.

They are not part of the spec, they are a convenience defined by Geronimo
code; as such they should be in a geronimo module.


View raw message