[JBoss JIRA] (ELY-1473) Java 9: Use new Provider(String, String, String) constructor
by David Lloyd (JIRA)
David Lloyd created ELY-1473:
--------------------------------
Summary: Java 9: Use new Provider(String,String,String) constructor
Key: ELY-1473
URL: https://issues.jboss.org/browse/ELY-1473
Project: WildFly Elytron
Issue Type: Enhancement
Reporter: David Lloyd
Starting from Java 9, Provider instances no longer have a version of type {{double}}; instead it is a plain string. We can start to supply the actual Elytron version string for this parameter, in Java 9.
To have Java 8 and Java 9 versions of this class, an intermediate superclass must be introduced which extends Provider, which can be overridden in a Java 9 supplement. On Java 8, the [emulation logic|https://github.com/dmlloyd/openjdk/commit/3f86236207573314e25bf7009...] from Java 9 (or something similar) is used to construct a {{double}} from the version string. On Java 9, the literal version string is used.
Developing a Java 9 supplement for Elytron is a prerequisite to this task.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 9 months
[JBoss JIRA] (WFLY-9634) Enable MixedDomainDeploymentTest.testExplodedDeployment() for EAP 7.1.0
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-9634?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-9634:
-----------------------------
Description:
I have added an
{code}
// TODO WFLY-9634
Assume.assumeFalse(supportManagedExplodedDeployment());
{code}
to this test in https://github.com/wildfly/wildfly/pull/10730 which introduces the 7.1.0 mixed domain tests. See WFCORE-3479 for more details.
If for some reason the decision is to *not* allow this use case from within a composite, this test should be rewritten to not use a composite.
was:
I have added an
{code}
// TODO WFLY-9634
Assume.assumeFalse(supportManagedExplodedDeployment());
{code}
to disable this test for 7.1.0. See WFCORE-3479 for more details.
If for some reason the decision is to *not* allow this use case from within a composite, this test should be rewritten to not use a composite.
> Enable MixedDomainDeploymentTest.testExplodedDeployment() for EAP 7.1.0
> -----------------------------------------------------------------------
>
> Key: WFLY-9634
> URL: https://issues.jboss.org/browse/WFLY-9634
> Project: WildFly
> Issue Type: Task
> Components: Domain Management, Test Suite
> Reporter: Kabir Khan
> Assignee: ehsavoie Hugonnet
> Fix For: 12.0.0.Alpha1
>
>
> I have added an
> {code}
> // TODO WFLY-9634
> Assume.assumeFalse(supportManagedExplodedDeployment());
> {code}
> to this test in https://github.com/wildfly/wildfly/pull/10730 which introduces the 7.1.0 mixed domain tests. See WFCORE-3479 for more details.
> If for some reason the decision is to *not* allow this use case from within a composite, this test should be rewritten to not use a composite.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 9 months
[JBoss JIRA] (WFLY-9634) Enable MixedDomainDeploymentTest.testExplodedDeployment() for EAP 7.1.0
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-9634?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-9634:
-----------------------------
Description:
I have added an
{code}
// TODO WFLY-9634
Assume.assumeFalse(supportManagedExplodedDeployment());
{code}
to disable this test for 7.1.0. See WFCORE-3479 for more details.
If for some reason the decision is to *not* allow this use case from within a composite, this test should be rewritten to not use a composite.
was:
I have added an
{code}
// TODO WFLY-9634
Assume.assumeFalse(supportManagedExplodedDeployment());
{code}
to disable this test for 7.1.0
> Enable MixedDomainDeploymentTest.testExplodedDeployment() for EAP 7.1.0
> -----------------------------------------------------------------------
>
> Key: WFLY-9634
> URL: https://issues.jboss.org/browse/WFLY-9634
> Project: WildFly
> Issue Type: Task
> Components: Domain Management, Test Suite
> Reporter: Kabir Khan
> Assignee: ehsavoie Hugonnet
> Fix For: 12.0.0.Alpha1
>
>
> I have added an
> {code}
> // TODO WFLY-9634
> Assume.assumeFalse(supportManagedExplodedDeployment());
> {code}
> to disable this test for 7.1.0. See WFCORE-3479 for more details.
> If for some reason the decision is to *not* allow this use case from within a composite, this test should be rewritten to not use a composite.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 9 months
[JBoss JIRA] (WFCORE-3479) Deploying an empty deployment and adding content later fails in a composite
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3479?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-3479:
-------------------------------
Description:
When adding mixed domain tests for EAP 7.1.0 I could not get the MixedDomainDeployment710TestCase.testExplodedDeployment() test to work. Comparing with the core domain ExplodedDeploymentTestCase.testInstallAndExplodeDeploymentOnDCFromScratch(), they both do the following:
{code}
1) Create an empty deployment
2) Add some content to the deployment using input streams
3) Add the deployment to a server group
{code}
However, they differ in that ExplodedDeploymentTestCase does this as individual steps, while MixedDomainDeployment710TestCase does this in a composite. I have a branch at https://github.com/kabir/wildfly-core/tree/WFCORE-3479 which expands ExplodedDeploymentTestCase to demonstrate the problem.
Going back to MixedDomainDeploymentTestCase, the testExplodedDeployment() test pushes the following composite to the DC:
{code}
{
"operation" => "composite",
"address" => [],
"steps" => [
{
"operation" => "add",
"address" => [("deployment" => "test.war")],
"content" => [{"empty" => true}]
},
{
"operation" => "add-content",
"address" => [("deployment" => "test.war")],
"content" => [
{
"target-path" => "index.html",
"input-stream-index" => 0
},
{
"target-path" => "index2.html",
"input-stream-index" => 1
}
]
},
{
"operation" => "add",
"address" => [
("server-group" => "other-server-group"),
("deployment" => "test.war")
],
"enabled" => true
},
{
"operation" => "add",
"address" => [
("server-group" => "main-server-group"),
("deployment" => "test.war")
],
"enabled" => true
}
],
"operation-headers" => {
"caller-type" => "user",
"access-mechanism" => "NATIVE",
"domain-uuid" => "b016e0a3-4175-4f40-b6b9-779fc0fd1745",
"execute-for-coordinator" => true
}
}
{code}
What ends up being pushed to the slave is:
{code}
{
"operation" => "composite",
"address" => [],
"steps" => [
{
"operation" => "add",
"address" => [("deployment" => "test.war")],
"content" => [{
"hash" => bytes {
0x8f, 0x7c, 0x8c, 0x80, 0x35, 0x88, 0x36, 0x16,
0x61, 0xfa, 0x0a, 0x10, 0x30, 0xf9, 0x13, 0x29,
0x04, 0x05, 0x9d, 0x82
},
"archive" => false
}],
"operation-headers" => {
"caller-type" => "user",
"access-mechanism" => "NATIVE",
"domain-uuid" => "9f6d874e-24f8-41ec-a1d0-9c98509964fc"
},
"runtime-name" => undefined
},
{
"operation" => "add-content",
"address" => [("deployment" => "test.war")],
"content" => [{
"hash" => bytes {
0x52, 0x3a, 0x0a, 0x7b, 0x3b, 0xae, 0x1c, 0x67,
0x22, 0x51, 0xf6, 0x34, 0xb5, 0x3b, 0xe7, 0xf9,
0x78, 0x59, 0x91, 0x63
},
"target-path" => "."
}],
"operation-headers" => {
"caller-type" => "user",
"access-mechanism" => "NATIVE",
"domain-uuid" => "9f6d874e-24f8-41ec-a1d0-9c98509964fc"
},
"path" => [
"index.html",
"index2.html"
]
},
{
"operation" => "add",
"address" => [
("server-group" => "other-server-group"),
("deployment" => "test.war")
],
"enabled" => true
},
{
"operation" => "add",
"address" => [
("server-group" => "main-server-group"),
("deployment" => "test.war")
],
"enabled" => true
}
],
"operation-headers" => {
"caller-type" => "user",
"access-mechanism" => "NATIVE",
"domain-uuid" => "9f6d874e-24f8-41ec-a1d0-9c98509964fc",
"execute-for-coordinator" => true
}
}
{code}
The error reported by the DC is:
{code}
{
"outcome" => "failed",
"result" => {
"step-1" => {
"outcome" => "failed",
"rolled-back" => true
},
"step-2" => {
"outcome" => "failed",
"rolled-back" => true
},
"step-3" => {
"outcome" => "failed",
"rolled-back" => true
},
"step-4" => {
"outcome" => "failed",
"rolled-back" => true
}
},
"failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"other-server-group" => {"host" => {"slave" => {"server-one" => {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test.war\")]' not found"}}}}}}}},
"rolled-back" => true,
"server-groups" => {"other-server-group" => {"host" => {"slave" => {"server-one" => {"response" => {
"outcome" => "failed",
"result" => {
"step-1" => {
"outcome" => "failed",
"failure-description" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test.war\")]' not found",
"rolled-back" => true
},
"step-2" => {"outcome" => undefined}
},
"failure-description" => {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test.war\")]' not found"}},
"rolled-back" => true
}}}}}}
}
{code}
Having debugged the slave process a bit, I *believe* the following is what is passed to the servers by the slave HC:
{code}
{
"operation" => "composite",
"steps" => [
{
"operation" => "add-content",
"address" => [("deployment" => "test.war")],
"content" => [{
"hash" => bytes {
0x52, 0x3a, 0x0a, 0x7b, 0x3b, 0xae, 0x1c, 0x67,
0x22, 0x51, 0xf6, 0x34, 0xb5, 0x3b, 0xe7, 0xf9,
0x78, 0x59, 0x91, 0x63
},
"target-path" => "."
}],
"operation-headers" => {
"access-mechanism" => "NATIVE",
"domain-uuid" => "2bd6c01d-a844-43fc-8d10-7d6e4c32e5b1"
},
"path" => [
"index.html",
"index2.html"
]
},
{
"operation" => "add",
"address" => [("deployment" => "test.war")],
"enabled" => true,
"operation-headers" => {
"access-mechanism" => "NATIVE",
"domain-uuid" => "2bd6c01d-a844-43fc-8d10-7d6e4c32e5b1"
},
"runtime-name" => "test.war",
"content" => [{
"hash" => bytes {
0x52, 0x3a, 0x0a, 0x7b, 0x3b, 0xae, 0x1c, 0x67,
0x22, 0x51, 0xf6, 0x34, 0xb5, 0x3b, 0xe7, 0xf9,
0x78, 0x59, 0x91, 0x63
},
"archive" => false
}]
}
],
"operation-headers" => {
"access-mechanism" => "NATIVE",
"domain-uuid" => "2bd6c01d-a844-43fc-8d10-7d6e4c32e5b1"
},
"address" => []
}
{code}
Note that 'add-content' now comes BEFORE 'add', which would explain the "Management resource '[(\"deployment\" => \"test.war\")]' not found".
> Deploying an empty deployment and adding content later fails in a composite
> ---------------------------------------------------------------------------
>
> Key: WFCORE-3479
> URL: https://issues.jboss.org/browse/WFCORE-3479
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.10.Final
> Reporter: Kabir Khan
> Assignee: Brian Stansberry
> Fix For: 4.0.0.Beta1
>
>
> When adding mixed domain tests for EAP 7.1.0 I could not get the MixedDomainDeployment710TestCase.testExplodedDeployment() test to work. Comparing with the core domain ExplodedDeploymentTestCase.testInstallAndExplodeDeploymentOnDCFromScratch(), they both do the following:
> {code}
> 1) Create an empty deployment
> 2) Add some content to the deployment using input streams
> 3) Add the deployment to a server group
> {code}
> However, they differ in that ExplodedDeploymentTestCase does this as individual steps, while MixedDomainDeployment710TestCase does this in a composite. I have a branch at https://github.com/kabir/wildfly-core/tree/WFCORE-3479 which expands ExplodedDeploymentTestCase to demonstrate the problem.
> Going back to MixedDomainDeploymentTestCase, the testExplodedDeployment() test pushes the following composite to the DC:
> {code}
> {
> "operation" => "composite",
> "address" => [],
> "steps" => [
> {
> "operation" => "add",
> "address" => [("deployment" => "test.war")],
> "content" => [{"empty" => true}]
> },
> {
> "operation" => "add-content",
> "address" => [("deployment" => "test.war")],
> "content" => [
> {
> "target-path" => "index.html",
> "input-stream-index" => 0
> },
> {
> "target-path" => "index2.html",
> "input-stream-index" => 1
> }
> ]
> },
> {
> "operation" => "add",
> "address" => [
> ("server-group" => "other-server-group"),
> ("deployment" => "test.war")
> ],
> "enabled" => true
> },
> {
> "operation" => "add",
> "address" => [
> ("server-group" => "main-server-group"),
> ("deployment" => "test.war")
> ],
> "enabled" => true
> }
> ],
> "operation-headers" => {
> "caller-type" => "user",
> "access-mechanism" => "NATIVE",
> "domain-uuid" => "b016e0a3-4175-4f40-b6b9-779fc0fd1745",
> "execute-for-coordinator" => true
> }
> }
> {code}
> What ends up being pushed to the slave is:
> {code}
> {
> "operation" => "composite",
> "address" => [],
> "steps" => [
> {
> "operation" => "add",
> "address" => [("deployment" => "test.war")],
> "content" => [{
> "hash" => bytes {
> 0x8f, 0x7c, 0x8c, 0x80, 0x35, 0x88, 0x36, 0x16,
> 0x61, 0xfa, 0x0a, 0x10, 0x30, 0xf9, 0x13, 0x29,
> 0x04, 0x05, 0x9d, 0x82
> },
> "archive" => false
> }],
> "operation-headers" => {
> "caller-type" => "user",
> "access-mechanism" => "NATIVE",
> "domain-uuid" => "9f6d874e-24f8-41ec-a1d0-9c98509964fc"
> },
> "runtime-name" => undefined
> },
> {
> "operation" => "add-content",
> "address" => [("deployment" => "test.war")],
> "content" => [{
> "hash" => bytes {
> 0x52, 0x3a, 0x0a, 0x7b, 0x3b, 0xae, 0x1c, 0x67,
> 0x22, 0x51, 0xf6, 0x34, 0xb5, 0x3b, 0xe7, 0xf9,
> 0x78, 0x59, 0x91, 0x63
> },
> "target-path" => "."
> }],
> "operation-headers" => {
> "caller-type" => "user",
> "access-mechanism" => "NATIVE",
> "domain-uuid" => "9f6d874e-24f8-41ec-a1d0-9c98509964fc"
> },
> "path" => [
> "index.html",
> "index2.html"
> ]
> },
> {
> "operation" => "add",
> "address" => [
> ("server-group" => "other-server-group"),
> ("deployment" => "test.war")
> ],
> "enabled" => true
> },
> {
> "operation" => "add",
> "address" => [
> ("server-group" => "main-server-group"),
> ("deployment" => "test.war")
> ],
> "enabled" => true
> }
> ],
> "operation-headers" => {
> "caller-type" => "user",
> "access-mechanism" => "NATIVE",
> "domain-uuid" => "9f6d874e-24f8-41ec-a1d0-9c98509964fc",
> "execute-for-coordinator" => true
> }
> }
> {code}
> The error reported by the DC is:
> {code}
> {
> "outcome" => "failed",
> "result" => {
> "step-1" => {
> "outcome" => "failed",
> "rolled-back" => true
> },
> "step-2" => {
> "outcome" => "failed",
> "rolled-back" => true
> },
> "step-3" => {
> "outcome" => "failed",
> "rolled-back" => true
> },
> "step-4" => {
> "outcome" => "failed",
> "rolled-back" => true
> }
> },
> "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"other-server-group" => {"host" => {"slave" => {"server-one" => {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test.war\")]' not found"}}}}}}}},
> "rolled-back" => true,
> "server-groups" => {"other-server-group" => {"host" => {"slave" => {"server-one" => {"response" => {
> "outcome" => "failed",
> "result" => {
> "step-1" => {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test.war\")]' not found",
> "rolled-back" => true
> },
> "step-2" => {"outcome" => undefined}
> },
> "failure-description" => {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test.war\")]' not found"}},
> "rolled-back" => true
> }}}}}}
> }
> {code}
> Having debugged the slave process a bit, I *believe* the following is what is passed to the servers by the slave HC:
> {code}
> {
> "operation" => "composite",
> "steps" => [
> {
> "operation" => "add-content",
> "address" => [("deployment" => "test.war")],
> "content" => [{
> "hash" => bytes {
> 0x52, 0x3a, 0x0a, 0x7b, 0x3b, 0xae, 0x1c, 0x67,
> 0x22, 0x51, 0xf6, 0x34, 0xb5, 0x3b, 0xe7, 0xf9,
> 0x78, 0x59, 0x91, 0x63
> },
> "target-path" => "."
> }],
> "operation-headers" => {
> "access-mechanism" => "NATIVE",
> "domain-uuid" => "2bd6c01d-a844-43fc-8d10-7d6e4c32e5b1"
> },
> "path" => [
> "index.html",
> "index2.html"
> ]
> },
> {
> "operation" => "add",
> "address" => [("deployment" => "test.war")],
> "enabled" => true,
> "operation-headers" => {
> "access-mechanism" => "NATIVE",
> "domain-uuid" => "2bd6c01d-a844-43fc-8d10-7d6e4c32e5b1"
> },
> "runtime-name" => "test.war",
> "content" => [{
> "hash" => bytes {
> 0x52, 0x3a, 0x0a, 0x7b, 0x3b, 0xae, 0x1c, 0x67,
> 0x22, 0x51, 0xf6, 0x34, 0xb5, 0x3b, 0xe7, 0xf9,
> 0x78, 0x59, 0x91, 0x63
> },
> "archive" => false
> }]
> }
> ],
> "operation-headers" => {
> "access-mechanism" => "NATIVE",
> "domain-uuid" => "2bd6c01d-a844-43fc-8d10-7d6e4c32e5b1"
> },
> "address" => []
> }
> {code}
> Note that 'add-content' now comes BEFORE 'add', which would explain the "Management resource '[(\"deployment\" => \"test.war\")]' not found".
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 9 months
[JBoss JIRA] (WFCORE-3479) Deploying an empty deployment and adding content later fails in a composite
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3479?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-3479:
-------------------------------
Fix Version/s: 4.0.0.Beta1
> Deploying an empty deployment and adding content later fails in a composite
> ---------------------------------------------------------------------------
>
> Key: WFCORE-3479
> URL: https://issues.jboss.org/browse/WFCORE-3479
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.10.Final
> Reporter: Kabir Khan
> Assignee: Brian Stansberry
> Fix For: 4.0.0.Beta1
>
>
> When adding mixed domain tests for EAP 7.1.0 I could not get the MixedDomainDeployment710TestCase.testExplodedDeployment() test to work. Comparing with the core domain ExplodedDeploymentTestCase.testInstallAndExplodeDeploymentOnDCFromScratch(), they both do the following:
> {code}
> 1) Create an empty deployment
> 2) Add some content to the deployment using input streams
> 3) Add the deployment to a server group
> {code}
> However, they differ in that ExplodedDeploymentTestCase does this as individual steps, while MixedDomainDeployment710TestCase does this in a composite. I have a branch at https://github.com/kabir/wildfly-core/tree/WFCORE-3479 which expands ExplodedDeploymentTestCase to demonstrate the problem.
> Going back to MixedDomainDeploymentTestCase, the testExplodedDeployment() test pushes the following composite to the DC:
> {code}
> {
> "operation" => "composite",
> "address" => [],
> "steps" => [
> {
> "operation" => "add",
> "address" => [("deployment" => "test.war")],
> "content" => [{"empty" => true}]
> },
> {
> "operation" => "add-content",
> "address" => [("deployment" => "test.war")],
> "content" => [
> {
> "target-path" => "index.html",
> "input-stream-index" => 0
> },
> {
> "target-path" => "index2.html",
> "input-stream-index" => 1
> }
> ]
> },
> {
> "operation" => "add",
> "address" => [
> ("server-group" => "other-server-group"),
> ("deployment" => "test.war")
> ],
> "enabled" => true
> },
> {
> "operation" => "add",
> "address" => [
> ("server-group" => "main-server-group"),
> ("deployment" => "test.war")
> ],
> "enabled" => true
> }
> ],
> "operation-headers" => {
> "caller-type" => "user",
> "access-mechanism" => "NATIVE",
> "domain-uuid" => "b016e0a3-4175-4f40-b6b9-779fc0fd1745",
> "execute-for-coordinator" => true
> }
> }
> {code}
> What ends up being pushed to the slave is:
> {code}
> {
> "operation" => "composite",
> "address" => [],
> "steps" => [
> {
> "operation" => "add",
> "address" => [("deployment" => "test.war")],
> "content" => [{
> "hash" => bytes {
> 0x8f, 0x7c, 0x8c, 0x80, 0x35, 0x88, 0x36, 0x16,
> 0x61, 0xfa, 0x0a, 0x10, 0x30, 0xf9, 0x13, 0x29,
> 0x04, 0x05, 0x9d, 0x82
> },
> "archive" => false
> }],
> "operation-headers" => {
> "caller-type" => "user",
> "access-mechanism" => "NATIVE",
> "domain-uuid" => "9f6d874e-24f8-41ec-a1d0-9c98509964fc"
> },
> "runtime-name" => undefined
> },
> {
> "operation" => "add-content",
> "address" => [("deployment" => "test.war")],
> "content" => [{
> "hash" => bytes {
> 0x52, 0x3a, 0x0a, 0x7b, 0x3b, 0xae, 0x1c, 0x67,
> 0x22, 0x51, 0xf6, 0x34, 0xb5, 0x3b, 0xe7, 0xf9,
> 0x78, 0x59, 0x91, 0x63
> },
> "target-path" => "."
> }],
> "operation-headers" => {
> "caller-type" => "user",
> "access-mechanism" => "NATIVE",
> "domain-uuid" => "9f6d874e-24f8-41ec-a1d0-9c98509964fc"
> },
> "path" => [
> "index.html",
> "index2.html"
> ]
> },
> {
> "operation" => "add",
> "address" => [
> ("server-group" => "other-server-group"),
> ("deployment" => "test.war")
> ],
> "enabled" => true
> },
> {
> "operation" => "add",
> "address" => [
> ("server-group" => "main-server-group"),
> ("deployment" => "test.war")
> ],
> "enabled" => true
> }
> ],
> "operation-headers" => {
> "caller-type" => "user",
> "access-mechanism" => "NATIVE",
> "domain-uuid" => "9f6d874e-24f8-41ec-a1d0-9c98509964fc",
> "execute-for-coordinator" => true
> }
> }
> {code}
> The error reported by the DC is:
> {code}
> {
> "outcome" => "failed",
> "result" => {
> "step-1" => {
> "outcome" => "failed",
> "rolled-back" => true
> },
> "step-2" => {
> "outcome" => "failed",
> "rolled-back" => true
> },
> "step-3" => {
> "outcome" => "failed",
> "rolled-back" => true
> },
> "step-4" => {
> "outcome" => "failed",
> "rolled-back" => true
> }
> },
> "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"other-server-group" => {"host" => {"slave" => {"server-one" => {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test.war\")]' not found"}}}}}}}},
> "rolled-back" => true,
> "server-groups" => {"other-server-group" => {"host" => {"slave" => {"server-one" => {"response" => {
> "outcome" => "failed",
> "result" => {
> "step-1" => {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test.war\")]' not found",
> "rolled-back" => true
> },
> "step-2" => {"outcome" => undefined}
> },
> "failure-description" => {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test.war\")]' not found"}},
> "rolled-back" => true
> }}}}}}
> }
> {code}
> Having debugged the slave process a bit, I *believe* the following is what is passed to the servers by the slave HC:
> {code}
> {
> "operation" => "composite",
> "steps" => [
> {
> "operation" => "add-content",
> "address" => [("deployment" => "test.war")],
> "content" => [{
> "hash" => bytes {
> 0x52, 0x3a, 0x0a, 0x7b, 0x3b, 0xae, 0x1c, 0x67,
> 0x22, 0x51, 0xf6, 0x34, 0xb5, 0x3b, 0xe7, 0xf9,
> 0x78, 0x59, 0x91, 0x63
> },
> "target-path" => "."
> }],
> "operation-headers" => {
> "access-mechanism" => "NATIVE",
> "domain-uuid" => "2bd6c01d-a844-43fc-8d10-7d6e4c32e5b1"
> },
> "path" => [
> "index.html",
> "index2.html"
> ]
> },
> {
> "operation" => "add",
> "address" => [("deployment" => "test.war")],
> "enabled" => true,
> "operation-headers" => {
> "access-mechanism" => "NATIVE",
> "domain-uuid" => "2bd6c01d-a844-43fc-8d10-7d6e4c32e5b1"
> },
> "runtime-name" => "test.war",
> "content" => [{
> "hash" => bytes {
> 0x52, 0x3a, 0x0a, 0x7b, 0x3b, 0xae, 0x1c, 0x67,
> 0x22, 0x51, 0xf6, 0x34, 0xb5, 0x3b, 0xe7, 0xf9,
> 0x78, 0x59, 0x91, 0x63
> },
> "archive" => false
> }]
> }
> ],
> "operation-headers" => {
> "access-mechanism" => "NATIVE",
> "domain-uuid" => "2bd6c01d-a844-43fc-8d10-7d6e4c32e5b1"
> },
> "address" => []
> }
> {code}
> Note that 'add-content' now comes BEFORE 'add', which would explain the "Management resource '[(\"deployment\" => \"test.war\")]' not found".
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 9 months
[JBoss JIRA] (WFCORE-3479) Deploying an empty deployment and adding content later fails in a composite
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3479?page=com.atlassian.jira.plugi... ]
Kabir Khan reassigned WFCORE-3479:
----------------------------------
Assignee: ehsavoie Hugonnet (was: Brian Stansberry)
> Deploying an empty deployment and adding content later fails in a composite
> ---------------------------------------------------------------------------
>
> Key: WFCORE-3479
> URL: https://issues.jboss.org/browse/WFCORE-3479
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.10.Final
> Reporter: Kabir Khan
> Assignee: ehsavoie Hugonnet
> Fix For: 4.0.0.Beta1
>
>
> When adding mixed domain tests for EAP 7.1.0 I could not get the MixedDomainDeployment710TestCase.testExplodedDeployment() test to work. Comparing with the core domain ExplodedDeploymentTestCase.testInstallAndExplodeDeploymentOnDCFromScratch(), they both do the following:
> {code}
> 1) Create an empty deployment
> 2) Add some content to the deployment using input streams
> 3) Add the deployment to a server group
> {code}
> However, they differ in that ExplodedDeploymentTestCase does this as individual steps, while MixedDomainDeployment710TestCase does this in a composite. I have a branch at https://github.com/kabir/wildfly-core/tree/WFCORE-3479 which expands ExplodedDeploymentTestCase to demonstrate the problem.
> Going back to MixedDomainDeploymentTestCase, the testExplodedDeployment() test pushes the following composite to the DC:
> {code}
> {
> "operation" => "composite",
> "address" => [],
> "steps" => [
> {
> "operation" => "add",
> "address" => [("deployment" => "test.war")],
> "content" => [{"empty" => true}]
> },
> {
> "operation" => "add-content",
> "address" => [("deployment" => "test.war")],
> "content" => [
> {
> "target-path" => "index.html",
> "input-stream-index" => 0
> },
> {
> "target-path" => "index2.html",
> "input-stream-index" => 1
> }
> ]
> },
> {
> "operation" => "add",
> "address" => [
> ("server-group" => "other-server-group"),
> ("deployment" => "test.war")
> ],
> "enabled" => true
> },
> {
> "operation" => "add",
> "address" => [
> ("server-group" => "main-server-group"),
> ("deployment" => "test.war")
> ],
> "enabled" => true
> }
> ],
> "operation-headers" => {
> "caller-type" => "user",
> "access-mechanism" => "NATIVE",
> "domain-uuid" => "b016e0a3-4175-4f40-b6b9-779fc0fd1745",
> "execute-for-coordinator" => true
> }
> }
> {code}
> What ends up being pushed to the slave is:
> {code}
> {
> "operation" => "composite",
> "address" => [],
> "steps" => [
> {
> "operation" => "add",
> "address" => [("deployment" => "test.war")],
> "content" => [{
> "hash" => bytes {
> 0x8f, 0x7c, 0x8c, 0x80, 0x35, 0x88, 0x36, 0x16,
> 0x61, 0xfa, 0x0a, 0x10, 0x30, 0xf9, 0x13, 0x29,
> 0x04, 0x05, 0x9d, 0x82
> },
> "archive" => false
> }],
> "operation-headers" => {
> "caller-type" => "user",
> "access-mechanism" => "NATIVE",
> "domain-uuid" => "9f6d874e-24f8-41ec-a1d0-9c98509964fc"
> },
> "runtime-name" => undefined
> },
> {
> "operation" => "add-content",
> "address" => [("deployment" => "test.war")],
> "content" => [{
> "hash" => bytes {
> 0x52, 0x3a, 0x0a, 0x7b, 0x3b, 0xae, 0x1c, 0x67,
> 0x22, 0x51, 0xf6, 0x34, 0xb5, 0x3b, 0xe7, 0xf9,
> 0x78, 0x59, 0x91, 0x63
> },
> "target-path" => "."
> }],
> "operation-headers" => {
> "caller-type" => "user",
> "access-mechanism" => "NATIVE",
> "domain-uuid" => "9f6d874e-24f8-41ec-a1d0-9c98509964fc"
> },
> "path" => [
> "index.html",
> "index2.html"
> ]
> },
> {
> "operation" => "add",
> "address" => [
> ("server-group" => "other-server-group"),
> ("deployment" => "test.war")
> ],
> "enabled" => true
> },
> {
> "operation" => "add",
> "address" => [
> ("server-group" => "main-server-group"),
> ("deployment" => "test.war")
> ],
> "enabled" => true
> }
> ],
> "operation-headers" => {
> "caller-type" => "user",
> "access-mechanism" => "NATIVE",
> "domain-uuid" => "9f6d874e-24f8-41ec-a1d0-9c98509964fc",
> "execute-for-coordinator" => true
> }
> }
> {code}
> The error reported by the DC is:
> {code}
> {
> "outcome" => "failed",
> "result" => {
> "step-1" => {
> "outcome" => "failed",
> "rolled-back" => true
> },
> "step-2" => {
> "outcome" => "failed",
> "rolled-back" => true
> },
> "step-3" => {
> "outcome" => "failed",
> "rolled-back" => true
> },
> "step-4" => {
> "outcome" => "failed",
> "rolled-back" => true
> }
> },
> "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"other-server-group" => {"host" => {"slave" => {"server-one" => {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test.war\")]' not found"}}}}}}}},
> "rolled-back" => true,
> "server-groups" => {"other-server-group" => {"host" => {"slave" => {"server-one" => {"response" => {
> "outcome" => "failed",
> "result" => {
> "step-1" => {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test.war\")]' not found",
> "rolled-back" => true
> },
> "step-2" => {"outcome" => undefined}
> },
> "failure-description" => {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test.war\")]' not found"}},
> "rolled-back" => true
> }}}}}}
> }
> {code}
> Having debugged the slave process a bit, I *believe* the following is what is passed to the servers by the slave HC:
> {code}
> {
> "operation" => "composite",
> "steps" => [
> {
> "operation" => "add-content",
> "address" => [("deployment" => "test.war")],
> "content" => [{
> "hash" => bytes {
> 0x52, 0x3a, 0x0a, 0x7b, 0x3b, 0xae, 0x1c, 0x67,
> 0x22, 0x51, 0xf6, 0x34, 0xb5, 0x3b, 0xe7, 0xf9,
> 0x78, 0x59, 0x91, 0x63
> },
> "target-path" => "."
> }],
> "operation-headers" => {
> "access-mechanism" => "NATIVE",
> "domain-uuid" => "2bd6c01d-a844-43fc-8d10-7d6e4c32e5b1"
> },
> "path" => [
> "index.html",
> "index2.html"
> ]
> },
> {
> "operation" => "add",
> "address" => [("deployment" => "test.war")],
> "enabled" => true,
> "operation-headers" => {
> "access-mechanism" => "NATIVE",
> "domain-uuid" => "2bd6c01d-a844-43fc-8d10-7d6e4c32e5b1"
> },
> "runtime-name" => "test.war",
> "content" => [{
> "hash" => bytes {
> 0x52, 0x3a, 0x0a, 0x7b, 0x3b, 0xae, 0x1c, 0x67,
> 0x22, 0x51, 0xf6, 0x34, 0xb5, 0x3b, 0xe7, 0xf9,
> 0x78, 0x59, 0x91, 0x63
> },
> "archive" => false
> }]
> }
> ],
> "operation-headers" => {
> "access-mechanism" => "NATIVE",
> "domain-uuid" => "2bd6c01d-a844-43fc-8d10-7d6e4c32e5b1"
> },
> "address" => []
> }
> {code}
> Note that 'add-content' now comes BEFORE 'add', which would explain the "Management resource '[(\"deployment\" => \"test.war\")]' not found".
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 9 months
[JBoss JIRA] (WFLY-9428) Distributed shared web sessions can passivate prematurely
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-9428?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-9428:
-------------------------------
Priority: Major (was: Critical)
> Distributed shared web sessions can passivate prematurely
> ---------------------------------------------------------
>
> Key: WFLY-9428
> URL: https://issues.jboss.org/browse/WFLY-9428
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final, 11.0.0.CR1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
>
> When an EAR is configured to share web sessions across WARs, each WAR deployment will use the same distributed session manager factory instance. However, each deployment will use a separate session manager instance (created from the shared factory). Since session expiration and passivation is managed per session manager, it is possible that a session is scheduled to expire on one manager, regardless of whether it is subsequently referenced by another manager, and can thus attempt to expire prematurely, thus failing to expire when it should.
> To fix this, each session manager instance must also share session expiration/eviction schedulers, where each manager registers deployment specific listeners on SessionManager.start() and unregisters on stop().
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 9 months