portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Price" <tpr...@iupui.edu>
Subject Re: [J2] Service Framework Proposal
Date Sun, 18 Jan 2004 09:18:43 GMT
Yes, very good proposal.

Just curious - why wasn't OSGI considered as a possible service framework?


> 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.
> 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.
> For service orchestration, we are in the process of settling on the
> optimal among several solutions.
> Thanks!
> Jun and Emad
> David Le Strat wrote:
>>We had quite a few threads on the service framework
>>topic, IRC sessions regarding Cornerstone.  In order
>>for J2 to shine, the Jetspeed developers community
>>needs to come to a consensus and a decision around a
>>service framework for Jetspeed.
>>I have prepared a document (zip file enclosed) that
>>tries to articulate what J2 needs from a service
>>framework and proposes a direction.  That should help
>>provide a basis for a discussion that hopefully will
>>lead to a decision / vote on the best alternative for
>>the future of Jetspeed.
>>David Le Strat.

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

View raw message