portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jun Yang <juny...@cisco.com>
Subject Re: [J2] Service Framework Proposal
Date Tue, 20 Jan 2004 04:20:46 GMT
David Le Strat wrote:

>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
>registry.
>
>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?
>  
>
Yes.  Each service will have its own config file packaged with it, just 
like what you have outlined in your proposal.

>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?
>  
>
The config file packaged with a component is its out-of-box 
configuration.  If central configration is not available, the component 
will be configured just as specified by this config file.  If central 
configuration is available, then central configuration is used as an 
override for out-of-box configuration.  In another word, central 
configuration is optional.  Central configuration enables the support 
for preservation of customization and "configuration planes".

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

>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
>http://cvs.sourceforge.net/viewcvs.py/jicarilla/jicarilla-sandbox/platform/container/tck/
>and http://www.jroller.com/page/lsd/20040114
>  
>
This is very interesting.

>What are you thoughts?
>
>Regards.
>
>David.
>  
>
Jun

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


Mime
View raw message