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

[Bug] When loaded via WildFly MODULE_OPTS, the default configuration properties are unset #486

Open
andrewazores opened this issue Sep 19, 2024 · 1 comment · May be fixed by #523
Open
Assignees
Labels
bug Something isn't working question Further information is requested

Comments

@andrewazores
Copy link
Member

As seen here, for example: https://github.com/cryostatio/cryostat/pull/660/files#diff-80091271b0c4b29825c64e3803935b6ca838e5e9434a029100fb9a946f1ee19cR30

Using MODULE_OPTS to load the Cryostat Agent works fine and the Agent does initialize successfully, but it fails to load any of its own default configuration values from https://github.com/cryostatio/cryostat-agent/blob/main/src/main/resources/META-INF/microprofile-config.properties . Every single configuration must be supplied to the Agent, ex. by environment variable, even if just to set the value to the same as the intended default.

@andrewazores andrewazores added bug Something isn't working question Further information is requested labels Sep 19, 2024
@andrewazores andrewazores moved this to Ready in 4.0.0 release Sep 19, 2024
@andrewazores andrewazores moved this from Ready to Backlog in 4.0.0 release Sep 19, 2024
@andrewazores
Copy link
Member Author

diff --git a/src/main/java/io/cryostat/agent/ConfigModule.java b/src/main/java/io/cryostat/agent/ConfigModule.java
index 5cb3d4d..15bb2cf 100644
--- a/src/main/java/io/cryostat/agent/ConfigModule.java
+++ b/src/main/java/io/cryostat/agent/ConfigModule.java
@@ -204,13 +204,23 @@ public abstract class ConfigModule {
                () -> {
                    ClassLoader cl = Thread.currentThread().getContextClassLoader();
                    if (cl != null) {
+                       if ("org.jboss.modules.ModuleClassLoader".equals(cl.getClass().getName())) {
+                           System.out.println(
+                                   "!!!!!!!!!!!!!!!!!!!!!!!!!!"
+                                           + "org.jboss.modules.ModuleClassLoader"
+                                                   .equals(cl.getClass().getName()));
+                           return cl;
+                       }
+                       cl = Config.class.getClassLoader();
                        return cl;
                    }
+
                    return new URLClassLoader(new URL[] {Agent.selfJarLocation().toURL()});
                };
        try {
            ClassLoader cl = AccessController.doPrivileged(pea);
-           return ConfigProvider.getConfig(cl);
+           Config config = ConfigProvider.getConfig(cl);
+           return config;
        } catch (PrivilegedActionException pae) {
            throw new RuntimeException(pae);
        }

Here's a hack from a WildFly contributor helping me to figure this out. The "org.jboss.modules.ModuleClassLoader" is the correct classloader to use for this case. Maybe we need to have some logic to try various classloaders from a list until we find one that correct loads the default properties file resource. There should be some default values for classloaders to try, including the jboss modules classloader, but this should probably also be something the end user can configure to add additional classloader names in case they require some other classloader, ex. if their application/framework/webserver has some other similar module-like loading system.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working question Further information is requested
Projects
Status: In progress
Development

Successfully merging a pull request may close this issue.

1 participant