Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deal with wildfly-core upgrade to jboss-logging 3.6.x #244

Open
simkam opened this issue Sep 16, 2024 · 2 comments · May be fixed by #245
Open

Deal with wildfly-core upgrade to jboss-logging 3.6.x #244

simkam opened this issue Sep 16, 2024 · 2 comments · May be fixed by #245

Comments

@simkam
Copy link
Collaborator

simkam commented Sep 16, 2024

After WFCORE-6883, wildfly-core was updated to depend on the new jboss-logging version, which comes with some new methods. At the same time, Wildly Integration was updated to use those new methods.

Because of that, we started to see many issues like:

java.lang.NoSuchMethodError: 'java.lang.Object org.jboss.logging.Logger.getMessageLogger(java.lang.invoke.MethodHandles$Lookup, java.lang.Class, java.lang.String)' at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365) at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)

or
 

java.lang.NoSuchMethodError: 'java.lang.Object org.jboss.logging.Logger.getMessageLogger(java.lang.invoke.MethodHandles$Lookup, java.lang.Class, java.lang.String)' at org.jboss.as.protocol.logging.ProtocolLogger.<clinit>(ProtocolLogger.java:37) at org.jboss.as.protocol.mgmt.AbstractMessageHandler.registerActiveOperation(AbstractMessageHandler.java:387) at org.jboss.as.protocol.mgmt.AbstractMessageHandler.registerActiveOperation(AbstractMessageHandler.java:336) at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:92) at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:249) at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:154) at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:133) at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:61) at org.wildfly.extras.creaper.core.online.OnlineOptions.connectAndWaitUntilServerBoots(OnlineOptions.java:449) at org.wildfly.extras.creaper.core.online.OnlineOptions.createModelControllerClient(OnlineOptions.java:423) at org.wildfly.extras.creaper.core.online.OnlineManagementClientImpl.connect(OnlineManagementClientImpl.java:42) at org.wildfly.extras.creaper.core.online.OnlineManagementClientImpl.<init>(OnlineManagementClientImpl.java:38) at org.wildfly.extras.creaper.core.online.OnlineOptions$2.create(OnlineOptions.java:493) at org.wildfly.extras.creaper.core.ManagementClient.online(ManagementClient.java:36)

From quick investigation, it seems the problem might be that the version of jboss-logging in the dependency tree is lower than 3.6.0 (and thus missing the new method)—IOW, we have a dependency on recent enough wildfly-core / wildfly-cli that tries to use that new method.
wildfly-core / wildfly-cli depends on new jboss-logging so that is not a problem but some other artifact's transitive jboss-logging (older) is resolved by maven.

So far, the only viable solution we have come up with is updating all test suites and tooling projects to depend on the latest jboss-logging 3.6.x. We hope we will not have to change that for another ten years like was the case with previous versions.

Alternatively we could remove explicit dependency on jboss-logging and allow it to be transitive (through WildFly Core ideally).

There is one change though - jboss-logging 3.6.x is JDK11+ only which isn't the problem for EAP 8.x testsuites but might be for some tooling projects (like Creaper) so we need to deal with that too.
 

simkam added a commit to simkam/creaper that referenced this issue Sep 16, 2024
fixes wildfly-extras#244

It attempts to fix issue due to current dependecy situation:
* creaper has explicit dependency on jboss-logging 3.3.0.Final
* jboss-logging added new methods in 3.6.0
* wildfly-core uses new methods from jboss-logging 3.6.x since 26.0.0.Beta3 which means WildFly 34
* it results in wildfly-extras#244

Let's bring in jboss-logging transitivitely from wildfly-core to keep version aligned.

----

Originally jboss-logging dependency was added with this commit message

```
OnlineManagementClient and OfflineManagementClient now log all commands
and operations they are performing. Operations (online only) are logged
on the DEBUG level, commands are logged on INFO. Also, commands are now
advised to provide a toString() method that is used for logging.

The logging framework that is used in Creaper is JBoss Logging, because:

1. It is not actually a logging framework, it's only a facade that delegates
   the logging work to some logging framework that appears to be used.
2. It can detect all commonly used logging frameworks (Logback, Log4j, JUL)
   and one uncommon too (JBoss LogManager).
3. Creaper already depended on it transitively. Avoiding new dependencies
   is good.
4. It has a really small and nice API.
```
@simkam simkam linked a pull request Sep 16, 2024 that will close this issue
@mchoma
Copy link
Collaborator

mchoma commented Sep 26, 2024

@dosu are you already here?

Copy link

dosubot bot commented Sep 26, 2024

@mchoma Hello there! I'm here to assist you with any issues you're facing. If you need help with bugs, have questions, or want to become a contributor, I'm here to help while you wait for a human maintainer.

Yes, I'm here. To resolve the java.lang.NoSuchMethodError issues caused by the jboss-logging 3.6.x upgrade in WildFly Core, you need to ensure that the correct version of jboss-logging is used throughout the Creaper project. Here are the steps to address this:

  1. Update jboss-logging Version:
    Update the jboss-logging version in your pom.xml to a compatible version that matches the WildFly Core requirements. Since jboss-logging 3.6.x is JDK11+ only, you will need to ensure that your project is compatible with JDK 11 or higher.

    <properties>
        ...
        <version.org.jboss.logging.jboss-logging>3.6.0.Final</version.org.jboss.logging.jboss-logging>
        ...
    </properties>
    
    <dependencyManagement>
        <dependencies>
            ...
            <dependency>
                <groupId>org.jboss.logging</groupId>
                <artifactId>jboss-logging</artifactId>
                <version>${version.org.jboss.logging.jboss-logging}</version>
            </dependency>
            ...
        </dependencies>
    </dependencyManagement>
  2. Ensure JDK Compatibility:
    Since jboss-logging 3.6.x requires JDK 11+, you need to update the JDK version specified in your build configuration. Currently, the Creaper project specifies JDK 1.8:

    <version.java>1.8</version.java>

    Update this to JDK 11:

    <version.java>11</version.java>
  3. Check for Transitive Dependencies:
    Ensure that no other dependencies are pulling in an older version of jboss-logging. You can use the mvn dependency:tree command to inspect the dependency tree and identify any such issues.

  4. Remove Explicit Dependencies (Optional):
    If feasible, consider removing the explicit dependency on jboss-logging and allow it to be resolved transitively through WildFly Core. This can help avoid version conflicts.

By following these steps, you should be able to resolve the NoSuchMethodError issues and ensure compatibility with the latest jboss-logging version [1][2][3].

Would you like more detailed guidance on implementing these solutions?

To continue talking to Dosu, mention @dosu.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants