Make the timeout for JettyRemoteDeployer configurable

Description

JettyRemoteDeployer has a hard-coded timeout of 30 seconds for new deployments:

and

We're deplying a big war file (generated by a 3rd party) to a virtualized server, so deployment typically takes 1 minute. The timeout should be configurable, so that cases like this can increase the timeout (whereas the default is probably fine for 99% of the users).

Activity

Show:
S. Ali Tokmen
August 5, 2016, 4:32 PM

Hi Havard

Thanks for pointing this out.

As per the below, the improvement is now implemented and tests are current being passed on the continous integration system.

You can check with the 1.5.1-SNAPSHOT version, either by building it yourself of waiting c.a. one day and following the instructions on https://codehaus-cargo.github.io/cargo/Maven2+Plugin+Installation.html#Maven2PluginInstallation-snapshots

Regards

Håvard Bjåstad
August 8, 2016, 6:52 AM
Edited

Hi Ali, thanks for the quick response!
Having it configurable in the web.xml makes it a bit cumbersome (having to unpack the war, substitute and re-pack the war), could you add the possibility to override the default with another mechanism...e.g. reading a system property?

S. Ali Tokmen
August 8, 2016, 10:59 PM

Hi Havard

Well ... The Java EE standards actually recommend updating the WAR, so you can also for example set security settings

Are you sure you also need a system property?

Please advise

Håvard Bjåstad
August 9, 2016, 9:14 AM

Hi Ali, I want to see the cargo-jetty-7-and-onwards-deployer war file as a binary artifact that I should not need to tamper with. There's nothing in the Java EE standards that recommend updating a ready-to-deploy war file

Having a default timeout in the web.xml is better than having a constant in the code - from the perspective of the developer of that artifact (you). But from the perspective of a user of the artifact (me), the difference is that it allows me to unpack the war file, change the web.xml and re-pack the war file (thus creating a new version of the artifact).

If you add the ability to override the default with a value retrieved from something external to your artifact (could be either a system property, an environment variable or an external file), then I could provide the override without tampering with your artifact.

S. Ali Tokmen
August 9, 2016, 8:40 PM

Hi Havard

It is for me more efficient to add a property than explain how Java EE recommends deployments

Property cargo.jetty.deployer.timeout added to org.codehaus.cargo.deployer.jetty.DeployerServlet.

Enjoy

Assignee

S. Ali Tokmen

Reporter

Håvard Bjåstad

Components

Fix versions

Priority

Major
Configure