dump jar paths in ModuleClassLoader

[basinilya1]

Hi.

For troubleshooting I want to see what the current classpath is.

org.jboss.modules.ModuleClassLoader has no getURLs() method. Is it possible to get this info?

private static void printClassloader0(final PrintWriter pw, final ClassLoader cl)
                                                                                  throws Exception {
    log(pw, cl);
    if (cl instanceof URLClassLoader) {
        final URLClassLoader ucl = (URLClassLoader) cl;
        log(pw, Arrays.asList(ucl.getURLs()));
    } else if (cl instanceof ModuleClassLoader) {
        final ModuleClassLoader mcl = (ModuleClassLoader) cl;
        ???
    }
    final ClassLoader parent = cl.getParent();
    if (parent != null && parent != cl) {
        printClassloader0(pw, parent);
    }
}

[zhurlik]

Hi,

I guess it could help you ModuleClassLoader : How can I retrieve the classpath from the loader

Thanks,

Vlad

[basinilya1]

The problem with calling getResources() is it recursively scans parent classloaders and you can't tell which resource belongs to which classloader. Isn't there a way to iterate resource-roots and dependencies of modules?

Besides, you have to pass a real folder name to that method, e.g. "/META-INF". Passing just a forward slash works for file:/ resources, but not for jar: resources. Not all jars contain a META-INF folder.

[yersan]

I haven't found either a way to get this information directly via JBoss Modules API.

Just in case it could help you somehow, via CLI there are a couple of operations that can be used to get information related, probably they won't fit at all on your use case, but, they could be useful to understand the classpath of your deployed application.

- Since WF16, you can list the JBoss Modules modules the server has added to your deployed application, see Developer Guide

- Via CLI, there is also an operation that can list root resources a JBoss Modules module has. It is deprecated because it was added as an experimental feature but it can still be used to get some information. This operation is also available via JMX (MBeans->jboss.as->module-loading -> operations on the jconsole)

[standalone@localhost:9990 /] /core-service=module-loading:list-resource-loader-paths(module=io.undertow.core)
{
    "outcome" => "success",
    "response-headers" => {"warnings" => [{
        "warning" => "WFLYCTL0449: Operation list-resource-loader-paths against the resource at address /core-service=module-loading is deprecated, and it might be removed in future version. See the the output of the read-operation-description operation to learn more about the deprecation.",
        "level" => "WARNING",
        "operation" => {
            "address" => [("core-service" => "module-loading")],
            "operation" => "list-resource-loader-paths"
        }
    }]},
    "result" => [
        "/wildfly/dist/target/wildfly-19.0.0.Beta2-SNAPSHOT/modules/system/layers/base/io/undertow/core/main/undertow-core-2.0.29.Final.jar",
        "/wildfly/dist/target/wildfly-19.0.0.Beta2-SNAPSHOT/modules/system/layers/base/io/undertow/core/main/lib"
    ]
}

[zhurlik]

Hi,

Sometimes I use jconsole to view information about modules, probably it will help you to figure out which MBean method can be used for getting the required information

There are a couple of interesting methods which you can invoke under: MBeans->jboss.modules

Thanks,

Vlad

[ctomc]

yersan  wrote:

- Via CLI, there is also an operation that can list root resources a JBoss Modules module has. It is deprecated because it was added as an experimental feature but it can still be used to get some information.

It was initially added as deprecated as it was using reflection to get jboss modules internals to display this data. But given that is now using public JMX api from jboss-modules, operation as such could be un-deprecated, wdyt?

[yersan]

Hey ctomc

The public JMX api is not available outside of the JMX world and the deprecation is also related to whether the internal functionality is fully supported on EAP. It seems is not so easy to un-deprecate the CLI use of this operation without an strong case supporting it.

[ctomc]

JMX api can be access from outside world (remote jmx, jconsole, ...) which makes it de facto public api.

And as such is "full supporteded" at least the jboss-modules part of the api

Wildfly side is as you said, different.