portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Le Strat <dlest...@yahoo.com>
Subject Re: [J2] Service Framework Proposal
Date Sun, 18 Jan 2004 18:05:40 GMT
Thanks Jun.
This sounds like quite a great and promising use of
Cornerstone.  JMX support for all components will be
quite nice.

I have a few questions.

Use case:
Let's say we have a persistence service (e.g with
several methods add, delete, query, etc.).
Another service, for instance registry, needs to use
the persistence service for building the portal

1. From a configuration stand point, will we be able
to package persistence and registry as 2 self
contained jar file where each jar contains the
configuration required for each service?

2. Will we be able to centralize the configuration for
each service? Will we still need to define the
registry or will it be built from the service
configuration in order to resolve dependencies?

3. How will it support unit testing?  Will we be able
to only load the service dependencies required for
unit test?  For instance, to test registry, only the
persistence service is needed?

As an aside, it may be interesting to look/use Leo
Simons components TCK, so that we can make sure that
our components are portable to other containers
and http://www.jroller.com/page/lsd/20040114

What are you thoughts?



--- Jun Yang <junyang@cisco.com> 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.
> 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:
> >All,
> >
> >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.
> >
> >Regards,
> >
> >David Le Strat.
> >
> To unsubscribe, e-mail:
> jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> jetspeed-dev-help@jakarta.apache.org

Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes

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

View raw message