leshan
leshan copied to clipboard
eclipse-leshan
SLF4J 2.0.X?
Is there a reason to keep master on SLF4J 1.7.X? For example eclipse jetty 11 uses slf4j 2.0 now
See: https://www.slf4j.org/faq.html#changesInVersion200
I tried to upgrade :joy:
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary for leshan 2.0.0-SNAPSHOT:
[INFO]
[INFO] leshan - core ...................................... SUCCESS [ 12.051 s]
[INFO] leshan - core californium .......................... FAILURE [ 2.892 s]
[INFO] leshan - server core ............................... SKIPPED
[INFO] leshan - server californium ........................ SKIPPED
[INFO] leshan - server redis .............................. SKIPPED
[INFO] leshan - client core ............................... SKIPPED
[INFO] leshan - client californium ........................ SKIPPED
[INFO] leshan - integration tests ......................... SKIPPED
[INFO] leshan - core demo ................................. SKIPPED
[INFO] leshan - client demo ............................... SKIPPED
[INFO] leshan - server core demo .......................... SKIPPED
[INFO] leshan - server demo ............................... SKIPPED
[INFO] leshan - bootstrap server demo ..................... SKIPPED
[INFO] leshan ............................................. SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 15.914 s
[INFO] Finished at: 2022-10-26T16:29:43+02:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.revapi:revapi-maven-plugin:0.14.7:check (default) on project leshan-core-cf: The following API problems caused the build to fail:
[ERROR] java.class.externalClassExposedInAPI: enum org.slf4j.event.Level: A class from supplementary archives is used in a public capacity in the API. [org.slf4j:slf4j-api:jar:2.0.3]
[ERROR] java.class.externalClassExposedInAPI: interface org.slf4j.spi.LoggingEventBuilder: A class from supplementary archives is used in a public capacity in the API. [org.slf4j:slf4j-api:jar:2.0.3]
[ERROR]
[ERROR] Consult the plugin output above for suggestions on how to ignore the found problems.
No a good one :wink:
Last time, I tried to do that I fall on this revapi issue. (I see you fall to the same one :grin:)
And so I started a discussion about this at : https://github.com/revapi/revapi/issues/276
I'm happy to have open that question before digging the same rabbit hole as you :joy:
Can we just /ignore revapi?
I report the use case to revapi maintainer but I mainly wanted to better understand the issue before to ignore it.
For now, I'm not sure if I correctly understand it and I'm not so sure what is the right way to "ignore" it.
to ignore I use:
iff --git a/build-config/lib-build-config/pom.xml b/build-config/lib-build-config/pom.xml
index cdc503db..2320381b 100644
--- a/build-config/lib-build-config/pom.xml
+++ b/build-config/lib-build-config/pom.xml
@@ -89,6 +89,12 @@ Contributors:
<match>/org\.eclipse\.californium(\..*)?/</match>
</item>
</exclude>
+ <exclude>
+ <item>
+ <matcher>java-package</matcher>
+ <match>/org\.slf4j(\..*)?/</match>
+ </item>
+ </exclude>
</elements>
</revapi.filter>
</analysisConfiguration>
If we really need sl4j 2.0.x now we can go in that way but I'm not totally sure this will not hide some real API issue/warning like explain at https://github.com/revapi/revapi/issues/186. :shrug:
This would also mean upgrading logback from 1.2.x https://logback.qos.ch/news.html
Yep from 1.2.x to 1.3.x. Logback is just used in demo and for junit tests.
looks like more work than just bumping the version in the pom
17:10:07,718 |-INFO in ch.qos.logback.classic.LoggerContext[default] - This is logback-classic version 1.3.4
17:10:07,747 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [logback-leshan-test.xml] at [file:/home/jvermillard/sandbox/leshan/leshan-client-core/logback-leshan-test.xml]
17:10:07,941 |-INFO in ch.qos.logback.core.model.processor.AppenderModelHandler - Processing appender named [STDOUT]
17:10:07,941 |-INFO in ch.qos.logback.core.model.processor.AppenderModelHandler - About to instantiate appender of type [ch.qos.logback.core.ConsoleAppender]
17:10:07,948 |-INFO in ch.qos.logback.core.model.processor.ImplicitModelHandler - Assuming default type [ch.qos.logback.classic.encoder.PatternLayoutEncoder] for [encoder] property
17:10:08,002 |-ERROR in ch.qos.logback.classic.pattern.ClassOfCallerConverter@463d3018 - failed to parse integer string [1.] java.lang.NumberFormatException: For input string: "1."
at java.lang.NumberFormatException: For input string: "1."
at at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:67)
at at java.base/java.lang.Integer.parseInt(Integer.java:668)
at at java.base/java.lang.Integer.parseInt(Integer.java:786)
at at ch.qos.logback.classic.pattern.NamedConverter.start(NamedConverter.java:92)
at at ch.qos.logback.core.pattern.ConverterUtil.startConverters(ConverterUtil.java:37)
at at ch.qos.logback.core.pattern.PatternLayoutBase.start(PatternLayoutBase.java:90)
at at ch.qos.logback.classic.encoder.PatternLayoutEncoder.start(PatternLayoutEncoder.java:28)
at at ch.qos.logback.core.model.processor.ImplicitModelHandler.postHandleComplex(ImplicitModelHandler.java:208)
at at ch.qos.logback.core.model.processor.ImplicitModelHandler.postHandle(ImplicitModelHandler.java:186)
at at ch.qos.logback.core.model.processor.DefaultProcessor.secondPhaseTraverse(DefaultProcessor.java:257)
at at ch.qos.logback.core.model.processor.DefaultProcessor.secondPhaseTraverse(DefaultProcessor.java:253)
at at ch.qos.logback.core.model.processor.DefaultProcessor.secondPhaseTraverse(DefaultProcessor.java:253)
at at ch.qos.logback.core.model.processor.DefaultProcessor.traversalLoop(DefaultProcessor.java:90)
at at ch.qos.logback.core.model.processor.DefaultProcessor.process(DefaultProcessor.java:106)
at at ch.qos.logback.core.joran.GenericXMLConfigurator.processModel(GenericXMLConfigurator.java:200)
at at ch.qos.logback.core.joran.GenericXMLConfigurator.doConfigure(GenericXMLConfigurator.java:166)
at at ch.qos.logback.core.joran.GenericXMLConfigurator.doConfigure(GenericXMLConfigurator.java:122)
at at ch.qos.logback.core.joran.GenericXMLConfigurator.doConfigure(GenericXMLConfigurator.java:65)
at at ch.qos.logback.classic.util.DefaultJoranConfigurator.configureByResource(DefaultJoranConfigurator.java:53)
at at ch.qos.logback.classic.util.DefaultJoranConfigurator.configure(DefaultJoranConfigurator.java:34)
at at ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:98)
at at ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:77)
at at ch.qos.logback.classic.spi.LogbackServiceProvider.initializeLoggerContext(LogbackServiceProvider.java:50)
at at ch.qos.logback.classic.spi.LogbackServiceProvider.initialize(LogbackServiceProvider.java:41)
at at org.slf4j.LoggerFactory.bind(LoggerFactory.java:152)
at at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:139)
at at org.slf4j.LoggerFactory.getProvider(LoggerFactory.java:422)
at at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:408)
at at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:357)
at at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:383)
at at org.eclipse.leshan.core.model.StaticModel.<clinit>(StaticModel.java:32)
at at org.eclipse.leshan.client.util.BaseInstanceEnablerFactoryTest.<clinit>(BaseInstanceEnablerFactoryTest.java:36)
at at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
at at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
at at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)
at at org.junit.runners.BlockJUnit4ClassRunner.createTest(BlockJUnit4ClassRunner.java:250)
at at org.junit.runners.BlockJUnit4ClassRunner.createTest(BlockJUnit4ClassRunner.java:260)
at at org.junit.runners.BlockJUnit4ClassRunner$2.runReflectiveCall(BlockJUnit4ClassRunner.java:309)
at at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at at org.junit.runners.BlockJUnit4ClassRunner.methodBlock(BlockJUnit4ClassRunner.java:306)
at at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at at org.apache.maven.surefire.junitcore.pc.Scheduler$1.run(Scheduler.java:405)
at at org.apache.maven.surefire.junitcore.pc.InvokerStrategy.schedule(InvokerStrategy.java:54)
at at org.apache.maven.surefire.junitcore.pc.Scheduler.schedule(Scheduler.java:362)
at at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at at org.junit.runners.Suite.runChild(Suite.java:128)
at at org.junit.runners.Suite.runChild(Suite.java:27)
at at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at at org.apache.maven.surefire.junitcore.pc.Scheduler$1.run(Scheduler.java:405)
at at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
at at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at at java.base/java.lang.Thread.run(Thread.java:833)
The plugin output of Revapi which suggests how to ignore the found problems, should also include the exampleUseChainInNewApi and/or exampleUseChainInOldApi. These two should give you an idea how the classes ended up in the transitive closure of your API as computed by Revapi.
So moving to SLF4J 2 you need to move to logback 1.3.X, but pulling logback 1.3.X comes with: javax.servlet:javax.servlet-api:jar:4.0.1:compile
But jetty pull servlet 3 API, and for moving to servlet 4 you need to switch to the java 11 branch:
As I guess that we don't use code from logback which used javax.servlet:javax.servlet-api
We can try to just exclude this dependency with something like :
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>${logback.version}</version>
<exclusions>
<exclusion>
<!-- we exclude servlet-api dependencies because of dependency convergence issue with jetty
See: https://github.com/eclipse/leshan/issues/1339#issuecomment-1293221705 -->
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
</exclusion>
</exclusions>
</dependency>
#1340 is integrated in master but I let this issue open to remember to remove the HACK when https://github.com/revapi/revapi/issues/186 will be fixed.