geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Wilkins <>
Subject Re: [moving-code]* back to core
Date Tue, 19 Aug 2003 03:02:33 GMT

The JSR Object model classes have not part of the spec *API* - hence
they are not in the package.

But they are defined by the spec.  They are our java implementations
of Object models that are clearly defined in the spec.  Thus I think
that putting them under the spec module in our package name is

They are not our implementations of the spec API - that is
AbstractStateManageable and that is in the geronimo core module.

If we move StateManageable interface back to a geronimo core module,
then we may as well just get rid of it and have the Component interface
provide the correct Object model.

The idea of factoring out StateManageable was to make it clear what
part of the implementation API was dictated by the spec - not just
happenstance that a class has a spec compliant API.

We had the discussion and decided to move them - and they have been
moved.  But if you really feel strongly about it, then can you propose
an alternate solution to just putting them back into org.apache.geronimo.core

I strongly believe that our java implementation of the jsr77 Object models needs
to be put somewhere that idicates that the API is controlled by a spec - and
the spec module under our own package appears to meet that criteria.

Jeremy Boynes wrote:
>>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.
> --
> Jeremy

View raw message