Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-10199

Using jboss-modules loading outside WildFly 12 is broken

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Major
    • 13.0.0.Final
    • 12.0.0.Final
    • None
    • None

    Description

      oVirt is using jboss-modules not only for dependencies inside WildFly, but also when executing command line tools outside WildFly process. We are using following method which worked fine from JBoss 7 to WildFly11:

      export JAVA_MODULEPATH="<PATH TO OUR MODULES>"
exec "${JAVA_HOME}/bin/java" \                                                                                                                                                                                
        -jar "${JBOSS_HOME}/jboss-modules.jar" \                                                                                                                                                              
        -dependencies org.ovirt.engine.core.tools \                                                                                                                                                           
        -class org.ovirt.engine.core.cryptotool.Main \                                                                                                                                                        
        "$@"

      where "org.ovirt.engine.core.tools" is one of our existing module and in class we have standard Java class with main() method executing logic of specific command line tool.

      When I try to execute this code with WildFly 12.0.0.FINAL I receive following exception:

      Exception in thread "main" java.lang.NullPointerException
	at java.util.Hashtable.put(Hashtable.java:460)
	at java.util.Properties.setProperty(Properties.java:166)
	at java.lang.System.setProperty(System.java:796)
	at org.jboss.modules.PropertyWriteAction.run(PropertyWriteAction.java:40)
	at org.jboss.modules.PropertyWriteAction.run(PropertyWriteAction.java:28)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.jboss.modules.Main.main(Main.java:390)

      When I tried to replace jboss-modules.jar provided by WildFly 12.0.0.FINAL with manuall build using latest code in 1.7 branch (commit a52a323c5c3d71cf9597f06951155e4639cbb707) I receive different error:

      org.jboss.modules.ModuleNotFoundException: org.ovirt.engine.core.tools
	at org.jboss.modules.Module.addPaths(Module.java:1221)
	at org.jboss.modules.Module.link(Module.java:1577)
	at org.jboss.modules.Module.relinkIfNecessary(Module.java:1605)
	at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:296)
	at org.jboss.modules.Main.main(Main.java:426)

      I haven't found any documentation describing such incompatible between 1.6 and 1.7, so is there any way how to have above execution compatible with both jboss-modules versions?

      Thanks

      Martin

      Attachments

        Issue Links

          is caused by

          Bug - A problem that impairs or prevents the functions of the product. MODULES-271 NPE when using -class option

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Resolved
          is cloned by

          Bug - A problem that impairs or prevents the functions of the product. JBEAP-14618 [LP - RHV product] (7.x / CD) Using jboss-modules loading outside WildFly 12 is broken

          • Blocker - To be worked above all other priorities. This term is chosen when the severity of the issue is very high, has no workaround, or the effort for the change is comparatively low. Issues that may be very publicly visible and could generate significant media attention may also drive a higher priority.
          • Closed
          is incorporated by

          Component Upgrade - A task tracking an update to a bundled component or revision of component upstream of the project. WFCORE-3684 Upgrade JBoss Modules to 1.8.0.Final

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Resolved

          Activity

            People

              dlloyd@redhat.com David Lloyd
              mperina1@redhat.com Martin Perina
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: