Cargo

Allow the XML/properties replacement engine to WARN when a replacement is not possible (instead of failing)

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 1.2.2
  • Component/s: Core
  • Labels:
    None
  • Complexity:
    Intermediate
  • Tested on JDKs:
    JDK 1.7
  • Number of attachments :
    0

Description

When starting a Tomcat 7.x server where there are no access logging defined i the server.xml the following exception occurs:

org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.cargo:cargo-maven2-plugin:1.2.1:start (start-container) on project fps: Execution start-container of goal org.codehaus.cargo:cargo-maven2-plugin:1.2.1:start failed: Cannot modify XML file /export/jenkins_home/jobs/FPS-Code-Analysis/workspace/trunk/target/cargo/configurations/tomcat7x/conf/server.xml
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
	at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
	at org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
	at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158)
	at hudson.maven.Maven3Builder.call(Maven3Builder.java:104)
	at hudson.maven.Maven3Builder.call(Maven3Builder.java:70)
	at hudson.remoting.UserRequest.perform(UserRequest.java:118)
	at hudson.remoting.UserRequest.perform(UserRequest.java:48)
	at hudson.remoting.Request$2.run(Request.java:287)
	at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
	at java.util.concurrent.FutureTask.run(FutureTask.java:166)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
	at java.lang.Thread.run(Thread.java:722)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution start-container of goal org.codehaus.cargo:cargo-maven2-plugin:1.2.1:start failed: Cannot modify XML file /export/jenkins_home/jobs/FPS-Code-Analysis/workspace/trunk/target/cargo/configurations/tomcat7x/conf/server.xml
	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
	... 27 more
Caused by: org.codehaus.cargo.util.CargoException: Cannot modify XML file /export/jenkins_home/jobs/FPS-Code-Analysis/workspace/trunk/target/cargo/configurations/tomcat7x/conf/server.xml
	at org.codehaus.cargo.util.DefaultFileHandler.replaceInXmlFile(DefaultFileHandler.java:463)
	at org.codehaus.cargo.container.spi.configuration.AbstractStandaloneLocalConfiguration.performXmlReplacements(AbstractStandaloneLocalConfiguration.java:124)
	at org.codehaus.cargo.container.tomcat.Tomcat5xStandaloneLocalConfiguration.performXmlReplacements(Tomcat5xStandaloneLocalConfiguration.java:155)
	at org.codehaus.cargo.container.tomcat.Tomcat7xStandaloneLocalConfiguration.performXmlReplacements(Tomcat7xStandaloneLocalConfiguration.java:86)
	at org.codehaus.cargo.container.spi.configuration.AbstractStandaloneLocalConfiguration.configure(AbstractStandaloneLocalConfiguration.java:90)
	at org.codehaus.cargo.container.spi.configuration.builder.AbstractStandaloneLocalConfigurationWithXMLConfigurationBuilder.configure(AbstractStandaloneLocalConfigurationWithXMLConfigurationBuilder.java:123)
	at org.codehaus.cargo.container.spi.AbstractLocalContainer.start(AbstractLocalContainer.java:159)
	at org.codehaus.cargo.maven2.AbstractContainerStartMojo.doExecute(AbstractContainerStartMojo.java:61)
	at org.codehaus.cargo.maven2.ContainerStartMojo.doExecute(ContainerStartMojo.java:52)
	at org.codehaus.cargo.maven2.AbstractCargoMojo.execute(AbstractCargoMojo.java:311)
	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
	... 28 more
Caused by: org.codehaus.cargo.util.CargoException: Node //Server/Service/Engine/Host/Valve[@className='org.apache.catalina.valves.AccessLogValve'] not found in file /export/jenkins_home/jobs/FPS-Code-Analysis/workspace/trunk/target/cargo/configurations/tomcat7x/conf/server.xml
	at org.codehaus.cargo.util.DefaultFileHandler.replaceInXmlFile(DefaultFileHandler.java:435)
	... 38 more

If server.xml does not contain any AccessLogValve-elements, cargo should not fail to start the server.

Issue Links

relates to

Improvement - An improvement or enhancement to an existing feature or task. CARGO-839 Avoid having the cargo-specific XML files in the JBoss local containers

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Improvement - An improvement or enhancement to an existing feature or task. CARGO-1060 Avoid having the cargo-specific XML files in the Jetty local containers

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Improvement - An improvement or enhancement to an existing feature or task. CARGO-1061 Avoid having the cargo-specific XML files in the Tomcat local containers

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Improvement - An improvement or enhancement to an existing feature or task. CARGO-1075 Avoid having the cargo-specific XML files in the Resin local containers

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Savas Ali Tokmen added a comment -

Hi Andreas

Is there a particular reason why you're using a standalone configuration?

If you want CARGO to reuse an existing server.xml, you should rather use an existing local configuration. More info here: http://cargo.codehaus.org/Existing+Local+Configuration

Thank you

Show
Savas Ali Tokmen added a comment - Hi Andreas Is there a particular reason why you're using a standalone configuration? If you want CARGO to reuse an existing server.xml, you should rather use an existing local configuration. More info here: http://cargo.codehaus.org/Existing+Local+Configuration Thank you
Hide
Permalink
Andreas Bergander added a comment -

When running integration tests I would prefer to have a new clean container each time and therefore I use the standalone configuration. I then use the method described here http://cargo.codehaus.org/Configuration+files+option to add my own server.xml from my source code repository. It worked nicely in previous versions of cargo (e.g. 1.1.4).

Also, the tests could be run on any machine without requiring a pre-installed Tomcat when using the standalone configuration.

On our continous integration server we could use the local configuration as a work around, so thanks for your suggestion. I would however prefer to use the standalone configuration for the reasons stated above.

Show
Andreas Bergander added a comment - When running integration tests I would prefer to have a new clean container each time and therefore I use the standalone configuration. I then use the method described here http://cargo.codehaus.org/Configuration+files+option to add my own server.xml from my source code repository. It worked nicely in previous versions of cargo (e.g. 1.1.4). Also, the tests could be run on any machine without requiring a pre-installed Tomcat when using the standalone configuration. On our continous integration server we could use the local configuration as a work around, so thanks for your suggestion. I would however prefer to use the standalone configuration for the reasons stated above.
Hide
Permalink
Savas Ali Tokmen added a comment -

Hi Andreas

The "standalone" configuration means that CARGO will create the configuration; on the other hand assumes that the server distribution given as executable is the "official" one.

What used to happen with CARGO 1.1.4 is that the server.xml was actually overwritten by the one provided by CARGO. With CARGO 1.2.0, CARGO attempts to replace entries in the XML file; which fails since you have manually removed a line from the official distribution.

Now, it might make sense to remove this for logging, or perhaps replace it with a warning. I guess this would be an improvement.

What do you think?

PS: More people would have shared their opinions if this were sent to the user@cargo.codehaus.org list

Show
Savas Ali Tokmen added a comment - Hi Andreas The "standalone" configuration means that CARGO will create the configuration; on the other hand assumes that the server distribution given as executable is the "official" one. What used to happen with CARGO 1.1.4 is that the server.xml was actually overwritten by the one provided by CARGO. With CARGO 1.2.0, CARGO attempts to replace entries in the XML file; which fails since you have manually removed a line from the official distribution. Now, it might make sense to remove this for logging, or perhaps replace it with a warning. I guess this would be an improvement. What do you think? PS: More people would have shared their opinions if this were sent to the user@cargo.codehaus.org list
Hide
Permalink
Andreas Bergander added a comment -

I guess I could modify my custom server.xml to better match the original, but yes, it would be an improvement if CARGO warns instead of fails when modifying the file. Should it be configurable?

I think it would be a nice feature to allow a custom config in the standalone mode. The standalone mode is great if you want all developers to be able to start a container without installing anything manually. But sometimes the project requires a custom config as well.

Btw, the following missing xpath also gave me an error: //Server/Service/Connector[@protocol='AJP/1.3'] Perhaps there are more?

Show
Andreas Bergander added a comment - I guess I could modify my custom server.xml to better match the original, but yes, it would be an improvement if CARGO warns instead of fails when modifying the file. Should it be configurable? I think it would be a nice feature to allow a custom config in the standalone mode. The standalone mode is great if you want all developers to be able to start a container without installing anything manually. But sometimes the project requires a custom config as well. Btw, the following missing xpath also gave me an error: //Server/Service/Connector [@protocol='AJP/1.3'] Perhaps there are more?
Hide
Permalink
Savas Ali Tokmen added a comment -

Hi Andreas

Perfect, so I'm changing the issue details accordingly.

Thank you

Show
Savas Ali Tokmen added a comment - Hi Andreas Perfect, so I'm changing the issue details accordingly. Thank you
Hide
Permalink
Savas Ali Tokmen added a comment -

Hi Andreas

Committed revision 3288 which fixes this.

The new property is GeneralPropertySet.IGNORE_NON_EXISTING_PROPERTIES or cargo.standalone.ignoreNonExistingProperties and is obviously by default set to false.

Feel free to try, for this use version 1.2.2-SNAPSHOTS. Instructions on http://cargo.codehaus.org/Maven2+Plugin+Installation#Maven2PluginInstallation-snapshots

Cheers

Show
Savas Ali Tokmen added a comment - Hi Andreas Committed revision 3288 which fixes this. The new property is GeneralPropertySet.IGNORE_NON_EXISTING_PROPERTIES or cargo.standalone.ignoreNonExistingProperties and is obviously by default set to false. Feel free to try, for this use version 1.2.2-SNAPSHOTS. Instructions on http://cargo.codehaus.org/Maven2+Plugin+Installation#Maven2PluginInstallation-snapshots Cheers
Hide
Permalink
Andreas Bergander added a comment -

Seems to work just fine!

Thank you

Show
Andreas Bergander added a comment - Seems to work just fine! Thank you

People

  • Assignee:
    Savas Ali Tokmen
    Reporter:
    Andreas Bergander
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: