Description of problem: After installing WildFly the Log4j module contains the following symbolic link: - log4j-1.2.17.jar -> /usr/lib/java/log4j-1.2.17.jar However the Log4j jar is actually at: - /usr/share/java/log4j-1.2.17.jar Version-Release number of selected component (if applicable): Installed Packages Name : wildfly Arch : noarch Epoch : 0 Version : 8.1.0 Release : 3.fc22 How reproducible: Only attempted the installation once, due to the nature of the error I don't see a subsequent attempt as being helpful. Steps to Reproduce: 1. dnf install wildfly 2. cd /usr/share/wildfly/bin 3. ./standalone.sh Actual results: Unable to read the logging configuration from 'file:/usr/share/wildfly/standalone/configuration/logging.properties' (java.io.FileNotFoundException: /usr/share/wildfly/standalone/configuration/logging.properties (Permission denied)) Exception in thread "main" org.jboss.modules.ModuleLoadError: Error loading module from /usr/share/wildfly/modules/system/layers/base/org/jboss/log4j/logmanager/main/module.xml at org.jboss.modules.ModuleLoadException.toError(ModuleLoadException.java:78) at org.jboss.modules.Module.getPathsUnchecked(Module.java:1392) at org.jboss.modules.Module.loadModuleClass(Module.java:563) at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205) Expected results: A cleanly started server. Additional info:
To fix this problem you need as root execute commands: #rm /usr/share/wildfly/modules/system/layers/base/org/jboss/log4j/logmanager/main/log4j-1.2.17.jar #ln -s /usr/share/java/log4j-1.2.17.jar /usr/share/wildfly/modules/system/layers/base/org/jboss/log4j/logmanager/main/log4j-1.2.17.jar
I'm very new to wildfly and not familiar with it at all and I'm not sure but I found some other missing symlinks in wildfly-8.1.0-3.fc22. By doing the below it worked even if still many warnings out. [root@lp5 ssato]# ln -sf /usr/share/java/txw2/txw2.jar /usr/share/wildfly/modules/system/layers/base/com/sun/xml/bind/main/txw2.jar [root@lp5 ssato]# ln -sf /usr/share/java/txw2/txw2.jar /usr/share/wildfly/modules/system/layers/base/com/sun/xml/txw2/main/txw2.jar [root@lp5 ssato]# ln -sf /usr/share/java/glassfish-jaxb/jaxb1-impl.jar /usr/share/wildfly/modules/system/layers/base/com/sun/xml/bind/main/jaxb-impl.jar [root@lp5 ssato]# ln -sf /usr/share/java/relaxngDatatype/relaxngDatatype.jar /usr/share/wildfly/modules/system/layers/base/com/github/relaxng/main/relaxngDatatype.jar [root@lp5 ssato]# ln -sf /usr/share/java/xsom/xsom.jar /usr/share/wildfly/modules/system/layers/base/com/sun/xsom/main/xsom.jar [root@lp5 ssato]# ln -sf /usr/share/java/rngom/rngom.jar /usr/share/wildfly/modules/system/layers/base/org/kohsuke/rngom/main/rngom.jar
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Still broken on wildfly-8.1.0-3.fc22 in F24. Which is not very surprising, considering the revision number...
How is this bug clubbed against fedora 22 when it is reported and present in fedora 24? Is it fixed in Fedora 24? Any plans to update Wildfly for current version of fedora?
Not sure what clubbed mean, but it's reported against F24.... Then the package in F24 seem to date back to F22, if judging by the release stamp. But that's a different story...
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Not available apache-juddi (was retired: 2015-06-02) Not available dependecies in F24 branch for upgrade to latest release or rebuild. see https://fedoraproject.org/wiki/WildFly
So... if we can't make the wildfly package to work, shouldn't we retire it? Does it make any sense to have a dead package hanging around? Or am I misunderstanding the situation?
(In reply to David Juran from comment #9) > So... if we can't make the wildfly package to work, shouldn't we retire it? > Does it make any sense to have a dead package hanging around? Or am I > misunderstanding the situation? i can not fix this problem for F<25 (Comment#8), ie upgrade to wildfly 10.x. the package will be usable only for F25 and rawhide
Sorry, then I misunderstood. Thanks for the clarification and thanks for fixing the issue (-: