cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: [2.2] Configuration
Date Mon, 22 May 2006 17:16:41 GMT
Reinhard Poetz wrote:
> Von: Carsten Ziegeler <>
>>Yes, true. What about extending the deployer (or creating another
>>plugin) which by default rewrites the web.xml and adds all required
>>wrappers (paranoid servlet etc.) and also moves the jars to a different
>>directory? With a plugin-configuration this can be turned off.
>>(We don't need this for b1)
> At the weekend I was thinking about this and using different locations for lib and classes
and extending the existing functionality of the maven-war-plugin can be achieved by renaming
them after the "original" methods have been called. That's easy :-)
> Having a configuration that can turn on/off the support for paranoid classloading is
the way to go. The default value is, as proposed by Carsten, true and then the deployer checks
whether all necessary configurations in web.xml are set correctly or if not set it adds them.
> I don't think that we have to (and should) provide any patching functionality to the
deployer as people are in control of the content of WEB-INF and its subdirectories. If they
add some file there which has the same name as a file in one of the blocks, it overrides the
original version. The only thing that we should do is splitting up our configuration files
in smaller chunks so that we get one configuration file for one component so that people get
fine-grained control.

One additional thought:
Maven 2 has the concept of profiles. Profiles make it possible to customize the 
build process and that's what we need to provide configurations for different 

Suppose you have two environments: development (dev) and production (prod). If 
you create the web application, you might need different .xconf (database 
connections, root sitemap, ...) values and different properties.

In your src/main/webapp directory, you have for example


I propose that we have a directory "src/main/webapp-profiles" that contains all 
files for different profiles:


This way we can create environment specific web applications by calling

"mvn cocoon:deploy -P dev" or "mvn cocoon:deploy -P dev,prod"

As mentioned in my previous message, this make it necessary to split up 
cocoon.core in small chunks (every component get's its own configuration file) 
so that the override mechanism works smoothly.


Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}



Telefonate ohne weitere Kosten vom PC zum PC:

View raw message