Title: Patch to Create a 'Local' Management Context (= SystemManager)

This patch implements the concept of a 'local' management context that objects are registered with.  I think its better than spreading the JMX naming scheme in different parts of the code.  The big change is the addition of the getSubContext() method to SystemManager.  The contexts are organized into hierarchy like this:

Phoenix
        Component List
                Component 1
                Component 2
        Application List
                Application 1
                        Block List
                                Block 1
                                Block 2
                Application 2
                        Block List
                                Block 1
                                Block 2

JMX naming is then derived by 'walking' up to the top level context, which is the 'real' SystemManager.

I've tested it with NoOpSystemManager and MX4JSystemManager and haven't encountered any problems.

An itemized list of changes:

org/apache/avalon/phoenix/interfaces/SystemManager.java
- Added method getSubContext( String parent, String type ) to create a subcontext

org/apache/avalon/phoenix/components/manager/MX4JSystemManager.java
- Modified naming code slightly to be compatible with new scheme

org/apache/avalon/phoenix/components/manager/AbstractSystemManager.java
- Added inner class SubContext, which implements SystemManager and acts as the local context

org/apache/avalon/phoenix/components/kernel/DefaultKernel.java
- Changed so applications register with the 'application' list context

org/apache/avalon/phoenix/components/kernel/DefaultApplicationContext.java
- Changed so blocks register with the application's block list context

org/apache/avalon/phoenix/components/embeddor/DefaultEmbeddor.java
- Changed so components are registered with the component list context

The diff was made with the cvs diff -u >> patch diff from the jakarta-avalon-phoenix/src/java directory.  I hope this is right - or is it better to diff each class seperately?

This is part of the Management Proposal idea i sent out last week.  I think these are the only interfaces changes that are required and all the rest of the work would be isolated behind SystemManager interface.

Please let me know what you think.

- Huw

 

Attachment: patch.diff
Description: Binary data

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>


Reply via email to