[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)
10 years, 7 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)
10 years, 7 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)
10 years, 7 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)
10 years, 7 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)
10 years, 7 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)
10 years, 7 months
[JBoss JIRA] (WFLY-5756) Unable to exclude root context (/) via excluded-contexts in mod_cluster subsystem
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5756?page=com.atlassian.jira.plugin.... ]
Radoslav Husar edited comment on WFLY-5756 at 12/2/15 10:12 AM:
----------------------------------------------------------------
-Unfortunately, org.jboss.modcluster.config.impl.ModClusterConfig#setExcludedContexts processes in a way that "ROOT" becomes "" internally and "/" becomes "//" because its prepended but the actual get context returns "/" in WF.-
Settled down on MODCLUSTER-473 that this is a contract of the API, MODCLUSTER-473 is making that explicit via JavaDoc. The actual fix will happen in WF code.
was (Author: rhusar):
Unfortunately, org.jboss.modcluster.config.impl.ModClusterConfig#setExcludedContexts processes in a way that "ROOT" becomes "" internally and "/" becomes "//" because its prepended but the actual get context returns "/" in WF.
> Unable to exclude root context (/) via excluded-contexts in mod_cluster subsystem
> ---------------------------------------------------------------------------------
>
> Key: WFLY-5756
> URL: https://issues.jboss.org/browse/WFLY-5756
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR4
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
>
> {noformat}[standalone@localhost:9990 /] /subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=excluded-contexts,value="ROOT,/"{noformat}
> but no luck
> {noformat}
> mod_cluster/1.3.2.Alpha1-SNAPSHOT
> Auto Refresh show DUMP output show INFO output
> Node localhost (ajp://127.0.0.1:8009):
> Enable Contexts Disable Contexts Stop Contexts
> Balancer: syrah-cluster,LBGroup: ,Flushpackets: Off,Flushwait: 10000,Ping: 10000000,Smax: 26,Ttl: 60000000,Status: OK,Elected: 0,Read: 0,Transferred: 0,Connected: 0,Load: 77
> Virtual Host 1:
> Contexts:
> /clusterbench-passivating, Status: ENABLED Request: 0 Disable Stop
> /, Status: ENABLED Request: 0 Disable Stop
> Aliases:
> localhost
> default-host
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (DROOLS-993) Drools throws CCE when using global SessionClock in temporal operator
by Duncan Doyle (JIRA)
Duncan Doyle created DROOLS-993:
-----------------------------------
Summary: Drools throws CCE when using global SessionClock in temporal operator
Key: DROOLS-993
URL: https://issues.jboss.org/browse/DROOLS-993
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 6.3.0.Final
Environment: Max OS X 10.11.1, Oracle Hotspot 1.8.0_45
Reporter: Duncan Doyle
Assignee: Mario Fusco
When I insert the PseudoClock as a global in my KieSession, and I use the clock in combination with a temporal operator in a rule, I get the following CCE:
{code}
Caused by: java.lang.ClassCastException: java.lang.Long cannot be cast to java.util.Date
at org.drools.core.base.evaluators.BeforeEvaluatorDefinition$BeforeEvaluator.evaluate(BeforeEvaluatorDefinition.java:301)
at org.drools.core.base.EvaluatorWrapper.evaluate(EvaluatorWrapper.java:94)
... 61 more
{code}
The interesting thing is that this line works:
{code}
$s: SimpleEvent(clock.currentTime after[300s] timestamp)
{code}
while this one fails:
{code}
$s: SimpleEvent(timestamp before[300s] clock.currentTime)
{code}
Reproducer can be found here: https://github.com/DuncanDoyle/drools-cce-issue
Just run 'mvn clean test'.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5762) Messaging replication fails to check-for-live-server on restart
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-5762?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil moved JBEAP-2115 to WFLY-5762:
------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-5762 (was: JBEAP-2115)
Workflow: GIT Pull Request workflow (was: CDW v1)
Component/s: JMS
(was: ActiveMQ)
Target Release: (was: 7.0.0.GA)
Affects Version/s: 10.0.0.CR4
(was: 7.0.0.ER1)
> Messaging replication fails to check-for-live-server on restart
> ---------------------------------------------------------------
>
> Key: WFLY-5762
> URL: https://issues.jboss.org/browse/WFLY-5762
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.CR4
> Reporter: Jeff Mesnil
> Assignee: Andy Taylor
>
> The attached configuration use JGroups.
> I had a look at the code and I suspect the issue is located somewhere when the server1 is restarted and calls its SharedNothingLiveActivation#isNodeIdUsed().
> This method returns false and the server completes its live activation instead of setting its HA policy to replicaPolicy.
> Digging into the code, I looks like DiscoveryGroup#received boolean is never set to true because its corresponding JGroupsBroadcastEndpoint never receives any JGroups message.
> I confirm that server2 is working at that time and does send JGroups message.
> I suspect that there is a bug in the wrapping of JGroups receiver/channel/etc. in org.apache.activemq.artemis.api.core.JGroupsBroadcastEndpoint and the endpoint in DiscoveryGroup never receives the message that is actually received by JGroups in the ReceiverAdapter instantiated by JGroupsBroadcastEndpoint.JChannelWrapper#connect.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months