WF 39.0.1: CLI command module-info does not work in embedded mode

[Andreas Liebscher]

From CLI based installation scripts I tried to replace the usage of deprecated method /core-service=module-loading/:list-resource-loader-paths(module=xxx) with /core-service=module-loading/:module-info(name=xxx,slot="main"). In embedded mode the outcome is always (outcome != success). Isn't this behaviour a bug of the method module-info?

[Brian Stansberry]

This works for me.

$ bin/jboss-cli.sh
You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
[disconnected /] embed-server
[standalone@embedded /] /core-service=module-loading/:module-info(name=org.jboss.as.controller,slot=main)
{
    "outcome" => "success",
    "result" => {
        "name" => "org.jboss.as.controller",
        "main-class" => undefined,
        "fallback-loader" => undefined,
        "dependencies" => [
            {
                "dependency-name" => "ModuleDependency",
                "module-name" => "java.base",
                "export-filter" => "Reject",
                "import-filter" => "multi-path filter {exclude children of \"META-INF/\", exclude equals \"META-INF\", default accept}",
                "optional" => false
            },

           ....

[Andreas Liebscher]

Perhaps the problem occurs only with non-system modules (located under modules directly, not under modules/system/layers/base)?

I use embed-server --server-config=standalone-full.xml.

[James Perkins]

I do see an issue as well with a custom installed module:
[standalone@embedded /] /core-service=module-loading:module-info(name=jakarta.tck.appclient, slot=main)
{
    "outcome" => "failed",
    "failure-description" => "WFLYSRV0232: Could not get module info for module name: jakarta.tck.appclient",
    "rolled-back" => true
}

And the module exists:
wildfly/modules/jakarta/tck/appclient/main/
total 756
-rw-r--r--. 1 jperkins jperkins 155471 May  6 05:12 arquillian-protocol-lib.jar
-rw-r--r--. 1 jperkins jperkins    715 May  7 10:53 module.xml
-rw-r--r--. 1 jperkins jperkins 586292 Mar  9 11:56 tck-common.jar
-rw-r--r--. 1 jperkins jperkins   3978 May  6 05:12 tck-porting-lib.jar
-rw-r--r--. 1 jperkins jperkins  16941 May  7 10:53 wildfly-tck-common.jar

The difference is, it's likely not active in an embedded server given there are no deployments which would activate it. Whether this is a bug or not, I'm not sure. There is no real info to give, given the module isn't actually loaded.

[Andreas Liebscher]

I just need to check if a module is already installed.

Even in embedded mode the module-info could parse the directory and module.xml decriptor...

[Brian Stansberry]

Andreas, can you file a WFCORE Feature Request JIRA for this?. It will take some thought to determine how far to go with the concept of handling as-yet-unloaded modules. I don't see us wanting to do any kind of parsing etc, at least not for this resource, but perhaps it could ask JBoss Modules to load the module if it's not already loaded. That has downsides too though, since now it's changing the server's running state. The module load could also fail, e.g. if some dependency is missing. Perhaps that is ok though; if it can't load it's the same as if it's not present.

James, does your example work if you're not using an embedded server? I don't see why embedded vs not would be relevant. It seems moer like a matter of whether the module has been loaded or not.

--
You received this message because you are subscribed to the Google Groups "WildFly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/wildfly/54a00685-f64c-4cd5-8130-6b449ea20a5dn%40googlegroups.com.

--

Brian Stansberry

Collaborative Partner - IBM

Architect, JBoss EAP

WildFly Project Lead

He/Him/His

[James Perkins]

No, it doesn't work in non-embedded either. I think if there was a deployment that activated the module it would work, but since the module as not been activated it won't work.

I do understand the point of trying to see if a module exists and adding it if it does not. I thought I'd done this somewhere before, but I'm not finding an example if I had.

[Andreas Liebscher]

At least, with the current state, module-info is no replacement for list-resource-loader-paths.
Why has list-resource-loader-paths been deprecated if there is no replacement?

Can you send me a link where to create a WFCORE feature request?

Do I have the right to create an issue?

Greeting!

[Brian Stansberry]

Hi Andreas,

If you want to file a Feature Request to enhance module-info it would be done at https://redhat.atlassian.net/jira/software/c/projects/WFCORE/summary.

If you have an account at redhat.atlassian.net you should be able to file an issue. (Red Hat changed JIRA a lot a couple months ago but AFAIK that is still the case.)

But, you may not want to bother. I looked a bit into why list-resource-loader-paths is deprecated and filed https://redhat.atlassian.net/browse/WFCORE-7588 to track re-evaluating that. It's basically deprecated because it's "experimental". But what made it experimental has changed somewhat since it was marked that way in 2013. Plus it's been part of our API for 13 years so it needs re-evaluation. The way it works now is very much analogous to the undeprecated 'module-info' command.

BTW, I'm pretty sure the reason list-resource-loader-roots works for a module that has not been loaded while module-info does not is the handler for list-resource-loader-roots loads the module before inspecting it, while the handler for module-info does not. If we undeprecate list-resource-loader-paths we should consider changing module-info to load the module. If it's ok for one operation I don't see why it would be wrong for another. IOW we'd not be opening up some new category of behavior.

Best regards,

Brian

[Andreas Liebscher]

Sounds good.

I do not have the rights to open a new issue, sorry.

Best regards,

Andreas

[Jason Lee]

You might take a look at this document, which was just updated this morning: https://github.com/wildfly/wildfly/blob/main/CONTRIBUTING.md#issues

Several users reported permission issues with the new Jira. The updates in that section should get you over the hump...

To view this discussion visit https://groups.google.com/d/msgid/wildfly/f408e24b-96e1-4e85-a59e-f6b10b7671ecn%40googlegroups.com.

-- 
Jason Lee
Principal Software Engineer
IBM Java Middleware
Java Champion