If you need any help from me lemme know. ~suchi
-----Original Message----- From: Jun Yang [mailto:[EMAIL PROTECTED] Sent: Monday, February 02, 2004 11:51 PM To: Jetspeed Developers List Subject: Re: [J2] Service Framework Proposal We will start implementation now. Will do Cornerstone JMX first and then Cornerstone Customization for PicoContainer. Jun 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
