geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: [moving-code]* back to core
Date Tue, 19 Aug 2003 03:45:40 GMT
On Monday, August 18, 2003, at 10:02 PM, Greg Wilkins wrote:

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

That is like saying our transaction manager should go into the JTA spec 

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

Yes "they are not our implementations" and belong in out implementation 
tree... modules.

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

No state manageable is a simple interface that only has the state 
manageable methods defined in chapter 5.  Component has a container and 
an object name.  I think we should consider renaming component to 
J2EEManageObject as it more closely resembles it, but it would mean 
adding a few more methods, and is for another discussion.

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

Just put some java doc that says this if from the J2EE management spec 
chapter 5.  Don't change it.

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

All of our implementations are controlled by specs.


View raw message