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: Cornerstone demo
Date Sat, 13 Dec 2003 21:14:25 GMT
BaTien Duong wrote:

> Jun Yang wrote:
>
>> BaTien,
>>
>> Here is the email that we sent earlier.  Please read the document 
>> Jetspeed Cornerstone Sample Code in particular.  Let me know if you 
>> have any questions.
>
>
> Thanks. I looked at cornerstone-demo. Here are my first impressions:
>
> The cornerstone concept is very interesting, especially with its 4 
> dimensions of customizations: components, component relationships, 
> control flows of components, and persistence of the customizations. It 
> seems to me the framework will be much more useful with these additions:
>    1) Except of the bootstrap properties file, components (service) 
> initialization centralized in 1 place using XML and Digester will make 
> the naming much easier to follow and manage.  The services not 
> initialized via XML name-value settings can then proprammatically 
> registered with empty context as demonstrated. The effort in this area 
> is munimum but the benefit is significant. Many apache projects use 
> Digester: Struts, Tiles, HiveMind.

In terms of "one place", Cornerstone already has all configuration in 
one place, the registry.  It's just registry entries are in separate 
files.  We tried to avoid having a single file on purpose so that adding 
or replacing something is just a matter of copying some files and 
removing something just a matter of deleting some files (vs. having to 
unserialize a file, modify and serialize it back (what if somebody else 
is holding onto a copy of the unserialized form of that file?)).  I find 
difficult, for example, having to find the right place to 
insert/modify/delete in server.xml or web.xml.  This is exactly what we 
tried to avoid.

Also, the registry implemented with properties files can support this: a 
whole "plane" of registry can be taken out for example when we delete 
the directory for that plane under registry.  More concretely, the 
out-of-box registry plane is 100.  So we have directory registry/100 
under which is all configuraiton.  Vendor 1 adds some customizations on 
top of that by adding a plane 150.  So we have directory "100" and "150" 
under "registry" with everything in 150 overriding 100.  Vendor 2 adds 
plane "170".  So plane "170" overrides "150" which overrides "100".  As 
a customer, you can easily take out vendor 1 or vendor 2's 
customizations by deleting directory "150" or "170".

However, it doesn't mean properties files are the only form of registry 
Cornerstone will ever see.  It's just one of the possible 
implementations (albeit a simple yet powerful one).  Anybody can add an 
implementation using XML or database (in the plans).  This is the 
flexibility built into the core of Cornerstone.  But it's the 
capabilities above that we want to retain.

>    2) Two things will make the framework instantly shine are 
> best-of-breed CacheService and  SpoolService besides the full working 
> of the 4 dimensions of customization. I saw the tutorial of 
> CacheService in developmnet cookbook but missing in the current cvs.

The Cisco production version of Cornerstone has both caching and 
pooling.  They are not included in the Jetspeed version because they 
both have some dependencies on some internally developed components.  
Adding them back is very easy especially given the internal caching 
mechanism is just a layer on top of JCS Caching.  For pooling, we can 
use one of the many available.

> Hope Jun will have time to make cornerstone framework a real 
> cornerstone of portal services.

Yes, we want to make Jetspeed shine with Cornerstone.  Within Cisco, the 
buzz is getting around.  We have some concrete projects that are using 
or going to use Cornerstone (remember one is in production already :)).  
On the other hand, as many have pointed out, Cornerstone is not a portal 
only framework.  It can be used in any application that needs mass 
customization (well practically every single one does :))..

We are very excited at seeing so much positive feedback on this mailing 
list.  Thank you all!  Please contribute your great ideas so that we 
push it forward together!

> Best Regards
> BaTien
> DBGROUPS

Jun

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