Created attachment 1231207 [details] wildfly server.log for standalone-full.xml configuration. Description of problem: After a clean install of Wildfly, there are errors starting up the standalone-full.xml configuration. Specifically: java.lang.ClassNotFoundException: javax.json.JsonValue "WFLYCTL0080: Failed services" => {"jboss.infinispan.hibernate" => "org.jboss.msc.service.StartException in service jboss.infinispan.hibernate: Failed to start service Also, there are some dangling symlinks which might be causing some of these problems: [root@nestor wildfly]# symlinks -r . | grep dangling dangling: /usr/share/wildfly/modules/system/layers/base/org/jboss/as/webservices/main/wildfly-webservices-10.1.0.Final.jar -> /usr/share/java/wildfly/wildfly-webservices.jar dangling: /usr/share/wildfly/modules/system/layers/base/org/jboss/as/clustering/jgroups/main/wildfly-clustering-jgroups-10.1.0.Final.jar -> /usr/share/java/wildfly/wildfly-clustering-jgroups.jar dangling: /usr/share/wildfly/modules/system/layers/base/org/jboss/as/clustering/infinispan/main/wildfly-clustering-infinispan-10.1.0.Final.jar -> /usr/share/java/wildfly/wildfly-clustering-infinispan.jar Version-Release number of selected component (if applicable): wildfly-10.1.0-7.fc25.noarch How reproducible: Steps to Reproduce: 1. Clean install of wildfly-10.1.0-7 2. Update /etc/wildfly/wildfly.conf, set WILDFLY_CONFIG=standalone-full.xml 3. systemctl start wildfly 4. verify /var/log/wildfly/standalone/server.log Actual results: Failure to start start services. See attached server.log. Expected results: Clean startup without errors. Additional info:
(In reply to Martin Nichol from comment #0) > Created attachment 1231207 [details] > wildfly server.log for standalone-full.xml configuration. > > Description of problem: > After a clean install of Wildfly, there are errors starting up the > standalone-full.xml configuration. where you found this xml file? is not available in my/original package > Specifically: > java.lang.ClassNotFoundException: javax.json.JsonValue Maybe this is only a missing library (jsonp) symlink. Required investigation this could be fixed adding in modules/system/layers/base/javax/json/api/main/module.xml <resources> <resource-root path="lib"/> <artifact name="${javax.json:javax.json-api}"/> </resources> and <module name="javax.json.api" slot="main"/> in modules/system/layers/base/org/apache/activemq/artemis/main/module.xml > "WFLYCTL0080: Failed services" => {"jboss.infinispan.hibernate" => > "org.jboss.msc.service.StartException in service jboss.infinispan.hibernate: > Failed to start service > > Also, there are some dangling symlinks which might be causing some of these > problems: NOT true > Version-Release number of selected component (if applicable): > wildfly-10.1.0-7.fc25.noarch
(In reply to gil cattaneo from comment #1) > (In reply to Martin Nichol from comment #0) > > Created attachment 1231207 [details] > > wildfly server.log for standalone-full.xml configuration. > > > > Description of problem: > > After a clean install of Wildfly, there are errors starting up the > > standalone-full.xml configuration. > where you found this xml file? is not available in my/original package Found
I think this happens also with the default standalone.xml, not just with standalone-full.xml
The problem is caused by Apache Activemq Artemise because of https://issues.apache.org/jira/browse/ARTEMIS-565. In this period i have no time to check if the workaround (Comment#1) to fix this issue/s.
The fix that bug 1400977 has pushed to F25 testing repo, from what I can tell, looks like it fixes the problem. Can someone confirm? Thanks, Trevor Flynn
(In reply to Trevor Flynn from comment #5) > The fix that bug 1400977 has pushed to F25 testing repo, from what I can > tell, looks like it fixes the problem. Can someone confirm? > > Thanks, > Trevor Flynn I did a clean install of Fedora 25 (Server) and installed Wildfly.1.0-10.fc25 (the version referenced in the above mentioned bug). The NoClassDefFoundError: javax.json.JsonValue still exists. I will attached the log file.
Created attachment 1286425 [details] wildfly server.log for standalone-full.xml configuration (v10.1.0-10.fc25)
Hello Martin, I installed mine from updates-testing repo prior to it being moved to the updates repo. I am using the standalone.xml, not the standalone-full.xml. There could possibly be an issue between the configs, but I believe that it is the same package in the two repos. Try to start is using the standalone.xml. If you would like I can post my log and my standalone.xml because it is unmodified. (I just installed on a F25 VM for testing and have not changed it except to allow connections from any address). I will get another test VM running and test the standalone-full from the updates repo when I get home, I am currently at a wedding. Also, out of the box the install should use standalone.xml, did you change it or was it using standalone-full.xml from the clean install? ~Trevor
The initial problem was with starting wildfly with the standalone-full configuration. The standalone.xml and standalone-full.xml configurations start up different things. standalone.xml is a subset of standalone-full.xml. From the Wildfly documentation, here are the differences: * standalone.xml (default): Java Enterprise Edition 7 web profile certified configuration with the required technologies plus those noted in the table above. * standalone-ha.xml: Java Enterprise Edition 7 web profile certified configuration with high availability * standalone-full.xml: Java Enterprise Edition 7 full profile certified configuration including all the required EE 7 technologies * standalone-full-ha.xml: Java Enterprise Edition 7 full profile certified configuration with high availability From what I remember, I needed standalone-full to use JMS queues. To answer your question: out of the box did use standalone.xml, but I changed it to use the standalone-full.xml that is supplied with the clean install.
I am aware of the differences between the configs. I can confirm that standalone-full.xml does throw java.lang.NoClassDefFoundError: javax/json/JsonValue This occurs even when standalone.xml works just fine. I am not sure why at this point... ~Trevor
I cant work for fix this issue (and other) because latest F25 update break my system and my pc become unusable. i sent an email @ Fedora Developement list [1], but until now I did not get support to understand the problem [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/TWTHAKK6B5RBI5L6RQ2S543KHCGH4GHJ/
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Created attachment 1358243 [details] wildfly server.log for standalone-full.xml configuration (v10.1.0-11.fc27) Problem still exists in Fedora 27.
*** Bug 1517504 has been marked as a duplicate of this bug. ***
Problem still exists in Fedora 27.
Problem still exists in Fedora 28
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '27'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Problem still exists in Fedora 29.
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 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.