[JBoss JIRA] (WFCORE-1330) Deployment error after reboot [WFLYSRV0137]
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1330?page=com.atlassian.jira.plugi... ]
ehsavoie Hugonnet edited comment on WFCORE-1330 at 2/2/16 9:52 AM:
-------------------------------------------------------------------
[~wildflyer] Did you run WildFly with different OS users (maybe in the same group) ?
was (Author: ehugonnet):
Did you run WildFly with different OS users (maybe in the same group) ?
> Deployment error after reboot [WFLYSRV0137]
> -------------------------------------------
>
> Key: WFCORE-1330
> URL: https://issues.jboss.org/browse/WFCORE-1330
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.2.Final
> Environment: Ubuntu 14.04 LTS 64bit, jre-1.8.0_65
> Several deployed (JavaEE) web applications including non XA datasources that connect to a MySQL instance.
> Reporter: Tobi Tobias
> Assignee: ehsavoie Hugonnet
> Priority: Critical
> Attachments: server.log, server.log
>
>
> I have a working configuration on wildfly 9.0.2 final with several web applications (JavaEE).
> After a couple of days, I deployed another war file via jboss CLI. This application worked correctly and no deployment error occurred.
> But if I restart the server now, I get following error message:
> 10:36:01,893 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "MM-Controller-0.1.0-SNAPSHOT.war")]) - failure description: "WFLYSRV0137: No deployment content with hash 966847a6f5f5bf8c3470f07ea9e65b7bbcdcd7b7 is available in the deployment content repository for deployment 'MM-Controller-0.1.0-SNAPSHOT.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuration file and restart."
> 10:36:01,990 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> I reproduced this at least 30 times - even with different jars. I always get this error. The server works fine as long as I don't reboot.
> The only way to fix the configuration is to manually remove the deployments from the standalone.xml.
> But this is not an option for me as I want to have the wildfly running as production server where I have several automatic deployments every day.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1121) Use script name for file related to Wildfly to allow multiple instances easily
by Romain Pelisse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1121?page=com.atlassian.jira.plugi... ]
Romain Pelisse updated WFCORE-1121:
-----------------------------------
Git Pull Request: https://github.com/jbossas/jboss-eap/pull/2625
> Use script name for file related to Wildfly to allow multiple instances easily
> ------------------------------------------------------------------------------
>
> Key: WFCORE-1121
> URL: https://issues.jboss.org/browse/WFCORE-1121
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Scripts
> Affects Versions: 2.0.1.Final
> Reporter: Romain Pelisse
> Assignee: Romain Pelisse
> Priority: Optional
> Fix For: 3.0.0.Alpha1
>
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> With the current provided init.d script, one cannot start several instances of Wildfly. Indeed, the script will associate the same files (pid file, log) to both instance. If we rename those files using, for instance, the name of the script we can easily use the *exact same script* for all local instances:
> {code:bash}
> # ln -s ..../init.d/wildfly-initd-redhat.sh /etc/init.d/wildfly-1
> # ln -s ..../init.d/wildfly-initd-redhat.sh /etc/init.d/wildfly-2
> {code}
> And to take the example of the PIDFILE:
> {code:bash}
> JBOSS_PIDFILE=/var/run/$(basename $0)/jboss-as-domain.pid
> {code}
> Each links will then look up and creates its own separate file:
> /var/run/wildfly-1/jboss-as-domain.pid
> /var/run/wildfly-2/jboss-as-domain.pid
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-5850) Can't deploy an EJB to a WildFly 10 server migrated from EAP 6.4
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-5850?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-5850:
----------------------------------------
[~swd847] An issue Jason mentioned yesterday is whether this app should have failed due to the absence of BV. That, is, BV was meant to be optional in some cases. I'm not sure whether this app should have been one of those cases. IOW, is CDI being too aggressive in requiring BV, or is use of CDI *not* one of those cases where BV is optional?
If the answer is CDI is being too aggressive, though, IMHO that's a separate, lower priority, issue. As is answering the question. ;).
> Can't deploy an EJB to a WildFly 10 server migrated from EAP 6.4
> ----------------------------------------------------------------
>
> Key: WFLY-5850
> URL: https://issues.jboss.org/browse/WFLY-5850
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Ladislav Thon
> Assignee: Stuart Douglas
> Priority: Critical
>
> I just tried to migrate a {{standalone.xml}} server from clean EAP 6.4.0 to WildFly 10.0.0.CR4 and then deploy the {{server-side}} part of the {{ejb-remote}} quickstart:
> {code}
> git clone git@github.com:jboss-developer/jboss-eap-quickstarts.git
> cd jboss-eap-quickstarts/
> git checkout -b 6.4.x origin/6.4.x
> cd ejb-remote/server-side/
> mvn clean package -s ../../settings.xml
> cd target
> unzip .../jboss-eap-6.4.0.zip
> unzip .../wildfly-10.0.0.CR4.zip
> cp jboss-eap-6.4/standalone/configuration/standalone.xml wildfly-10.0.0.CR4/standalone/configuration/test.xml
> ./wildfly-10.0.0.CR4/bin/standalone.sh -c test.xml --admin-only
> # on a separate console
> ./wildfly-10.0.0.CR4/bin/jboss-cli.sh -c --controller=localhost:9999
> /subsystem=threads:remove
> /extension=org.jboss.as.threads:remove
> /subsystem=web:migrate
> shutdown
> # on the original console
> cp jboss-ejb-remote-server-side.jar wildfly-10.0.0.CR4/standalone/deployments/
> ./wildfly-10.0.0.CR4/bin/standalone.sh -c test.xml
> {code}
> What I get is this horrible stack trace:
> {code}
> 15:35:50,913 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."jboss-ejb-remote-server-side.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."jboss-ejb-remote-server-side.jar".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment "jboss-ejb-remote-server-side.jar"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154) [wildfly-server-2.0.0.CR8.jar:2.0.0.CR8]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
> Caused by: javax.validation.ValidationException: Unable to create a Configuration, because no Bean Validation provider could be found. Add a provider like Hibernate Validator (RI) to your classpath.
> at javax.validation.Validation$GenericBootstrapImpl.configure(Validation.java:271)
> at org.hibernate.validator.internal.cdi.ValidationExtension.<init>(ValidationExtension.java:109)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.8.0_66]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) [rt.jar:1.8.0_66]
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.8.0_66]
> at java.lang.reflect.Constructor.newInstance(Constructor.java:422) [rt.jar:1.8.0_66]
> at java.lang.Class.newInstance(Class.java:442) [rt.jar:1.8.0_66]
> at org.jboss.as.weld.deployment.WeldPortableExtensions.tryRegisterExtension(WeldPortableExtensions.java:53)
> at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.loadAttachments(WeldPortableExtensionProcessor.java:121)
> at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.deploy(WeldPortableExtensionProcessor.java:81)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147) [wildfly-server-2.0.0.CR8.jar:2.0.0.CR8]
> ... 5 more
> 15:35:50,921 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "jboss-ejb-remote-server-side.jar")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"jboss-ejb-remote-server-side.jar\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"jboss-ejb-remote-server-side.jar\".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment \"jboss-ejb-remote-server-side.jar\"
> Caused by: javax.validation.ValidationException: Unable to create a Configuration, because no Bean Validation provider could be found. Add a provider like Hibernate Validator (RI) to your classpath."}}
> {code}
> When I deploy the same JAR to a clean install of WildFly 10.0.0.CR4, it works just fine. This suggests that something (probably the EJB subsystem?) doesn't correctly parse/serialize the legacy configuration. Or something like that.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-5715) Wildfly 9/10 removing deployments after a certain time
by Oleg Hoefling (JIRA)
[ https://issues.jboss.org/browse/WFLY-5715?page=com.atlassian.jira.plugin.... ]
Oleg Hoefling commented on WFLY-5715:
-------------------------------------
@[~ehugonnet]: Unfortunately, I moved on with the installation in home directory for now, as I plan to run wildfly as a service process anyway. This is pretty strange as I couldn't reproduce the bug on any other system available to me, so it maybe has smth to do with the server machine setup.
> Wildfly 9/10 removing deployments after a certain time
> ------------------------------------------------------
>
> Key: WFLY-5715
> URL: https://issues.jboss.org/browse/WFLY-5715
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 9.0.2.Final, 10.0.0.CR4
> Environment: Ubuntu 12.04.5 LTS
> Reporter: Sven Ulrich
> Assignee: ehsavoie Hugonnet
> Attachments: Dummy.war, ifxjdbc_4.10.jar, server.log, standalone.xml
>
>
> I have setup a Wildfly 10 CR4 on a Ubuntu 12.04.5 LTS. The server is running fine.
> Now I want to deploye my jar files (jdbc driver and jee apps).
> All is uploaded via the management web interface running on the port 10010 (added offset of 20 because a WF8 is running on Port 8080)
> First I log into the web interface and navigate to the tab deployments. Then I use the button add.
> In the popup window:
> 1: Upload a new deployment
> 2: I choose ifxjdbc_4.10.jar for e.g.
> 3: In Verify upload enabled is set and everything else is standard
> 4: The upload takes round about 30sec.
> Now I can setup datasources for this driver and its works fine. My next step is to stop the server and restart it. Then the server wont start because the content is missing for the jar.
> It wont be an issue for me if i could be 100% sure that the server wont be restarted anytime :)
> I have added my standalone.xml and the log with hopefully all needed information.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-5850) Can't deploy an EJB to a WildFly 10 server migrated from EAP 6.4
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-5850?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-5850:
----------------------------------------
[~lthon], you wrote:
"Then, I compare the migrated XML with a stock standalone-full-ha.xml. The following extensions are missing: batch.jberet, bean-validation, clustering.singleton, request-controller and security.manager. Not really sure what to do here. They can be added manually, but some of the subsystem contain substantial configuration that the user can't really provide.
Could there possibly be another management operation that sets up the new extensions/subsystems? Or we can declare that the :migrate operations are internal-only and the only supported way is Eduardo's migration tool."
I see bean-validation as being somewhat different from the others. It provides functionality that in EAP 6 was already part of what the ee subsystem provided. It was broken out so users would have the option to remove it if they didn't need it for their app. So restoring it is a natural thing to do to allow a config to run on WildFly/EAP 7 servers. That seems within the reasonable scope of the server's own function.
I see completely new functionality like batch-jberet, clustering.singleton and security.manager as being a different thing. Adding that's not taking a config meant to support an existing app and moving it; it's adding new functionality for which a new app would be written. That seems more like the proper task of an external management tool, i.e. the migration tool.
The request-controller subsystem is a bit of a middle case, as it's really an aspect of core functionality. But having the server try and add it would be fairly significant hassle, so I would prefer that it be left to the migration tool, at least for now.
> Can't deploy an EJB to a WildFly 10 server migrated from EAP 6.4
> ----------------------------------------------------------------
>
> Key: WFLY-5850
> URL: https://issues.jboss.org/browse/WFLY-5850
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Ladislav Thon
> Assignee: Stuart Douglas
> Priority: Critical
>
> I just tried to migrate a {{standalone.xml}} server from clean EAP 6.4.0 to WildFly 10.0.0.CR4 and then deploy the {{server-side}} part of the {{ejb-remote}} quickstart:
> {code}
> git clone git@github.com:jboss-developer/jboss-eap-quickstarts.git
> cd jboss-eap-quickstarts/
> git checkout -b 6.4.x origin/6.4.x
> cd ejb-remote/server-side/
> mvn clean package -s ../../settings.xml
> cd target
> unzip .../jboss-eap-6.4.0.zip
> unzip .../wildfly-10.0.0.CR4.zip
> cp jboss-eap-6.4/standalone/configuration/standalone.xml wildfly-10.0.0.CR4/standalone/configuration/test.xml
> ./wildfly-10.0.0.CR4/bin/standalone.sh -c test.xml --admin-only
> # on a separate console
> ./wildfly-10.0.0.CR4/bin/jboss-cli.sh -c --controller=localhost:9999
> /subsystem=threads:remove
> /extension=org.jboss.as.threads:remove
> /subsystem=web:migrate
> shutdown
> # on the original console
> cp jboss-ejb-remote-server-side.jar wildfly-10.0.0.CR4/standalone/deployments/
> ./wildfly-10.0.0.CR4/bin/standalone.sh -c test.xml
> {code}
> What I get is this horrible stack trace:
> {code}
> 15:35:50,913 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."jboss-ejb-remote-server-side.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."jboss-ejb-remote-server-side.jar".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment "jboss-ejb-remote-server-side.jar"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154) [wildfly-server-2.0.0.CR8.jar:2.0.0.CR8]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
> Caused by: javax.validation.ValidationException: Unable to create a Configuration, because no Bean Validation provider could be found. Add a provider like Hibernate Validator (RI) to your classpath.
> at javax.validation.Validation$GenericBootstrapImpl.configure(Validation.java:271)
> at org.hibernate.validator.internal.cdi.ValidationExtension.<init>(ValidationExtension.java:109)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.8.0_66]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) [rt.jar:1.8.0_66]
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.8.0_66]
> at java.lang.reflect.Constructor.newInstance(Constructor.java:422) [rt.jar:1.8.0_66]
> at java.lang.Class.newInstance(Class.java:442) [rt.jar:1.8.0_66]
> at org.jboss.as.weld.deployment.WeldPortableExtensions.tryRegisterExtension(WeldPortableExtensions.java:53)
> at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.loadAttachments(WeldPortableExtensionProcessor.java:121)
> at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.deploy(WeldPortableExtensionProcessor.java:81)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147) [wildfly-server-2.0.0.CR8.jar:2.0.0.CR8]
> ... 5 more
> 15:35:50,921 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "jboss-ejb-remote-server-side.jar")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"jboss-ejb-remote-server-side.jar\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"jboss-ejb-remote-server-side.jar\".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment \"jboss-ejb-remote-server-side.jar\"
> Caused by: javax.validation.ValidationException: Unable to create a Configuration, because no Bean Validation provider could be found. Add a provider like Hibernate Validator (RI) to your classpath."}}
> {code}
> When I deploy the same JAR to a clean install of WildFly 10.0.0.CR4, it works just fine. This suggests that something (probably the EJB subsystem?) doesn't correctly parse/serialize the legacy configuration. Or something like that.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months