>I have a "zillion" settings. Suppose I
>will have a trillion of applications here. Then I would have to made a
>trillion of changes to the above mentioned files [cocoon.xconf, web.xml]?

For me, this hasn't been so much of a problem.

1) Regard the cocoon instance as a platform that should be suitable for all your 
cocoon-apps (very much like the configuration for tomcat should be suitable for all 
your web-apps).

2) Most application specific things are done in the sitemap (much more so now in 
version 2 than in version 1). Use sub-sitemaps on a per application basis.

3) If you really really have deep application specific settings that needs to go in 
cocoon.xconf and web.xml, consider using many cocoon instances on your servlet engine. 
It is as easy as deploying the cocoon.war many times under different names 
(cocoon-myapp1.war, cocoon-myotherapp.war).

The benefit of centralized management? Well, some things should be central and others 
should be per application. 

The "problem" (if any) is that cocoon doesn't directly support the notion of different 
"applications". There is no clear definition on what an "application" is in cocoon. 
The discussion about Cocoon Blocks somewhat deals with this, one idea is to create a 
cocoon block as a reusable block of functionality containing its own configuration 
(very much like a war). See the discussion on the dev list.

Hope this helps

/O



---------------------------------------------------------------------
Please check that your question  has not already been answered in the
FAQ before posting.     <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail:     <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Reply via email to