portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emad Benjamin <ebenj...@cisco.com>
Subject Re: [J2] Service Framework Proposal
Date Mon, 09 Feb 2004 16:05:39 GMT
At 08:17 AM 2/9/2004 -0700, BaTien Duong wrote:
>Jun Yang wrote:
>>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.
>Hello Jun
>It's great. There are so many excellent things going on with open 
>technologies and i cannot find time to get back to J2 and Pluto. Anyway, i 
>have a quick and simple question regarding to JMX implementation. Would 
>you please shed some light on the current implementation in relation to 
>standard JMX in J2SE 1.5

I did a quick review of the JMX APIs in J2SE1.5 and I see that they have a 
good wide coverage of the JMX set, but I couldn't see where they have made 
it easier for a java.lang.Object to be auto-JMX-ed.  I think long term we 
can compliment the J2Se1.5 by adding our solution as a helper class.

Here is some background information:


http://www.developer.com/java/data/article.php/2213791 <--- article on what 
Sun plans to do

http://java.sun.com/developer/technicalArticles/releases/j2se15/ <--- 
scroll down to manageability

>>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 
>>>>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: jetspeed-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

View raw message