[JBoss JIRA] (WFLY-975) Deployment replace causes invalid state in DUP
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-975?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration updated WFLY-975:
-----------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1282881, https://bugzilla.redhat.com/show_bug.cgi?id=924562 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1282881)
> Deployment replace causes invalid state in DUP
> ----------------------------------------------
>
> Key: WFLY-975
> URL: https://issues.jboss.org/browse/WFLY-975
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Reporter: Thomas Diesler
> Assignee: Stuart Douglas
> Fix For: 8.0.0.Alpha1
>
> Attachments: v200.jar, v201.jar, webapp-v200.war
>
>
> Webapp A depends on deployment B. Replacing B causes NPE in JPAInterceptorProcessor
> {code}
> 12:52:05,712 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015876: Starting deployment of "v200.jar" (runtime-name: "v200.jar")
> 12:52:05,889 INFO [org.jboss.as.server] (XNIO-1 task-8) JBAS018559: Deployed "v200.jar" (runtime-name : "v200.jar")
> 12:52:37,207 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "webapp-v200.war" (runtime-name: "webapp-v200.war")
> 12:52:37,349 INFO [org.jboss.web] (ServerService Thread Pool -- 52) JBAS018210: Register web context: /webapp-v200
> 12:52:37,436 INFO [org.jboss.as.server] (XNIO-1 task-3) JBAS018559: Deployed "webapp-v200.war" (runtime-name : "webapp-v200.war")
> 12:53:20,252 INFO [org.jboss.web] (ServerService Thread Pool -- 57) JBAS018224: Unregister web context: /webapp-v200
> 12:53:20,272 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment v200.jar (runtime-name: v200.jar) in 25ms
> 12:53:20,274 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "v200.jar" (runtime-name: "v200.jar")
> 12:53:20,293 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."webapp-v200.war".FIRST_MODULE_USE: org.jboss.msc.service.StartException in service jboss.deployment.unit."webapp-v200.war".FIRST_MODULE_USE: JBAS018733: Failed to process phase FIRST_MODULE_USE of deployment "webapp-v200.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:127) [jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1972) [jboss-msc-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1905) [jboss-msc-1.1.1.Final.jar:1.1.1.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_13]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_13]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_13]
> Caused by: java.lang.NullPointerException
> at org.jboss.as.jpa.processor.JPAInterceptorProcessor.deploy(JPAInterceptorProcessor.java:52)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:120) [jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> ... 5 more
> {code}
> What might be happening here is that replacing B causes ModuleB to go down. Phase FIRST_MODULE_USE of A depends on ModuleB, which causes a call to undeploy() on the DUPs for A. When ModuleB becomes available again, deploy() is called on the DUPs for A again. Possibly because of the cleanup phase, necessary state is lost and we see a NPE.
> AFAICS, this is a variation of the feature request that DUPs support multiple calls to deploy/undeploy.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-975) Deployment replace causes invalid state in DUP
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-975?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration updated WFLY-975:
-----------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1282881 (was: https://bugzilla.redhat.com/show_bug.cgi?id=924562)
Bugzilla Update: Perform
> Deployment replace causes invalid state in DUP
> ----------------------------------------------
>
> Key: WFLY-975
> URL: https://issues.jboss.org/browse/WFLY-975
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Reporter: Thomas Diesler
> Assignee: Stuart Douglas
> Fix For: 8.0.0.Alpha1
>
> Attachments: v200.jar, v201.jar, webapp-v200.war
>
>
> Webapp A depends on deployment B. Replacing B causes NPE in JPAInterceptorProcessor
> {code}
> 12:52:05,712 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015876: Starting deployment of "v200.jar" (runtime-name: "v200.jar")
> 12:52:05,889 INFO [org.jboss.as.server] (XNIO-1 task-8) JBAS018559: Deployed "v200.jar" (runtime-name : "v200.jar")
> 12:52:37,207 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "webapp-v200.war" (runtime-name: "webapp-v200.war")
> 12:52:37,349 INFO [org.jboss.web] (ServerService Thread Pool -- 52) JBAS018210: Register web context: /webapp-v200
> 12:52:37,436 INFO [org.jboss.as.server] (XNIO-1 task-3) JBAS018559: Deployed "webapp-v200.war" (runtime-name : "webapp-v200.war")
> 12:53:20,252 INFO [org.jboss.web] (ServerService Thread Pool -- 57) JBAS018224: Unregister web context: /webapp-v200
> 12:53:20,272 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment v200.jar (runtime-name: v200.jar) in 25ms
> 12:53:20,274 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "v200.jar" (runtime-name: "v200.jar")
> 12:53:20,293 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."webapp-v200.war".FIRST_MODULE_USE: org.jboss.msc.service.StartException in service jboss.deployment.unit."webapp-v200.war".FIRST_MODULE_USE: JBAS018733: Failed to process phase FIRST_MODULE_USE of deployment "webapp-v200.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:127) [jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1972) [jboss-msc-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1905) [jboss-msc-1.1.1.Final.jar:1.1.1.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_13]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_13]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_13]
> Caused by: java.lang.NullPointerException
> at org.jboss.as.jpa.processor.JPAInterceptorProcessor.deploy(JPAInterceptorProcessor.java:52)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:120) [jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> ... 5 more
> {code}
> What might be happening here is that replacing B causes ModuleB to go down. Phase FIRST_MODULE_USE of A depends on ModuleB, which causes a call to undeploy() on the DUPs for A. When ModuleB becomes available again, deploy() is called on the DUPs for A again. Possibly because of the cleanup phase, necessary state is lost and we see a NPE.
> AFAICS, this is a variation of the feature request that DUPs support multiple calls to deploy/undeploy.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-1363) Updating deployment with dependant
by Brad Maxwell (JIRA)
[ https://issues.jboss.org/browse/WFLY-1363?page=com.atlassian.jira.plugin.... ]
Brad Maxwell commented on WFLY-1363:
------------------------------------
Looks like duplicate of https://issues.jboss.org/browse/WFLY-975 - which is fixed in wildfly, I tested wildfly-10.0.0.CR4 , deployed a depends on b, then redeployed a and then redeployed b, and did not get the IllegalStateException that I saw in EAP 6.4, so I would say this Wildfly jira is resolved in Wildlfy
> Updating deployment with dependant
> ----------------------------------
>
> Key: WFLY-1363
> URL: https://issues.jboss.org/browse/WFLY-1363
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Environment: Windows 7 64bit, JBoss 7.2.0.Final
> Reporter: Bart Van Dosselaer
> Assignee: Jason Greene
> Labels: deployment
> Attachments: jboss-deployment.zip, jboss-deployment.zip
>
>
> I'm faced with a certain deployment issue, for which I've created a small maven project (see attachment) so anyone can easily reproduce this behaviour.
>
> I have a scenario where I have two EAR deployments: base.ear and service.ear. The latter uses some services of the former. For this to work, it has all the necessary entries in its manifest.
> Once deployed, I can call the EJB from service.ear and the EJB from base.ear gets injected and used. No problems so far.
>
> This works fine, until I want to update base.ear.
>
> We have our own mechanism to update deployments (through the management API), but the same result can be achieved by deploying through the JBoss Admin console or JBoss CLI.
> So, when I update base.ear (just replace with the same base.ear file) it deploys fine and the invocation is successful. However, there's one line in the console which goes like:
> JBAS014777: Services which failed to start: service jboss.deployment.subunit."service.ear"."service-ejb.jar".FIRST_MODULE_USE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."service.ear"."service-ejb.jar".FIRST_MODULE_USE: JBAS018733: Failed to process phase FIRST_MODULE_USE of subdepl
> oyment "service-ejb.jar" of deployment "service.ear"
> At this moment, the service.ear, and all its EJBs, isn't really deployed anymore. Or atleast, wrongfully deployed. Not sure how to call that state.
> One possibility is to invoke the :reload command (or restart the server), but ideally we'd like to not have this error in the first place.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5696) Mixed domain test launches a server from the DC
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-5696?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-5696:
-----------------------------------
Fix Version/s: 11.0.0.Alpha1
> Mixed domain test launches a server from the DC
> -----------------------------------------------
>
> Key: WFLY-5696
> URL: https://issues.jboss.org/browse/WFLY-5696
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, Test Suite
> Affects Versions: 10.0.0.CR4
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Minor
> Fix For: 11.0.0.Alpha1
>
>
> The host.xml used by the DC in the testsuite/mixed-domain tests is launching a server. This server fails to launch because the profiles being used include stuff that won't work on current version servers (i.e. legacy subsystems like web).
> The failure to launch the server isn't affecting the test results, proving the existence of the server is not relevant to the test assertions.
> Our goal in these tests is to test how the old slaves handle stuff. We have other ways to test how new servers handle old stuff. So I'm going to remove the launch of this server from the DC config.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5696) Mixed domain test launches a server from the DC
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-5696:
--------------------------------------
Summary: Mixed domain test launches a server from the DC
Key: WFLY-5696
URL: https://issues.jboss.org/browse/WFLY-5696
Project: WildFly
Issue Type: Bug
Components: Domain Management, Test Suite
Affects Versions: 10.0.0.CR4
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Priority: Minor
The host.xml used by the DC in the testsuite/mixed-domain tests is launching a server. This server fails to launch because the profiles being used include stuff that won't work on current version servers (i.e. legacy subsystems like web).
The failure to launch the server isn't affecting the test results, proving the existence of the server is not relevant to the test assertions.
Our goal in these tests is to test how the old slaves handle stuff. We have other ways to test how new servers handle old stuff. So I'm going to remove the launch of this server from the DC config.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5676) Wrong WildFly version when WildFly standalone is started
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5676?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-5676:
-----------------------------------
Version 1.0.2 comes from WildFly Core, which is the actual version that is used in WildFly (full)
class org.jboss.as.Version is part of wildfly core, that is why version there is version of core.
> Wrong WildFly version when WildFly standalone is started
> --------------------------------------------------------
>
> Key: WFLY-5676
> URL: https://issues.jboss.org/browse/WFLY-5676
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 9.0.2.Final
> Reporter: Stefan Lindner
> Assignee: Jason Greene
>
> See also Bug WFLY-2544
> Wildfly 9.2.0 final reports Version 1.0.2 if asked from within Java-application (consulting org.jboss.as.version.Version):
> AS_VERSION = 1.0.2.Final
> AS_RELEASE_CODENAME = Kenny
> Yes, we could test if it's "kenny" and the aha: 1.0.2 is 9.0.2 but this sounds strange
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5676) Wrong WildFly version when WildFly standalone is started
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFLY-5676?page=com.atlassian.jira.plugin.... ]
ehsavoie Hugonnet commented on WFLY-5676:
-----------------------------------------
To get the version you should use the ProductConfig or the Maangement API.
For example the CLI gives :
[standalone@localhost:9990 /] :read-attribute(name=product-version)
{
"outcome" => "success",
"result" => "10.0.0.CR5-SNAPSHOT"
}
[standalone@localhost:9990 /] :read-attribute(name=product-name)
{
"outcome" => "success",
"result" => "WildFly Full"
}
> Wrong WildFly version when WildFly standalone is started
> --------------------------------------------------------
>
> Key: WFLY-5676
> URL: https://issues.jboss.org/browse/WFLY-5676
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 9.0.2.Final
> Reporter: Stefan Lindner
> Assignee: Jason Greene
>
> See also Bug WFLY-2544
> Wildfly 9.2.0 final reports Version 1.0.2 if asked from within Java-application (consulting org.jboss.as.version.Version):
> AS_VERSION = 1.0.2.Final
> AS_RELEASE_CODENAME = Kenny
> Yes, we could test if it's "kenny" and the aha: 1.0.2 is 9.0.2 but this sounds strange
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1136) Subsystem parser tests fail when woodstox parser is on classpath
by Tomaz Cerar (JIRA)
Tomaz Cerar created WFCORE-1136:
-----------------------------------
Summary: Subsystem parser tests fail when woodstox parser is on classpath
Key: WFCORE-1136
URL: https://issues.jboss.org/browse/WFCORE-1136
Project: WildFly Core
Issue Type: Bug
Components: Test Suite
Affects Versions: 2.0.1.Final
Environment: woodstox parser on test classpath
Reporter: Tomaz Cerar
Assignee: Tomaz Cerar
When subsystem is testing remove resources and subsystem model is empty.
Marshaling fails inside subsystem harness with
{noformat}
Caused by: javax.xml.stream.XMLStreamException: Trying to write END_DOCUMENT when document has no root (ie. trying to output empty document).
at com.ctc.wstx.sw.BaseStreamWriter.throwOutputError(BaseStreamWriter.java:1522)
at com.ctc.wstx.sw.BaseStreamWriter.reportNwfStructure(BaseStreamWriter.java:1551)
at com.ctc.wstx.sw.BaseStreamWriter._finishDocument(BaseStreamWriter.java:1377)
at com.ctc.wstx.sw.BaseStreamWriter.writeEndDocument(BaseStreamWriter.java:536)
at org.jboss.staxmapper.FormattingXMLStreamWriter.writeEndDocument(FormattingXMLStreamWriter.java:215)
at org.jboss.as.subsystem.test.TestParser.writeContent(TestParser.java:80)
at org.jboss.as.subsystem.test.TestParser.writeContent(TestParser.java:51)
at org.jboss.staxmapper.XMLMapperImpl.doDeparse(XMLMapperImpl.java:88)
at org.jboss.staxmapper.XMLMapperImpl.deparseDocument(XMLMapperImpl.java:83)
at org.jboss.as.controller.persistence.AbstractConfigurationPersister.marshallAsXml(AbstractConfigurationPersister.java:117)
... 51 more
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1135) Unable to start Wildfly when FIPS is enabled in domain mode
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1135?page=com.atlassian.jira.plugi... ]
Ryan Emerson updated WFCORE-1135:
---------------------------------
Description:
Resulting stacktrace below:
15:47:39,410 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.host.controller.client: org.jboss.msc.service.StartException in service jboss.host.controller.client: java.io.IOException: WFLYSRV0117: Unable to initialise a basic SSLContext 'FIPS mode: only SunJSSE TrustManagers may be used'
[Server:server-one] at org.jboss.as.server.mgmt.domain.HostControllerConnectionService.start(HostControllerConnectionService.java:133)
[Server:server-one] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
[Server:server-one] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
[Server:server-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[Server:server-one] at java.lang.Thread.run(Thread.java:745)
[Server:server-one] Caused by: java.io.IOException: WFLYSRV0117: Unable to initialise a basic SSLContext 'FIPS mode: only SunJSSE TrustManagers may be used'
[Server:server-one] at org.jboss.as.server.mgmt.domain.HostControllerConnectionService.getAcceptingSSLContext(HostControllerConnectionService.java:212)
[Server:server-one] at org.jboss.as.server.mgmt.domain.HostControllerConnectionService.start(HostControllerConnectionService.java:108)
[Server:server-one] ... 5 more
> Unable to start Wildfly when FIPS is enabled in domain mode
> -----------------------------------------------------------
>
> Key: WFCORE-1135
> URL: https://issues.jboss.org/browse/WFCORE-1135
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security
> Affects Versions: 2.0.1.Final
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Attachments: domain.xml, host.xml
>
>
> Resulting stacktrace below:
> 15:47:39,410 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.host.controller.client: org.jboss.msc.service.StartException in service jboss.host.controller.client: java.io.IOException: WFLYSRV0117: Unable to initialise a basic SSLContext 'FIPS mode: only SunJSSE TrustManagers may be used'
> [Server:server-one] at org.jboss.as.server.mgmt.domain.HostControllerConnectionService.start(HostControllerConnectionService.java:133)
> [Server:server-one] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> [Server:server-one] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:server-one] at java.lang.Thread.run(Thread.java:745)
> [Server:server-one] Caused by: java.io.IOException: WFLYSRV0117: Unable to initialise a basic SSLContext 'FIPS mode: only SunJSSE TrustManagers may be used'
> [Server:server-one] at org.jboss.as.server.mgmt.domain.HostControllerConnectionService.getAcceptingSSLContext(HostControllerConnectionService.java:212)
> [Server:server-one] at org.jboss.as.server.mgmt.domain.HostControllerConnectionService.start(HostControllerConnectionService.java:108)
> [Server:server-one] ... 5 more
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months