Force Jetty Maven Plugin to use SLF4J for it's own logs

[timmacp]

Jetty Version
Jetty Maven Plugin version 11.0.24 12.0.19

Jetty Environment

Java Version
17

Question
Using logback classic: logs written in the application work as expected
but Jetty's own logs are still using JUL as evidenced by the level WARNING instead of the SLF4J level WARN.
Formatting as in logback.xml is ignored.
No such issue occurs when using embedded Jetty started in main().

[joakime]

Jetty Version Jetty Maven Plugin version 11.0.24

First, Jetty 11 is now at EOL, and shouldn't be used anymore.

• EOL (End of Life) for Jetty 10 / Jetty 11 - January 2025 #10485

Upgrade to a supported version of Jetty. Which is Jetty 12 at this point in time.

but Jetty's own logs are still using JUL as evidenced by the level WARNING instead of the SLF4J level WARN.

Jetty itself does not use java.util.logging.
You might be encountering a 3rd party library that uses java.util.logging.

With slf4j, you can route java.util.logging to slf4j-api, which is then picked up by logback for formatting.
See the slf4j manual for details on how to set that up.

If you use Jetty 12, just enable the logging-jul-capture module to have that auto-wired for you.

One last thing, maven uses slf4j too.

[timmacp]

Thanks, I started with jetty-ee10-maven-plugin version12.0.19.
There seem to be subtle differences in how the plugin interacts with Maven profiles or how it handles resource bases in this new version ? I can no longer activate a profile by:
<activation> <activeByDefault>true</activeByDefault></activation>

or
<activation> <property> ...

It runs if resource bases are moved into the plugin configuration in the main section.
Is this a known change since version 11 ?

I need 2 profiles for 2 different resource bases so I'm hoping the plugin can deal with more explicit activation using -P.

[joakime]

@olamy can you answer this?

[olamy]

Thanks, I started with jetty-ee10-maven-plugin version12.0.19. There seem to be subtle differences in how the plugin interacts with Maven profiles or how it handles resource bases in this new version ? I can no longer activate a profile by: <activation> <activeByDefault>true</activeByDefault></activation>

or <activation> <property> ...

It runs if resource bases are moved into the plugin configuration in the main section. Is this a known change since version 11 ?

I need 2 profiles for 2 different resource bases so I'm hoping the plugin can deal with more explicit activation using -P.

As is, I cannot see any real reasons for this. Maven profiles' activation is managed by Maven core, and this shouldn't have anything to do with the Jetty plugin.
@timmacp do you have any simple example to reproduce this?
Thanks

[timmacp]

My fault, omission in the upgrade

[olamy]

@timmacp no worries. Can we close this issue? or do you still need some answers?

[timmacp]

Using <deployMode>EXTERNAL</deployMode>

& enabling logging-jul-capture like this:
<modules> <module>logging-jul-capture</module> </modules>

then logging-jul-capture module seems to get registered:

`[INFO] Configuring Jetty for project: historyTrees-server
...
[INFO] Home process starting
WARN : Forking second JVM due to forking module(s): [logging-jul-capture]. Use --dry-run to generate the command line to avoid forking

Jetty's logs now appear in the default SLF4J provider's format
in red eg:
2025-04-10 11:44:42.227:WARN :oejshC.maven_ee10:qtp815674463-38: Exception while dispatching incoming RPC call
previously it was giving WARNING as for JUL.

Without <module>logging-jul-capture</module> :
in contextInitialized() a JUL handler is found: java.util.logging.ConsoleHandler

There's still a problem with logback:
The next log says:
"Unable to get public no-arg constructor" for ch.qos.logback.classic.spi.LogbackServiceProvider,
suggests the classloader doesn't have access to the necessary Logback classes.

Next the logback initialization logs appear:
They show that logback.xml is found in /resources but these only affect logs produced in the app.
logback-classic is a dependency in jetty-ee10-maven-plugin and also in the main <dependencies> section
and logback-core is pulled in.

I tried putting
-classpath ${maven.dependency.classpath} in <jvmArgs>
OR -classpath %classpath;${maven.dependency.classpath}

but these didn't help, maybe you have the answer ?
Thanks

[joakime]

There's still a problem with logback:
The next log says:
"Unable to get public no-arg constructor" for ch.qos.logback.classic.spi.LogbackServiceProvider,
suggests the classloader doesn't have access to the necessary Logback classes.

What version of logback are you using?
It has to be compatible with slf4j-api 2.x, not the older 1.6.x versions.

[timmacp]

logback-classic version 1.5.18 seems to be the latest (Mar 18, 2025) , and slf4j.version 2.0.16

[timmacp]

The previous error in resolving LogbackServiceProvider
was due to the plugin not resolving the transitive dependency logback-core when
logback-classic is declared in the plugin - no error if declared in the main dependencies.

Question now is how to remove the default Jetty SLF4J binding ?

[github-actions]

This issue has been automatically marked as stale because it has been a
full year without activity. It will be closed if no further activity occurs.
Thank you for your contributions.