Hi Eric, I have been thinking a bit about this and I don't have a perfect solution yet. I can think of 2:
1/ Have an optional Maven Cactus plugin property, such as maven.cactus.tomcat4x.serverxml. If defined, the cactus plugin will one the location specified by it and if not, it will use the default server.xml. A variation of this is what you suggest: merging the 2 server.xml. That's true for all configuration files for all containers... 2/ Have the ability in the cactus plugin to point to an existing tomcat setup instead of deploying it in a tmp directory. Thus for simple tests, users would use the predefined setup and for complex one, it could use a user-defined setup. -Vincent > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: 10 February 2003 16:44 > To: [EMAIL PROTECTED] > Subject: How to test apps that require specific Server.xml > > Hi all, > > I recently discovered JNDI and am thinking about switching from a heaviliy > properties based configs, to using Tomcat's JNDI support. However, that > means a lot of data is in server.xml and web.xml's... > > I am using the Maven plugin for Cactus, and am challenged by the fact that > the plugin doesn't merge or otherwise deal with server.xml. I could just > edit the source server.xml for all my webapps that need testing, but I was > hoping to hear what other people have done. > > Has anyone written something that would merge a specific webapps > server.xml > into the main test server.xml file? > > Eric Pugh --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
