You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Dain Sundstrom <da...@coredevelopers.net> on 2003/08/19 02:07:35 UTC
[moving-code] org.apache.management.j2ee.* back to core
This is the one that really threw me... Why do we have a
org.apache.management.j2ee package? This is outside of our project
space and should be at least org.apache.geronimo.management, and
without the j2ee as it is redundant because geronimo is a j2ee server.
The other thing is these classes are not part of the spec so should not
be in the spec tree at all. I will be moving these back to core.
-dain
/*************************
* Dain Sundstrom
* Partner
* Core Developers Network
*************************/
Re: [moving-code] org.apache.management.j2ee.* back to core
Posted by James Strachan <ja...@yahoo.co.uk>.
On Tuesday, August 19, 2003, at 09:29 am, Richard Monson-Haefel wrote:
> I'm not an expert at CVS, but isn't it possible to restrict changes to
> a
> particular set of sources to specific parties. In other words, make
> it so
> that only a few people in-the-know can modify the source code of the
> 77
> impls.
Not really - unless we split up the project into multiple CVS
repositories (which I don't like) or use SVN.
Incidentally, one solution to the moving code problem could be to
create the patch from the src directory (rather than the geronimo
directory) then it doesn't matter where the code gets moved to, from
module to module, the patch should still work.
James
-------
http://radio.weblogs.com/0112098/
Re: [moving-code] org.apache.management.j2ee.* back to core
Posted by Richard Monson-Haefel <Ri...@Monson-Haefel.com>.
I'm not an expert at CVS, but isn't it possible to restrict changes to a
particular set of sources to specific parties. In other words, make it so
that only a few people in-the-know can modify the source code of the 77
impls.
On 8/18/03 8:45 PM, in article
9A602864-D1F7-11D7-8482-000393DB559A@coredevelopers.net, "Dain Sundstrom"
<da...@coredevelopers.net> wrote:
> 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 javax.management.j2ee 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
> tree.
>
>> 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.
>
> -dain
>
>
Re: [moving-code] org.apache.management.j2ee.* back to core
Posted by Dain Sundstrom <da...@coredevelopers.net>.
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 javax.management.j2ee 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
tree.
> 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.
-dain
Re: [moving-code] org.apache.management.j2ee.* back to core
Posted by Greg Wilkins <gr...@mortbay.com>.
The JSR Object model classes have not part of the spec *API* - hence
they are not in the javax.management.j2ee 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.
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 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
>
>
Re: [moving-code] org.apache.management.j2ee.* back to core
Posted by Greg Wilkins <gr...@mortbay.com>.
The JSR Object model classes have not part of the spec *API* - hence
they are not in the javax.management.j2ee 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.
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 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
>
>
RE: [moving-code] org.apache.management.j2ee.* back to core
Posted by Jeremy Boynes <je...@coredevelopers.net>.
> 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
Re: [moving-code] org.apache.management.j2ee.* back to core
Posted by Greg Wilkins <gr...@mortbay.com>.
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.
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.
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.
cheers
Dain Sundstrom wrote:
> This is the one that really threw me... Why do we have a
> org.apache.management.j2ee package? This is outside of our project
> space and should be at least org.apache.geronimo.management, and without
> the j2ee as it is redundant because geronimo is a j2ee server. The
> other thing is these classes are not part of the spec so should not be
> in the spec tree at all. I will be moving these back to core.
>
> -dain
>
> /*************************
> * Dain Sundstrom
> * Partner
> * Core Developers Network
> *************************/
>
>
Re: [moving-code][jsr77] org.apache.management.j2ee.* back to core
Posted by Greg Wilkins <gr...@mortbay.com>.
Bodo Wippermann wrote:
> to compile the unit tests the "StateTest" should also be moved.
> and the package name should be corrected.
DOH! How did that pass the test harnesses!
fixing now.
Re: [moving-code][jsr77] org.apache.management.j2ee.* back to core
Posted by Bodo Wippermann <bo...@bodow.de>.
to compile the unit tests the "StateTest" should also be moved.
and the package name should be corrected.
Greg Wilkins schrieb:
>
>
>
> Greg Wilkins wrote:
> > So I'm giving notice that I'm going to move
> >
> > State
> > StateManageable
> > NotificationType
> >
> > from specs/j2ee-management/src/java/org/apache/management/j2ee
> > to modules/core/src/java/org/apache/geronimo/management
>
> OK, I'm going ahead with this. Commit in the next hour.
>
>
Re: [moving-code][jsr77] org.apache.management.j2ee.* back to core
Posted by Greg Wilkins <gr...@coredevelopers.net>.
Greg Wilkins wrote:
> So I'm giving notice that I'm going to move
>
> State
> StateManageable
> NotificationType
>
> from specs/j2ee-management/src/java/org/apache/management/j2ee
> to modules/core/src/java/org/apache/geronimo/management
OK, I'm going ahead with this. Commit in the next hour.
--
/**************************
* Greg Wilkins
* Partner
* Core Developers Network
**************************/
Re: [moving-code][jsr77] org.apache.management.j2ee.* back to core
Posted by Greg Wilkins <gr...@mortbay.com>.
Dain Sundstrom wrote:
> I suggested org.apache.geronimo.management
OK - so we wont move them back to org.apache.geronimo.core package,
just the core module.
Having them 77 models in their own package is all that is really needed.
So I'm giving notice that I'm going to move
State
StateManageable
NotificationType
from specs/j2ee-management/src/java/org/apache/management/j2ee
to modules/core/src/java/org/apache/geronimo/management
I'll do this tomorrow unless told not to.
cheers
Re: [moving-code][jsr77] org.apache.management.j2ee.* back to core
Posted by Greg Wilkins <gr...@mortbay.com>.
Dain Sundstrom wrote:
> I suggested org.apache.geronimo.management
OK - so we wont move them back to org.apache.geronimo.core package,
just the core module.
Having them 77 models in their own package is all that is really needed.
So I'm giving notice that I'm going to move
State
StateManageable
NotificationType
from specs/j2ee-management/src/java/org/apache/management/j2ee
to modules/core/src/java/org/apache/geronimo/management
I'll do this tomorrow unless told not to.
cheers
Re: [moving-code] org.apache.management.j2ee.* back to core
Posted by Dain Sundstrom <da...@coredevelopers.net>.
On Monday, August 18, 2003, at 07:31 PM, Alex.Blewitt@ioshq.com wrote:
> On Mon, 18 Aug 2003, Dain Sundstrom wrote:
>
>> This is the one that really threw me... Why do we have a
>> org.apache.management.j2ee package? This is outside of our project
>> space and should be at least org.apache.geronimo.management, and
>> without the j2ee as it is redundant because geronimo is a j2ee server.
>
> There was a discussion regarding these packages and what they should be
> called. The discussion at hand (as I recall) was that there needed to
> be
> a clear differentiation between the JSR77? and JMX packages, which is
> why
> the package J2EE Management was created; see JSR77:
> http://www.jcp.org/en/jsr/detail?id=77
I suggested org.apache.geronimo.management, but don't get me wrong
everything we are doing is JMX. I am just suggesting management as our
JMX package contains JMX extensions and utilities.
>> The other thing is these classes are not part of the spec so should
>> not
>> be in the spec tree at all. I will be moving these back to core.
>
> Are they not an implementation of the spec? From what I recall of the
> discussions of JSR77, there were untyped interfaces that relied solely
> on
> naming conventions in order to work. I recall that some generic
> implementations were created to satisfy those naming conventions, but
> as
> you say, they are not part of the 'official' interface.
The is exactly my point. These class are our implementation, and our
implementation classes go into the plain old modules trees. If we were
to follow the logic of our implementation goes into the spec tree, we
would not have a modules tree at all.
-dain
/*************************
* Dain Sundstrom
* Partner
* Core Developers Network
*************************/
Re: [moving-code] org.apache.management.j2ee.* back to core
Posted by Al...@ioshq.com.
On Mon, 18 Aug 2003, Dain Sundstrom wrote:
> This is the one that really threw me... Why do we have a
> org.apache.management.j2ee package? This is outside of our project
> space and should be at least org.apache.geronimo.management, and
> without the j2ee as it is redundant because geronimo is a j2ee server.
There was a discussion regarding these packages and what they should be
called. The discussion at hand (as I recall) was that there needed to be
a clear differentiation between the JSR77? and JMX packages, which is why
the package J2EE Management was created; see JSR77:
http://www.jcp.org/en/jsr/detail?id=77
> The other thing is these classes are not part of the spec so should not
> be in the spec tree at all. I will be moving these back to core.
Are they not an implementation of the spec? From what I recall of the
discussions of JSR77, there were untyped interfaces that relied solely on
naming conventions in order to work. I recall that some generic
implementations were created to satisfy those naming conventions, but as
you say, they are not part of the 'official' interface.
All this is IIRC, because I wasn't involved with the JSR77 stuff, just
dredging up thoughts from the back of my mind.
Alex.
/***************************************************************\
|* Alex Blewitt * Hug, and the world hugs with you *|
|* Alex.Blewitt@ioshq.com * *|
|* Mobile: +44 7966 158 647 * Spread a little happiness *|
\***************************************************************/