> 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 org.apache.management.j2ee ? > (or as you suggest org.apache.geronimo.management.j2ee). > > Note the package was picked as it was shadowing javax.management.j2ee > > 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. -- Jeremy
