portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jun Yang <juny...@cisco.com>
Subject Re: [J2] Service Framework Proposal
Date Mon, 09 Feb 2004 17:28:58 GMT
Hi BaTien,

Cornerstone JMX is not a JMX implementation per se.  It's a bridge 
between an object you want to manage (e.g. an instance of a service) and 
the complex JMX API.  It takes the hard part out of using JMX.  For 
example, here is what you need to do to make logService manageable by JMX:

IJMXManager jmxManager = (IJMXManager) 
Cornerstone.getManager(IJMXManager.class);
jmxManager.manage(logService);

And yes, that's all you need.  With a standard JMX tool, you manage all 
constructors, properties and methods (operations) of logService (e.g. 
change the level log at runtime).

Jun

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


Mime
View raw message