Using Maven Cargo with Jetty 12x

27 views
Skip to first unread message

John Domingo

unread,
May 7, 2024, 2:35:06 PM5/7/24
to Codehaus Cargo
Hi Cargo Team!

I am looking at using Maven Cargo since I have a need to run mutiple WARs for integration testing I am doing in a project. I am currently trying to use the following with the project:
  • JDK 17 
  • Maven Cargo Plugin v1.10.13
  • Jetty 12x (specifically 12.0.8)
I did notice there currently is no embedded container support for Jetty12x, so I was looking at using the local container solution via the artifactInstaller option (or even the ZIP option, but the artifactInstaller option seems to be the cleaner solution.  Your current documentation example references the use of the org.eclipse.jetty:jetty-distribution dependency, but I noticed is that the Maven Jetty distribution project does not seem to be supported anymore (last distribution available is for 11.0.0.beta1, built in July 2020).  I looked a bit, and don't see a jetty-distribution available under the new org.eclipse.jetty.ee10 groupId, and I can't find any reference to a replacement anywhere.

My question is, is there current and specific documentation/examples for configuring the Maven Cargo Plugin for use with Jetty12x and artifactInstaller?  Is it even supported for Jetty12x still?  I just wanted some direction on whether or not this is possible at the moment.  Are there any examples available I can reference for using the combination of version of Maven Cargo plugin (v1.10.13) and Jetty 12x (v12.0.8)?

Thanks Cargo team!

Cheers!
John

S. Ali Tokmen

unread,
May 7, 2024, 2:41:57 PM5/7/24
to codehau...@googlegroups.com
Hi John

The artifactInstaller is definitely the best way to go indeed 👍

The Maven artifact for Jetty 12 is under org.eclipse.jetty (groupId) and jetty-home (artifactId).

Regards


--
You received this message because you are subscribed to the Google Groups "Codehaus Cargo" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codehaus-carg...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/codehaus-cargo/24476872-a47d-4259-87d1-19bb45baf633n%40googlegroups.com.

John Domingo

unread,
May 8, 2024, 12:56:30 AM5/8/24
to Codehaus Cargo

Thanks Ali!  Much appreciated for the quick response.


So I was able to finally get it working with the Maven Cargo plugin using artifactInstaller (in execution - start and stop).


I did have a few other questions:


1.  I would like to get Maven Cargo and Jetty working using SSL (actually with mutual authentication).  I noticed that with the Maven Cargo + Tomcat configuration, you can set the identity keystore configuration and the trust store configuration via configuration settings (e.g., cargo.tomcat.connector.keystoreFile, cargo.tomcat.connector.truststoreFile, etc.).  I noticed that for the Cargo Jetty 12x documentation, there are no such configuration properties to use.  Are there configuration settings that will allow me to set these values (keystore, keystore type, password, etc.).  OR...is the only way to be able to set these settings for Jetty12x is to modify these is to actually configure Jetty config files (e.g., jetty-ssl-context.xml) with the appropriate settings, and then use the Maven Cargo plugin to override the configuration file???


2.  Does the Maven Cargo plugin also support code coverage instrumentation like Jetty does with JaCoCo??  I only ask because I have a requirement to be able to report on code coverage for integration tests that interact with the WAR application deployed to the servlet container (either embedded or not), and with Jetty you can pass in Failsafe arguments to be able to trigger instrumentation with the application code running within the servlet container, which make it possible to get code coverage results after integration test execution via JaCoCo.  I read through your documentation and did not notice support any information regarding using Maven Cargo with a container to capture code coverage through JaCoCo.  Is there a way to get those instrumentation results for code coverage with Maven Cargo?


Thanks!


Cheers!

John

S. Ali Tokmen

unread,
May 8, 2024, 2:00:39 AM5/8/24
to codehau...@googlegroups.com

Hi John

Great news!

Adding HTTPS support for Jetty has been in our backlog for some time (see https://codehaus-cargo.atlassian.net/issues/CARGO-977), if you want to give it a shot we gladly accept pull requests 🙂

Having said that, indeed it is probably possible to enable HTTPS using the https://codehaus-cargo.github.io/cargo/Configuration+files+option.html.

As for JaCoCo: I believe you'd use the JVM start arguments option, exactly as shown in https://codehaus-cargo.github.io/cargo/Debugging.html for debugging.

Does this help?

John Domingo

unread,
May 9, 2024, 2:55:19 AM5/9/24
to Codehaus Cargo
Thanks much Ali!

SO...I think I was able to get the config files updated correctly, using SSL/TLS and the keystore/truststore configured.  The issue I am having now is that apparently the cargo plugin does some sort of heartbeat with a deployed app called "cargocpc"...it basically tries to hit the index.html to determine if the container is running.  The problem is that with SSL enabled and mutual authentication being done, the connection is failing because the call to the webapp is not presenting a valid identity to the server (based on the trust chain).

Due to this, it seems like the plugin terminates the container after it times out (see error and stack trace after the sig below).

Is there way to disable the plugin's call to the "cargocpc" web apps "index.html"????  Or...is there a way to configure the call to "cargocpc" index.html to use a specific identity keystore?

Thanks again!

Cheers!
John

>>>>>>>>>>>>>>>>>

[ERROR] Starting container [org.codehaus.cargo.container.jetty.Jetty12xInstalledLocalContainer@58feb6b0] failed
org.codehaus.cargo.container.ContainerException: Deployable [https://localhost:9296/cargocpc/index.html] failed to finish deploying within the timeout period [120000]. The Deployable state is thus unknown.
    at org.codehaus.cargo.container.spi.deployer.DeployerWatchdog.watch (DeployerWatchdog.java:111)
    at org.codehaus.cargo.container.spi.AbstractLocalContainer.waitForCompletion (AbstractLocalContainer.java:424)
    at org.codehaus.cargo.container.spi.AbstractLocalContainer.start (AbstractLocalContainer.java:237)
    at org.codehaus.cargo.maven3.ContainerStartMojo.executeLocalContainerAction (ContainerStartMojo.java:83)
    at org.codehaus.cargo.maven3.ContainerRunMojo.doExecute (ContainerRunMojo.java:126)
    at org.codehaus.cargo.maven3.AbstractCargoMojo.execute (AbstractCargoMojo.java:466)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:126)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2 (MojoExecutor.java:328)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:316)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:212)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:174)
    at org.apache.maven.lifecycle.internal.MojoExecutor.access$000 (MojoExecutor.java:75)
    at org.apache.maven.lifecycle.internal.MojoExecutor$1.run (MojoExecutor.java:162)
    at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute (DefaultMojosExecutionStrategy.java:39)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:159)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:105)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:73)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:53)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:118)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:906)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:77)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:568)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:283)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:226)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:407)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:348)

S. Ali Tokmen

unread,
May 9, 2024, 3:23:41 AM5/9/24
to codehau...@googlegroups.com

Hi John

Well done 🙂 Let us know if you want to contribute with a PR, for a "proper" HTTPS support for Jetty.

The Cargo Ping Component is the "only" way we have in Jetty, and it uses the same Java VM as your Maven. Hence, if you add the trust in your Maven's JVM, or add the Java options to ignore signatures, it would do the trick.

S. Ali Tokmen

unread,
May 10, 2024, 2:23:00 AM5/10/24
to codehau...@googlegroups.com

Hi John

I had a closer look, and observed adding HTTPS in Jetty 10.x onwards is quite simple, so commited https://github.com/codehaus-cargo/cargo/commit/d84674aa9a42bcd60165f4b9c847aef59cbeb032 which cllses the below JIRA.

What I noticed as well, this is doable with the current version of Codehaus Cargo:

  1. Make use of the cargo.jetty.modules property to add the https module
  2. Add the 3 mandatory JVM properties: jetty.ssl.port, jetty.sslContext.keyStorePath and jetty.sslContext.keyStorePassword, as explained on https://codehaus-cargo.github.io/cargo/Passing+system+properties.html

Let me know if this helps as well, with the below instructions you get a Jetty which is configured to deliver over HTTP and HTTPS at the same time.

John Domingo

unread,
May 18, 2024, 7:36:09 AM5/18/24
to codehau...@googlegroups.com
Hi Ali!!!

Thanks for the follow up.  My apologies for not responding sooner, but your suggestion to specify the properties as JVM properties actually did the trick.  I configured the Maven Cargo plugin (using local Jetty option) in my POM to use http, but, as you indicated, by setting the appropriate Jetty properties as JVM arguments allowed me to configure the Truststore, Identity Keystore, as well as specify the Https port, and enable mutual authentication (want not need property).

Based on this, I am able to have, not only my service being tested (using Jetty Maven plugin, configured with coverage instrumentation), but also a dependent war (in same module project) running using Cargo Maven plugin with a local Jetty 12x instance.

Again, wanted to express my thanks for your quick responses as well as your great direction.

Thanks Ali!

Cheers!
John


S. Ali Tokmen

unread,
May 21, 2024, 1:00:52 PM5/21/24
to codehau...@googlegroups.com

Hi John

Fantastic news! 🙂

With Codehaus Cargo 1.10.14 (once released) this should become even easier, with https://codehaus-cargo.atlassian.net/issues/CARGO-977 implemented and also https://codehaus-cargo.github.io/cargo/Containers+with+HTTPS+support.html explaining HTTPS support on Jetty 10.x onwards (both for setups having HTTP and HTTPS, or of course HTTPS-only).

Reply all
Reply to author
Forward
0 new messages