portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Sean Taylor <da...@bluesunrise.com>
Subject Re: [J2] Service Framework Proposal
Date Tue, 03 Feb 2004 05:51:41 GMT

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

View raw message