Using jetty properties with the Jetty Maven Plugin

[lachlan-roberts]

Jetty version(s)
12.0.x

The Jetty 12 documentation lists several different methods to configure Jetty properties for the Jetty Maven Plugin.
However I cannot get these to work, I can only get the systemProperties option to work.

I am using mvn jetty:run with a deployMode of EXTERNAL.

jettyOptions Configuration

The "In a jetty distribution" section lists the jettyOptions configuration parameter. Which is described as a "A space separated string representing extra arguments to the synthesized Jetty command line".

I have tried this and it does not work.

<plugin>
  <groupId>org.eclipse.jetty.ee10</groupId>
  <artifactId>jetty-ee10-maven-plugin</artifactId>
  <version>${jetty.version}</version>
  <configuration>
    <deployMode>EXTERNAL</deployMode>
    <jettyOptions>jetty.server.dumpAfterStart=true</jettyOptions>
  </configuration>
</plugin>

jettyProperties Configuration

The common configuration section lists the jettyProperties configuration described as "a map of property name, value pairs. Allows you to configure standard jetty properties".

<plugin>
  <groupId>org.eclipse.jetty.ee10</groupId>
  <artifactId>jetty-ee10-maven-plugin</artifactId>
  <version>${jetty.version}</version>
  <configuration>
    <deployMode>EXTERNAL</deployMode>
    <jettyProperties>
      <jetty.server.dumpAfterStart>true</jetty.server.dumpAfterStart>
    </jettyProperties>
  </configuration>
</plugin>

systemProperties Configuration

I managed to get the dump working with system properties. Like this

<plugin>
  <groupId>org.eclipse.jetty.ee10</groupId>
  <artifactId>jetty-ee10-maven-plugin</artifactId>
  <version>${jetty.version}</version>
  <configuration>
    <deployMode>EXTERNAL</deployMode>
    <systemProperties>
      <jetty.server.dumpAfterStart>true</jetty.server.dumpAfterStart>
    </systemProperties>
  </configuration>
</plugin>

However the documentation for this is lacking as it doesn't specify whether this is a space separated string or a map (it is a map).

[janbartel]

@lachlan-roberts make sure you're using an up to date HEAD. There have been some changes in the ordering of properties on the jetty start line (since environments were introduced) that means that a property has to be defined before the module that uses it. I've only recently discovered and fixed this for the jetty maven plugin - we were following the start command line doco which said that properties should be at the end of the command (btw it needs updating - think I already raised an issue for @gregw for that). So jettyProperties are now output in the generated commmand line before the modules. It is definitely working, otherwise the maven it tests fail as we use a jetty property to carry the port number to use. For the 'jettyOptions' they are still being output at the end of the command as per the existing start doco - but you're trying to define a property that is interpreted by the server module which is defined much earlier in the command line so that won't work. If you changed your test to use something other than a jetty property in the jettyOptions I'm pretty sure you'll find it will work as we have an it test that enables --debug via a jettyOptions element and I can confirm I can see startup debug logging happening.

So in short, I think this is a documentation problem, so I'll change the label on this issue.

[janbartel]

Actually, just to clarify, the problem is with the help text generated by java -jar ${jetty.home}/start.jar --help. It says the syntax is:

$ java -jar $JETTY_HOME/start.jar [command] [options...]

Then describes setting jetty properties in the Options section, however any properties used by anything earlier in the [command] or even [options] sections must be specified on the command line prior. So this is a code change to the start code to correct the generated help text.

[lachlan-roberts]

@janbartel yes I just checked and on 12.0.13-SNAPSHOT the jettyProperties work, just not on 12.0.12.
So seems like that bug was already resolved.

Then describes setting jetty properties in the Options section, however any properties used by anything earlier in the [command] or even [options] sections must be specified on the command line prior. So this is a code change to the start code to correct the generated help text.

Not sure what you mean by this.

The --help command specifies that properties can be listed in the options section.

Options:
--------

...

<name>=<value>
                  Specifies a property value that overrides the same
                  property defined in a ${jetty.base}/start.d/*.ini file

And adding the system property here works just not the jetty property.
I get the dump by using <jettyOptions>-Djetty.server.dumpAfterStart=true</jettyOptions>.

[olamy]

fixed with #12183
?

[janbartel]

@janbartel yes I just checked and on 12.0.13-SNAPSHOT the jettyProperties work, just not on 12.0.12. So seems like that bug was already resolved.

As @olamy said, I did it in #12183.

Then describes setting jetty properties in the Options section, however any properties used by anything earlier in the [command] or even [options] sections must be specified on the command line prior. So this is a code change to the start code to correct the generated help text.

Not sure what you mean by this.

The --help command specifies that properties can be listed in the options section.

Options:
--------

...

<name>=<value>
                  Specifies a property value that overrides the same
                  property defined in a ${jetty.base}/start.d/*.ini file

Yes but if you see the command line syntax, [options] are listed last. So if you put a property last that is relied upon by an xml file named by a module in the earlier [commands] section, it won't work: the property must come before the module is named.

And adding the system property here works just not the jetty property. I get the dump by using <jettyOptions>-Djetty.server.dumpAfterStart=true</jettyOptions>.
Possibly the start process treats System properties differently when it parses the command line.

[lachlan-roberts]

Yes but if you see the command line syntax, [options] are listed last. So if you put a property last that is relied upon by an xml file named by a module in the earlier [commands] section, it won't work: the property must come before the module is named.

Is this a Jetty Maven Plugin specific thing? Because I can do this on command line and it works fine.

java -jar jetty-home/start.jar --modules=server,http jetty.server.dumpAfterStart=true

[janbartel]

That won't work if you enable any of the ee specific modules. Take a look at #12183 .

This is what happens if you enable an ee specific module on the command line with the property at the end:

janb@silver: ~/src/jetty-eclipse/jetty-12.0.x/jetty-home/target/base (jetty-12.0.x)
[2192] java -jar ../jetty-home/start.jar --modules=server,http,ee10-deploy jetty.server.dumpAfterStart=true
2024-09-04 14:49:34.696:INFO :oejs.Server:main: jetty-12.0.13-SNAPSHOT; built: 2024-09-03T04:06:48.211Z; git: e2a3eeabc4151aa023208ee66332a9541e8067bb; jvm 22+36-2370
2024-09-04 14:49:34.715:INFO :oejdp.ScanningAppProvider:main: Deployment monitor ee10 in [file:///home/janb/src/jetty-eclipse/jetty-12.0.x/jetty-home/target/base/webapps] at intervals 0s
2024-09-04 14:49:34.715:WARN :oejdp.ScanningAppProvider:main: Does not exist: file:///home/janb/src/jetty-eclipse/jetty-12.0.x/jetty-home/target/base/webapps
2024-09-04 14:49:34.716:INFO :oejs.DefaultSessionIdManager:main: Session workerName=node0
2024-09-04 14:49:34.725:INFO :oejs.AbstractConnector:main: Started ServerConnector@52102734{HTTP/1.1, (http/1.1)}{0.0.0.0:8080}
2024-09-04 14:49:34.736:INFO :oejs.Server:main: Started oejs.Server@2cd76f31{STARTING}[12.0.13-SNAPSHOT,sto=5000] @789ms
^C2024-09-04 14:49:36.843:INFO :oejs.Server:JettyShutdownThread: Stopped oejs.Server@2cd76f31{STOPPING}[12.0.13-SNAPSHOT,sto=5000]
2024-09-04 14:49:36.843:INFO :oejs.Server:JettyShutdownThread: Shutdown oejs.Server@2cd76f31{STOPPING}[12.0.13-SNAPSHOT,sto=5000]
2024-09-04 14:49:36.851:INFO :oejs.AbstractConnector:JettyShutdownThread: Stopped ServerConnector@52102734{HTTP/1.1, (http/1.1)}{0.0.0.0:8080}

[lachlan-roberts]

Yep okay, that makes sense.

So since the bugs are already fixed with 12.0.13.
I can just do a bit of an update on the docs to make it a bit clearer.