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: Service and Component Frameworks
Date Mon, 01 Dec 2003 19:48:38 GMT
Weaver, Scott wrote:

>>What would be the key features that we would be
>>looking for?
>This is me speaking, but I am sure others feel the same:
>1.  Transparent JMX management of deployed modules.
Cornerstone has transparent JMX support for all services.  A developer 
doesn't need to know anything about JMX to get his/her service 
JMX-enabled.  We can add that support to non-service components easily.

>2.  Hot deploy and hot configuration.  No more stop container, change 
>    property(ies), restart container, wash, rinse, repeat.  Gawd, that's a  
Cornerstone doesn't have hot configuration.  To add it is easy.  
However, the issue is how do we resolve dependencies cleanly.  For 
example, component A has configuration CfgA.  Component B uses a copy of 
CfgA and adds its own overwrites.  We change CfgA at run-time and reload 
A.  We need to know B needs to be reloaded too.  We need a clean and 
simple solution for that.  Otherwise reloading the whole thing might be 
easier and less error-prone.

>3.  The use of POJOs as components would be a nice feature but isn't really 
>    a deal breaker. 
All components in Cornerstone are POJOs.  We designed for simplicity.  
In the current implementation of registry, we don't even use XML.

>4.  Self-contained deployment either via jar or some other container/archive 
>    mechanism.  Each module would have its own config file included.  No 
>    more sifting through unwieldy properties files.  This also makes 
>    updating from the CVS easier you don't have to worry about 
>    dif'ing out all the changes you made that will more than likely conflict
>    with the CVS.  You obviously have to perform some dif'ing, but in 
>    smaller more manageable chunks.
Cornerstone is designed for independently manageable configuration 
chunks.  We need to add this information to the concepts paper.  If you 
look at the registry (code will be available real soon now), we 
purposefully designed away from centralize configuration files (such as 
Tomcat's server.xml and web.xml).  You don't need to parse a 
configuration file to find where you need to insert or modify or 
delete.  In Cornerstone you always simply copy over a file to or delete 
a file from registry in deployment.


>| Scott T Weaver                 |
>| <weaver@apache.org>            | 
>| Apache Jetspeed Portal Project |
>| Apache Pluto Portlet Container |
>>-----Original Message-----
>>From: David Le Strat [mailto:dlestrat@yahoo.com]
>>Sent: Saturday, November 29, 2003 11:44 AM
>>To: Jetspeed Developers List
>>Subject: Re: Service and Component Frameworks
>>There is a lot of good info comparing the differences
>>between frameworks at:
>>Regarding Hivemind, Howard gave a presentation a while
>>back, some more info on Hivemind can be found at:
>>It is a neat framework and hopefully the intellectual
>>property issue will be resolved soon.  I especially
>>like the clean interceptor model.  The substitution
>>model would also be quite handy to create clean
>>separated modules and substitute common configuration
>>from a central configuration point. Finally Hivedoc is
>>quite nice in providing a clear picture of the
>>dependencies between modules.
>>Another interesting approach (which is the approach
>>taken by ExoPortal for instance) would be to combine
>>AOP with Pico container or Avalon (Merlin seems to be
>>the recommended service framework).
>>Lots of choices out there.
>>What would be the key features that we would be
>>looking for?
>>--- David Sean Taylor <david@bluesunrise.com> wrote:
>>>Im starting a little informal thread discussing
>>>Service and Component
>>>Currently we are using Fulcrum in Jetspeed-2.
>>>While I do like Fulcrum and it has been very useful
>>>for us, there are
>>>now more advanced service frameworks available.
>>>All services in J2 are implemented as Common Portlet
>>>Services. The goal
>>>of CPS was to act as a layer so that we could more
>>>easily swap out
>>>Fulcrum in the future. I think that time has come
>>>and we need to start
>>>reviewing the other frameworks and make a decision.
>>>The frameworks we have considering are:
>>>1. Hivemind
>>>2. Pico Container
>>>3. Jetspeed Cornerstone (not to be confused with
>>>Avalon Cornerstone)
>>>4. Avalon
>>>I really like what I've seen in Hivemind, however
>>>the current licensing
>>>issues concern me.
>>>I also think that Cornerstone, contributed by the
>>>Cisco team to
>>>Jetspeed, is very powerful.
>>>Are there other service frameworks we should be

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

View raw message