[JBoss JIRA] (WFCORE-1128) Improve the subsystem test schema test coverage
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1128?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1128:
-------------------------------------
Fix Version/s: 2.0.4.Final
(was: 2.0.3.Final)
> Improve the subsystem test schema test coverage
> -----------------------------------------------
>
> Key: WFCORE-1128
> URL: https://issues.jboss.org/browse/WFCORE-1128
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.1.Final
> Reporter: Kabir Khan
> Assignee: Kabir Khan
> Fix For: 2.0.4.Final
>
>
> Currently the way to enable the AbstractSubsystemBaseTest testSchema() and testSchemaOfSubsystemTemplates() tests is to override getSubsystemXsdPath() and getSubsystemTemplatePaths().
> Rather than making it explicit to turn on, it should be explicit to turn off.
> Also the current way of doing this uses Assume.assumeTrue() to check if a test has provided a schema file, which provides a lot of ignored test noise in the test output. If the xsd should not be tested, methods should instead override testSchema() or testSchemaOfSubsystemTemplates() and provide an empty implementation with a comment saying why it is not important.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFLY-5764) Remove the default value with outdated contexts for mod_cluster's excluded-context
by Radoslav Husar (JIRA)
Radoslav Husar created WFLY-5764:
------------------------------------
Summary: Remove the default value with outdated contexts for mod_cluster's excluded-context
Key: WFLY-5764
URL: https://issues.jboss.org/browse/WFLY-5764
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 10.0.0.CR4
Reporter: Radoslav Husar
Assignee: Radoslav Husar
The list of current values is useless in the defualt configuration.
{code} "excluded-contexts" => "ROOT,invoker,jbossws,juddi,console",{code}
I am actually marking this as bug, because if you just want to use the root context, if you undefine the value, the default will be used which exludes root context.
Trying a "" value, results in a failure.
{code}[standalone@localhost:9990 /] /subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=excluded-contexts,value=""
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0113: '' is an invalid value for parameter excluded-contexts. Values must have a minimum length of 1 characters",
"rolled-back" => true,
"response-headers" => {"process-state" => "reload-required"}
}{code}
This all comes from legacy stuff.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFLY-5764) Remove the default value with outdated contexts for mod_cluster's excluded-context
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5764?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-5764:
---------------------------------
Description:
The list of current values is useless in the defualt configuration.
{code}"excluded-contexts" => "ROOT,invoker,jbossws,juddi,console"{code}
I am actually marking this as bug, because if you just want to use the root context, if you undefine the value, the default will be used which exludes root context.
Trying a "" value, results in a failure.
{code}[standalone@localhost:9990 /] /subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=excluded-contexts,value=""
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0113: '' is an invalid value for parameter excluded-contexts. Values must have a minimum length of 1 characters",
"rolled-back" => true,
"response-headers" => {"process-state" => "reload-required"}
}{code}
This all comes from legacy stuff.
was:
The list of current values is useless in the defualt configuration.
{code} "excluded-contexts" => "ROOT,invoker,jbossws,juddi,console",{code}
I am actually marking this as bug, because if you just want to use the root context, if you undefine the value, the default will be used which exludes root context.
Trying a "" value, results in a failure.
{code}[standalone@localhost:9990 /] /subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=excluded-contexts,value=""
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0113: '' is an invalid value for parameter excluded-contexts. Values must have a minimum length of 1 characters",
"rolled-back" => true,
"response-headers" => {"process-state" => "reload-required"}
}{code}
This all comes from legacy stuff.
> Remove the default value with outdated contexts for mod_cluster's excluded-context
> ----------------------------------------------------------------------------------
>
> Key: WFLY-5764
> URL: https://issues.jboss.org/browse/WFLY-5764
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR4
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
>
> The list of current values is useless in the defualt configuration.
> {code}"excluded-contexts" => "ROOT,invoker,jbossws,juddi,console"{code}
> I am actually marking this as bug, because if you just want to use the root context, if you undefine the value, the default will be used which exludes root context.
> Trying a "" value, results in a failure.
> {code}[standalone@localhost:9990 /] /subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=excluded-contexts,value=""
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0113: '' is an invalid value for parameter excluded-contexts. Values must have a minimum length of 1 characters",
> "rolled-back" => true,
> "response-headers" => {"process-state" => "reload-required"}
> }{code}
> This all comes from legacy stuff.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (ELY-336) Tests do not establish LoginPermission
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/ELY-336?page=com.atlassian.jira.plugin.sy... ]
Farah Juma reassigned ELY-336:
------------------------------
Assignee: Farah Juma
> Tests do not establish LoginPermission
> --------------------------------------
>
> Key: ELY-336
> URL: https://issues.jboss.org/browse/ELY-336
> Project: WildFly Elytron
> Issue Type: Task
> Components: Testsuite
> Reporter: David Lloyd
> Assignee: Farah Juma
> Priority: Blocker
> Fix For: 1.1.0.Final
>
>
> All users performing authentication in the test suite must be granted the LoginPermission. Without this permission, all tests performing authentications will fail when the {{identity.getPermissions().implies(new LoginPermission())}} checks are enabled in {{ServerAuthenticationContext}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFLY-5752) SFSB deployment fails when passivation-store is configured with custom cache-container
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-5752?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-5752:
-------------------------------
Summary: SFSB deployment fails when passivation-store is configured with custom cache-container (was: Can't rename the "ejb" cache container)
> SFSB deployment fails when passivation-store is configured with custom cache-container
> --------------------------------------------------------------------------------------
>
> Key: WFLY-5752
> URL: https://issues.jboss.org/browse/WFLY-5752
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Reporter: Ladislav Thon
> Assignee: Paul Ferraro
> Priority: Blocker
> Attachments: tinyRemoteEjb-server-ee7.jar
>
>
> When I rename the {{ejb}} cache container, deploying a simple app that contains an EJB ends with a horrible error message. This is a blocker, because renaming a cache container is required for a 2clusters scenario (standalone client invoking a remote EJB in cluster A, that EJB in turns invokes a remote EJB in cluster B, and forwards the response to the original client).
> More details:
> 1. build current WildFly master and {{unzip .../wildfly/build/target/wildfly-10.0.0.CR5-SNAPSHOT.zip}}
> 2. {{cp tinyRemoteEjb-server-ee7.jar wildfly-10.0.0.CR5-SNAPSHOT/standalone/deployments/}} # the JAR is attached
> 3. change the {{wildfly-10.0.0.CR5-SNAPSHOT/standalone/configuration/standalone-full-ha.xml}} file like this:
> {code}
> <!-- in the "ejb3" subsystem -->
> <passivation-store name="infinispan" cache-container="ejb2" max-size="10000"/>
> <remote cluster="ejb2" connector-ref="http-remoting-connector" thread-pool-name="default"/>
> <!-- in the "infinispan" subsystem -->
> <cache-container name="ejb2" ...>
> {code}
> 4. {{./wildfly-10.0.0.CR5-SNAPSHOT/bin/standalone.sh -c standalone-full-ha.xml}}
> This leads to:
> {code}
> 14:11:22,473 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "tinyRemoteEjb-server-ee7.jar")]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
> "Services that were unable to start:" => [
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".CdiValidatorFactoryService",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".WeldStartService",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".component.MyBeanImpl.CREATE",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".component.MyBeanImpl.JndiBindingsService",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".component.MyBeanImpl.START",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".component.MyBeanImpl.VIEW.\"cz.ladicek.tinyRemoteEjb.server.MyBean\".REMOTE",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".component.MyBeanImpl.WeldInstantiator",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".component.MyBeanImpl.WeldInterceptorBindingsService",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".deploymentCompleteService",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".jndiDependencyService",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".moduleDeploymentRuntimeInformation",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".moduleDeploymentRuntimeInformationStart",
> "jboss.naming.context.java.app.tinyRemoteEjb-server-ee7.tinyRemoteEjb-server-ee7.MyBeanImpl",
> "jboss.naming.context.java.app.tinyRemoteEjb-server-ee7.tinyRemoteEjb-server-ee7.\"MyBeanImpl!cz.ladicek.tinyRemoteEjb.server.MyBean\"",
> "jboss.naming.context.java.global.tinyRemoteEjb-server-ee7.MyBeanImpl",
> "jboss.naming.context.java.global.tinyRemoteEjb-server-ee7.\"MyBeanImpl!cz.ladicek.tinyRemoteEjb.server.MyBean\"",
> "jboss.naming.context.java.module.tinyRemoteEjb-server-ee7.tinyRemoteEjb-server-ee7.MyBeanImpl",
> "jboss.naming.context.java.module.tinyRemoteEjb-server-ee7.tinyRemoteEjb-server-ee7.\"MyBeanImpl!cz.ladicek.tinyRemoteEjb.server.MyBean\""
> ],
> "Services that may be the cause:" => ["jboss.clustering.registry.ejb2.client-mappings"]
> }}
> 14:11:22,476 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "ejb3"),
> ("service" => "remote")
> ]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.ejb.remoting.connector.client-mappings.installer is missing [jboss.clustering.registry.ejb2.client-mappings]"]}
> {code}
> This works perfectly fine in 10.0.0.CR4, so I did a {{git bisect}} and traced the problem to this commit: https://github.com/wildfly/wildfly/commit/232dff042f The error message mentions that an {{...ejb2.client-mappings}} service is missing, which is consistent with the commit message (also mentions client mappings).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFLY-5752) Can't rename the "ejb" cache container
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-5752?page=com.atlassian.jira.plugin.... ]
Paul Ferraro edited comment on WFLY-5752 at 12/2/15 10:30 AM:
--------------------------------------------------------------
OK - I see what you mean - if you do change the cache container - there's a missing service.
was (Author: pferraro):
OK - I see what you mean - if you diddochange the cache container - there's a missing service.
> Can't rename the "ejb" cache container
> --------------------------------------
>
> Key: WFLY-5752
> URL: https://issues.jboss.org/browse/WFLY-5752
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Reporter: Ladislav Thon
> Assignee: Paul Ferraro
> Priority: Blocker
> Attachments: tinyRemoteEjb-server-ee7.jar
>
>
> When I rename the {{ejb}} cache container, deploying a simple app that contains an EJB ends with a horrible error message. This is a blocker, because renaming a cache container is required for a 2clusters scenario (standalone client invoking a remote EJB in cluster A, that EJB in turns invokes a remote EJB in cluster B, and forwards the response to the original client).
> More details:
> 1. build current WildFly master and {{unzip .../wildfly/build/target/wildfly-10.0.0.CR5-SNAPSHOT.zip}}
> 2. {{cp tinyRemoteEjb-server-ee7.jar wildfly-10.0.0.CR5-SNAPSHOT/standalone/deployments/}} # the JAR is attached
> 3. change the {{wildfly-10.0.0.CR5-SNAPSHOT/standalone/configuration/standalone-full-ha.xml}} file like this:
> {code}
> <!-- in the "ejb3" subsystem -->
> <passivation-store name="infinispan" cache-container="ejb2" max-size="10000"/>
> <remote cluster="ejb2" connector-ref="http-remoting-connector" thread-pool-name="default"/>
> <!-- in the "infinispan" subsystem -->
> <cache-container name="ejb2" ...>
> {code}
> 4. {{./wildfly-10.0.0.CR5-SNAPSHOT/bin/standalone.sh -c standalone-full-ha.xml}}
> This leads to:
> {code}
> 14:11:22,473 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "tinyRemoteEjb-server-ee7.jar")]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
> "Services that were unable to start:" => [
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".CdiValidatorFactoryService",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".WeldStartService",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".component.MyBeanImpl.CREATE",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".component.MyBeanImpl.JndiBindingsService",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".component.MyBeanImpl.START",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".component.MyBeanImpl.VIEW.\"cz.ladicek.tinyRemoteEjb.server.MyBean\".REMOTE",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".component.MyBeanImpl.WeldInstantiator",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".component.MyBeanImpl.WeldInterceptorBindingsService",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".deploymentCompleteService",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".jndiDependencyService",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".moduleDeploymentRuntimeInformation",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".moduleDeploymentRuntimeInformationStart",
> "jboss.naming.context.java.app.tinyRemoteEjb-server-ee7.tinyRemoteEjb-server-ee7.MyBeanImpl",
> "jboss.naming.context.java.app.tinyRemoteEjb-server-ee7.tinyRemoteEjb-server-ee7.\"MyBeanImpl!cz.ladicek.tinyRemoteEjb.server.MyBean\"",
> "jboss.naming.context.java.global.tinyRemoteEjb-server-ee7.MyBeanImpl",
> "jboss.naming.context.java.global.tinyRemoteEjb-server-ee7.\"MyBeanImpl!cz.ladicek.tinyRemoteEjb.server.MyBean\"",
> "jboss.naming.context.java.module.tinyRemoteEjb-server-ee7.tinyRemoteEjb-server-ee7.MyBeanImpl",
> "jboss.naming.context.java.module.tinyRemoteEjb-server-ee7.tinyRemoteEjb-server-ee7.\"MyBeanImpl!cz.ladicek.tinyRemoteEjb.server.MyBean\""
> ],
> "Services that may be the cause:" => ["jboss.clustering.registry.ejb2.client-mappings"]
> }}
> 14:11:22,476 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "ejb3"),
> ("service" => "remote")
> ]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.ejb.remoting.connector.client-mappings.installer is missing [jboss.clustering.registry.ejb2.client-mappings]"]}
> {code}
> This works perfectly fine in 10.0.0.CR4, so I did a {{git bisect}} and traced the problem to this commit: https://github.com/wildfly/wildfly/commit/232dff042f The error message mentions that an {{...ejb2.client-mappings}} service is missing, which is consistent with the commit message (also mentions client mappings).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFLY-5752) Can't rename the "ejb" cache container
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-5752?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-5752:
------------------------------------
OK - I see what you mean - if you diddochange the cache container - there's a missing service.
> Can't rename the "ejb" cache container
> --------------------------------------
>
> Key: WFLY-5752
> URL: https://issues.jboss.org/browse/WFLY-5752
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Reporter: Ladislav Thon
> Assignee: Paul Ferraro
> Priority: Blocker
> Attachments: tinyRemoteEjb-server-ee7.jar
>
>
> When I rename the {{ejb}} cache container, deploying a simple app that contains an EJB ends with a horrible error message. This is a blocker, because renaming a cache container is required for a 2clusters scenario (standalone client invoking a remote EJB in cluster A, that EJB in turns invokes a remote EJB in cluster B, and forwards the response to the original client).
> More details:
> 1. build current WildFly master and {{unzip .../wildfly/build/target/wildfly-10.0.0.CR5-SNAPSHOT.zip}}
> 2. {{cp tinyRemoteEjb-server-ee7.jar wildfly-10.0.0.CR5-SNAPSHOT/standalone/deployments/}} # the JAR is attached
> 3. change the {{wildfly-10.0.0.CR5-SNAPSHOT/standalone/configuration/standalone-full-ha.xml}} file like this:
> {code}
> <!-- in the "ejb3" subsystem -->
> <passivation-store name="infinispan" cache-container="ejb2" max-size="10000"/>
> <remote cluster="ejb2" connector-ref="http-remoting-connector" thread-pool-name="default"/>
> <!-- in the "infinispan" subsystem -->
> <cache-container name="ejb2" ...>
> {code}
> 4. {{./wildfly-10.0.0.CR5-SNAPSHOT/bin/standalone.sh -c standalone-full-ha.xml}}
> This leads to:
> {code}
> 14:11:22,473 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "tinyRemoteEjb-server-ee7.jar")]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
> "Services that were unable to start:" => [
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".CdiValidatorFactoryService",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".WeldStartService",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".component.MyBeanImpl.CREATE",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".component.MyBeanImpl.JndiBindingsService",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".component.MyBeanImpl.START",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".component.MyBeanImpl.VIEW.\"cz.ladicek.tinyRemoteEjb.server.MyBean\".REMOTE",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".component.MyBeanImpl.WeldInstantiator",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".component.MyBeanImpl.WeldInterceptorBindingsService",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".deploymentCompleteService",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".jndiDependencyService",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".moduleDeploymentRuntimeInformation",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".moduleDeploymentRuntimeInformationStart",
> "jboss.naming.context.java.app.tinyRemoteEjb-server-ee7.tinyRemoteEjb-server-ee7.MyBeanImpl",
> "jboss.naming.context.java.app.tinyRemoteEjb-server-ee7.tinyRemoteEjb-server-ee7.\"MyBeanImpl!cz.ladicek.tinyRemoteEjb.server.MyBean\"",
> "jboss.naming.context.java.global.tinyRemoteEjb-server-ee7.MyBeanImpl",
> "jboss.naming.context.java.global.tinyRemoteEjb-server-ee7.\"MyBeanImpl!cz.ladicek.tinyRemoteEjb.server.MyBean\"",
> "jboss.naming.context.java.module.tinyRemoteEjb-server-ee7.tinyRemoteEjb-server-ee7.MyBeanImpl",
> "jboss.naming.context.java.module.tinyRemoteEjb-server-ee7.tinyRemoteEjb-server-ee7.\"MyBeanImpl!cz.ladicek.tinyRemoteEjb.server.MyBean\""
> ],
> "Services that may be the cause:" => ["jboss.clustering.registry.ejb2.client-mappings"]
> }}
> 14:11:22,476 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "ejb3"),
> ("service" => "remote")
> ]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.ejb.remoting.connector.client-mappings.installer is missing [jboss.clustering.registry.ejb2.client-mappings]"]}
> {code}
> This works perfectly fine in 10.0.0.CR4, so I did a {{git bisect}} and traced the problem to this commit: https://github.com/wildfly/wildfly/commit/232dff042f The error message mentions that an {{...ejb2.client-mappings}} service is missing, which is consistent with the commit message (also mentions client mappings).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFLY-5752) Can't rename the "ejb" cache container
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-5752?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-5752:
------------------------------------
In EAP7, the cluster name is independent of the cache-container name. The cluster name is driven by the associated channel as defined by the jgroups subsystem.
> Can't rename the "ejb" cache container
> --------------------------------------
>
> Key: WFLY-5752
> URL: https://issues.jboss.org/browse/WFLY-5752
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Reporter: Ladislav Thon
> Assignee: Paul Ferraro
> Priority: Blocker
> Attachments: tinyRemoteEjb-server-ee7.jar
>
>
> When I rename the {{ejb}} cache container, deploying a simple app that contains an EJB ends with a horrible error message. This is a blocker, because renaming a cache container is required for a 2clusters scenario (standalone client invoking a remote EJB in cluster A, that EJB in turns invokes a remote EJB in cluster B, and forwards the response to the original client).
> More details:
> 1. build current WildFly master and {{unzip .../wildfly/build/target/wildfly-10.0.0.CR5-SNAPSHOT.zip}}
> 2. {{cp tinyRemoteEjb-server-ee7.jar wildfly-10.0.0.CR5-SNAPSHOT/standalone/deployments/}} # the JAR is attached
> 3. change the {{wildfly-10.0.0.CR5-SNAPSHOT/standalone/configuration/standalone-full-ha.xml}} file like this:
> {code}
> <!-- in the "ejb3" subsystem -->
> <passivation-store name="infinispan" cache-container="ejb2" max-size="10000"/>
> <remote cluster="ejb2" connector-ref="http-remoting-connector" thread-pool-name="default"/>
> <!-- in the "infinispan" subsystem -->
> <cache-container name="ejb2" ...>
> {code}
> 4. {{./wildfly-10.0.0.CR5-SNAPSHOT/bin/standalone.sh -c standalone-full-ha.xml}}
> This leads to:
> {code}
> 14:11:22,473 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "tinyRemoteEjb-server-ee7.jar")]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
> "Services that were unable to start:" => [
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".CdiValidatorFactoryService",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".WeldStartService",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".component.MyBeanImpl.CREATE",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".component.MyBeanImpl.JndiBindingsService",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".component.MyBeanImpl.START",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".component.MyBeanImpl.VIEW.\"cz.ladicek.tinyRemoteEjb.server.MyBean\".REMOTE",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".component.MyBeanImpl.WeldInstantiator",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".component.MyBeanImpl.WeldInterceptorBindingsService",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".deploymentCompleteService",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".jndiDependencyService",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".moduleDeploymentRuntimeInformation",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".moduleDeploymentRuntimeInformationStart",
> "jboss.naming.context.java.app.tinyRemoteEjb-server-ee7.tinyRemoteEjb-server-ee7.MyBeanImpl",
> "jboss.naming.context.java.app.tinyRemoteEjb-server-ee7.tinyRemoteEjb-server-ee7.\"MyBeanImpl!cz.ladicek.tinyRemoteEjb.server.MyBean\"",
> "jboss.naming.context.java.global.tinyRemoteEjb-server-ee7.MyBeanImpl",
> "jboss.naming.context.java.global.tinyRemoteEjb-server-ee7.\"MyBeanImpl!cz.ladicek.tinyRemoteEjb.server.MyBean\"",
> "jboss.naming.context.java.module.tinyRemoteEjb-server-ee7.tinyRemoteEjb-server-ee7.MyBeanImpl",
> "jboss.naming.context.java.module.tinyRemoteEjb-server-ee7.tinyRemoteEjb-server-ee7.\"MyBeanImpl!cz.ladicek.tinyRemoteEjb.server.MyBean\""
> ],
> "Services that may be the cause:" => ["jboss.clustering.registry.ejb2.client-mappings"]
> }}
> 14:11:22,476 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "ejb3"),
> ("service" => "remote")
> ]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.ejb.remoting.connector.client-mappings.installer is missing [jboss.clustering.registry.ejb2.client-mappings]"]}
> {code}
> This works perfectly fine in 10.0.0.CR4, so I did a {{git bisect}} and traced the problem to this commit: https://github.com/wildfly/wildfly/commit/232dff042f The error message mentions that an {{...ejb2.client-mappings}} service is missing, which is consistent with the commit message (also mentions client mappings).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months