Cornerstone JMX is ready for use.

I have checked in cornerstone-jmx-demo under jakarta-jetspeed-2. I will be checking in cornerstone-jmx after I merge the changes into cornerstone. jetspeed-cornerstone-jmx-1.0.jar is checked in under cornerstone-jmx-demo as a temporary measure to let the demo run. Read how-to-run.txt. The demo shows how simple it is to use Cornerstone JMX to put any object under the management of JMX.

Jun

PS: The Cornerstone JMX code was done by Emad Benjamin. I merely did repackaging to strip away anything else unnecessary in Cornstone for just the JMX purpose. We shall probably make him a committer too for him to maintain it.

David Sean Taylor wrote:


On Saturday, January 17, 2004, at 09:33 PM, Jun Yang wrote:


We thank David Le Strat for doing a great job on the service framework proposal.

Here is what we'd like to suggest to add to the proposal:

1. Cornerstone JMX

picoextras/jmx supports registering pico components as JMX components in a special JMX-aware pico container directly with an MBean Server. Cornerstone JMX is designed for a different purpose: JMX-enable any object with no JMX knowledge. When a component is configured to be JMX-enabled, all its states are managed by a standard JMX adapter (The name "adapter" maybe misleading to someone unfamiliar with JMX. It's basically a tool that allows you to manage JMX components). A developer doesn't need to know anything about JMX to make his/her components manageable by JMX. We generate MBeans dynamically.

We can make Cornerstone JMX a self-contained package to be used in Jetspeed so that all services are JMX-enabled with ease without a special pico container.

+1 on moving out Cornerstone's JMX into its own module


2. Cornerstone Customization

The forte of the Cornerstone Framework is its ability to support customizations in many dimensions (component, relationship, flow and preservation over upgrades). Right now it supports type 2 IoC. But we can change it slightly to support both type 2 and type 3 (same as pico) while maintaining the same configuration format. We can make the implementation manager part of Cornerstone a self-contained package as an approach to wiring pico components based on configuration to give pico components the following capabilities:

- Configuration-based (properties files or database) wiring.
- Finer-grain configuration than that picoextras/script's XML solution allows (per component configuration file vs. one file per container), which is important in supporting the next 2 points.
- Multiple "planes" of configuration with user defined order of override.
- Preservation of customization over upgrades.


I think we should get started on moving Jetspeed to the new service architecture now.
I am ready to help out.
My vote is +1 on yours and DLS's combined proposals.


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



Reply via email to