[cosmo-dev] cosmo webapp packaging

[Benoit Mercier]

Thank you for your quick reaction.  I completly agree with your comments 
concerning log4j and cosmo.properties. 
If you can manage to do the move, it would be a nice improvement of the 
cosmo deployment in existing tomcat environments.

Benoit

Brian Moseley a écrit :
> On Nov 16, 2007 7:54 AM, Benoit Mercier <Benoit.Mercier at usherbrooke.ca> wrote:
>   
>> It would be so nice to simply be able to extract or download the cosmo war and drop it "as it" in a running Tomcat.  We will still have to adapt the connection to the database by editing the /conf/Catalina/localhost/chandler.xml file created automagically by Tomcat from the context.xml file, but so much easier...  I am perhaps missing something, but I think it would be nice to have this configuration that suits the 2 worlds: embedded/bundled and "standard J2EE deployment".
>>     
>
> the war expects the following things from the deployer:
>
> 1) in server.xml, a data source resource
> 2) in server.xml, a mail resource
> 3) in server.xml, a resource that specifies the filesystem location of
> cosmo.properties
> 4) somewhere in the classpath (typically in $CATALINA_HOME/common/lib)
> a commons-logging provider - i've never tested to be sure, but if you
> don't drop in log4j, I believe Tomcat falls back to JDK logging
>
> it seems reasonable for us to provide a context.xml in the war in
> order to allow Tomcat to autocreate a chandler.xml. I know that's more
> preferred than configuring server.xml directly. I'll give it a try.
>
> however, I don't think it's appropriate to package cosmo.properties or
> log4j.jar in the war. in order for the deployer to modify
> cosmo.properties, to provide his own log4j configuration, or to use a
> different logging provider altogether, he'd have to "hack the war" in
> the way that you've done.
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev
>
>