portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From BaTien Duong <batien.du...@dbgroups.com>
Subject Re: [J2] Service Framework Proposal
Date Mon, 09 Feb 2004 18:57:27 GMT
Hello Jun and Emad

Thanks.

BaTien
DBGROUPS

Jun Yang wrote:

> 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
>
> .
>



---------------------------------------------------------------------
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