[JBoss JIRA] (DROOLS-2351) [DMN Editor] Move Editor controls inline. Sync menu bar with context menu
by Michael Anstis (JIRA)
Michael Anstis created DROOLS-2351:
--------------------------------------
Summary: [DMN Editor] Move Editor controls inline. Sync menu bar with context menu
Key: DROOLS-2351
URL: https://issues.jboss.org/browse/DROOLS-2351
Project: Drools
Issue Type: Enhancement
Components: DMN Editor
Reporter: Michael Anstis
Assignee: Michael Anstis
Following DROOLS-2272 the decision was made to have single right-click open a context menu "inline" in the editor (standard context menu stuff). However the actions on the context menu need also to be made available on the menu bar so Users can either use the menu bar or context menu.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9892) Upgrade org.apache.santuario.xmlsec to 2.1.1. caused regression in PicketLinkSTS
by Pedro Igor (JIRA)
[ https://issues.jboss.org/browse/WFLY-9892?page=com.atlassian.jira.plugin.... ]
Pedro Igor reassigned WFLY-9892:
--------------------------------
Assignee: Pedro Igor
> Upgrade org.apache.santuario.xmlsec to 2.1.1. caused regression in PicketLinkSTS
> --------------------------------------------------------------------------------
>
> Key: WFLY-9892
> URL: https://issues.jboss.org/browse/WFLY-9892
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 12.0.0.Beta1
> Reporter: Ondrej Lukas
> Assignee: Pedro Igor
> Priority: Blocker
> Attachments: ejb-security-picketlink.zip, ejb-test.jar, picketlink-sts.war, sts-config.properties
>
>
> When token from PicketLink STS is issued and signed then it is not able to be used for authentication through Remoting in WildFly 12 (i.e. it cannot be set as {{remote.connection.main.password}} property which can be used in PicketLink {{org.picketlink.identity.federation.bindings.jboss.auth.SAML2STSLoginModule}}). It seems it is caused by upgrade of org.apache.santuario.xmlsec to version 2.1.1. [1]. When WILDFLY11_HOME/modules/system/layers/base/org/apache/santuario/xmlsec/main/xmlsec-2.0.8.jar is placed to WildFly 12 modules then it works correctly.
> We report it as a blocker since it is regression - application which works correctly on WildFly 11 stops to work on WildFly 12 - users are not able to authenticate through Remoting with signed tokens from PicketLink STS correctly.
> Remoting fails due to following exception:
> {code}
> java.lang.IllegalArgumentException: ELY05131: Invalid ASCII control "0xA"
> at org.wildfly.security.sasl.util.StringPrep.forbidAsciiControl(StringPrep.java:117)
> at org.wildfly.security.sasl.util.StringPrep.encode(StringPrep.java:295)
> at org.wildfly.security.sasl.util.StringPrep.encode(StringPrep.java:196)
> at org.wildfly.security.sasl.plain.PlainSaslClient.evaluateChallenge(PlainSaslClient.java:95)
> at org.wildfly.security.sasl.util.AbstractDelegatingSaslClient.evaluateChallenge(AbstractDelegatingSaslClient.java:54)
> at org.wildfly.security.sasl.util.PrivilegedSaslClient.lambda$evaluateChallenge$0(PrivilegedSaslClient.java:55)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.wildfly.security.sasl.util.PrivilegedSaslClient.evaluateChallenge(PrivilegedSaslClient.java:55)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.lambda$handleEvent$1(ClientConnectionOpenListener.java:460)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:926)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1979)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1481)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1374)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> It is caused by different formating value of SignatureValue in assertion. In WildFly 11 SignatureValue looks like:
> {code}
> <dsig:SignatureValue xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">nFVkKrXTyYEQ9cwc9OOgySYebEtwzw4alVYP0viXzvqZAUAKtAXEBAfDB8xIOms78twlDdq79MiSvk8OrOdf126Kw/IR8JRn1fYyZ5tsIRcNoTXMgGaTqhrn/HKlLqqqHhVHrJURunqkSzTTxylA2AEPhEDD5Y7hS0W2ZZCeSvuri+PRDSTrRnuedz0yQuHQu1mZ0gjoEFbHh4Wkkn5Ac1R4gmewmmzPud+ZE6Ux4YpeHzQ8rAvZ4bDk6j+eQIRsSxFTLo5RSA3FWN8+lUNV/CSRqBPXsK7QxOaTdBgF+4NXWeExrNJ9SeVFcf9yelvReAtR2JNZ6DUY8u45KtXmLw==</dsig:SignatureValue>
> {code}
> In WildFly 12 it looks like (there are end of lines):
> {code}
> <dsig:SignatureValue xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">cUNpFJIZlLYrBDZtQSTDrq2K6PbnAHyg2qbx/D5FuB4XMjdQ5oxQjkMejLyelnA7s4GFusoLhahl
> qlTOT8UrOyxrR4yYAmJ/e5s+f4gys926+tbiraT/3/wG8wM/Lvcjvk5Ap69zODuRYpypsWfA4jrI
> 7TTBXVPGy8g4KUdnFviUiTuFTc2Ghgxp53AmUuLis/THyP28jE7+28//q8bi/bQrFwHC6tWX67+N
> K1duFCOcQ6IPIKeVrePZz55Ivgl+WWdkF6uYCz5IdMzurhzmeQ3K8DAMIxz/MG67VWJIOnuGNWF7
> nmdye5zd9AFcRsr1XadvZJCbGNfuc89AL5inCg==</dsig:SignatureValue>
> {code}
> [1] https://github.com/wildfly/wildfly/commit/536de514829f2187abf1126c8916a04...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9892) Upgrade org.apache.santuario.xmlsec to 2.1.1. caused regression in PicketLinkSTS
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-9892?page=com.atlassian.jira.plugin.... ]
Farah Juma commented on WFLY-9892:
----------------------------------
[~pcraveiro] It would be great if you could look at this one. Thanks!
> Upgrade org.apache.santuario.xmlsec to 2.1.1. caused regression in PicketLinkSTS
> --------------------------------------------------------------------------------
>
> Key: WFLY-9892
> URL: https://issues.jboss.org/browse/WFLY-9892
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 12.0.0.Beta1
> Reporter: Ondrej Lukas
> Priority: Blocker
> Attachments: ejb-security-picketlink.zip, ejb-test.jar, picketlink-sts.war, sts-config.properties
>
>
> When token from PicketLink STS is issued and signed then it is not able to be used for authentication through Remoting in WildFly 12 (i.e. it cannot be set as {{remote.connection.main.password}} property which can be used in PicketLink {{org.picketlink.identity.federation.bindings.jboss.auth.SAML2STSLoginModule}}). It seems it is caused by upgrade of org.apache.santuario.xmlsec to version 2.1.1. [1]. When WILDFLY11_HOME/modules/system/layers/base/org/apache/santuario/xmlsec/main/xmlsec-2.0.8.jar is placed to WildFly 12 modules then it works correctly.
> We report it as a blocker since it is regression - application which works correctly on WildFly 11 stops to work on WildFly 12 - users are not able to authenticate through Remoting with signed tokens from PicketLink STS correctly.
> Remoting fails due to following exception:
> {code}
> java.lang.IllegalArgumentException: ELY05131: Invalid ASCII control "0xA"
> at org.wildfly.security.sasl.util.StringPrep.forbidAsciiControl(StringPrep.java:117)
> at org.wildfly.security.sasl.util.StringPrep.encode(StringPrep.java:295)
> at org.wildfly.security.sasl.util.StringPrep.encode(StringPrep.java:196)
> at org.wildfly.security.sasl.plain.PlainSaslClient.evaluateChallenge(PlainSaslClient.java:95)
> at org.wildfly.security.sasl.util.AbstractDelegatingSaslClient.evaluateChallenge(AbstractDelegatingSaslClient.java:54)
> at org.wildfly.security.sasl.util.PrivilegedSaslClient.lambda$evaluateChallenge$0(PrivilegedSaslClient.java:55)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.wildfly.security.sasl.util.PrivilegedSaslClient.evaluateChallenge(PrivilegedSaslClient.java:55)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.lambda$handleEvent$1(ClientConnectionOpenListener.java:460)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:926)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1979)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1481)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1374)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> It is caused by different formating value of SignatureValue in assertion. In WildFly 11 SignatureValue looks like:
> {code}
> <dsig:SignatureValue xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">nFVkKrXTyYEQ9cwc9OOgySYebEtwzw4alVYP0viXzvqZAUAKtAXEBAfDB8xIOms78twlDdq79MiSvk8OrOdf126Kw/IR8JRn1fYyZ5tsIRcNoTXMgGaTqhrn/HKlLqqqHhVHrJURunqkSzTTxylA2AEPhEDD5Y7hS0W2ZZCeSvuri+PRDSTrRnuedz0yQuHQu1mZ0gjoEFbHh4Wkkn5Ac1R4gmewmmzPud+ZE6Ux4YpeHzQ8rAvZ4bDk6j+eQIRsSxFTLo5RSA3FWN8+lUNV/CSRqBPXsK7QxOaTdBgF+4NXWeExrNJ9SeVFcf9yelvReAtR2JNZ6DUY8u45KtXmLw==</dsig:SignatureValue>
> {code}
> In WildFly 12 it looks like (there are end of lines):
> {code}
> <dsig:SignatureValue xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">cUNpFJIZlLYrBDZtQSTDrq2K6PbnAHyg2qbx/D5FuB4XMjdQ5oxQjkMejLyelnA7s4GFusoLhahl
> qlTOT8UrOyxrR4yYAmJ/e5s+f4gys926+tbiraT/3/wG8wM/Lvcjvk5Ap69zODuRYpypsWfA4jrI
> 7TTBXVPGy8g4KUdnFviUiTuFTc2Ghgxp53AmUuLis/THyP28jE7+28//q8bi/bQrFwHC6tWX67+N
> K1duFCOcQ6IPIKeVrePZz55Ivgl+WWdkF6uYCz5IdMzurhzmeQ3K8DAMIxz/MG67VWJIOnuGNWF7
> nmdye5zd9AFcRsr1XadvZJCbGNfuc89AL5inCg==</dsig:SignatureValue>
> {code}
> [1] https://github.com/wildfly/wildfly/commit/536de514829f2187abf1126c8916a04...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9706) Newly added InfiniteOrPositiveValidators to messaging attributes should just print warning if negative values are not -1
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-9706?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-9706:
-----------------------------------
WFCORE-3651 is preventing backwards compatibility.
> Newly added InfiniteOrPositiveValidators to messaging attributes should just print warning if negative values are not -1
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9706
> URL: https://issues.jboss.org/browse/WFLY-9706
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 12.0.0.Beta1
> Reporter: Erich Duda
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> This Jira is reaction to WFLY-9433.
> The WFLY-9433 makes validator rules more strict for some attributes in messaging subsystem. Although there is no reason to use these values (which are newly considered as invalid), it was possible to configure them and they worked with Wildfly 11 and previous releases.
> As it is proposed in JBEAP-14110, this change should be done in 2 steps:
> * only WARN the user if the parameter is not valid (a negative value other than -1)
> * in next release, reject the parameter
> I am setting priority as Blocker, because this fix must be included in Wildfly 12 release. It makes no sense to do it later.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9910) CustomUndertowFilterTestCase fails to reload server if node0!=localhost
by Petr Kremensky (JIRA)
Petr Kremensky created WFLY-9910:
------------------------------------
Summary: CustomUndertowFilterTestCase fails to reload server if node0!=localhost
Key: WFLY-9910
URL: https://issues.jboss.org/browse/WFLY-9910
Project: WildFly
Issue Type: Bug
Components: Test Suite
Affects Versions: 12.0.0.Beta1
Reporter: Petr Kremensky
Assignee: Petr Kremensky
org.jboss.as.test.manualmode.undertow.CustomUndertowFilterTestCase stuck on server reload
{noformat}
ServerReload.executeReloadAndWaitForCompletion(controllerClient);
{noformat}
if node0!=localhost. Use
{noformat}
serverController.reload();
{noformat}
instead.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3651) ParameterCorrector are not taken into account when XML is parsed
by Jeff Mesnil (JIRA)
Jeff Mesnil created WFCORE-3651:
-----------------------------------
Summary: ParameterCorrector are not taken into account when XML is parsed
Key: WFCORE-3651
URL: https://issues.jboss.org/browse/WFCORE-3651
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 4.0.0.Beta2
Reporter: Jeff Mesnil
Assignee: Jeff Mesnil
Fix For: 4.0.0.CR1
The ParameterCorrector of an AttributeDefinition must attempt to correct the value before the value is validated against the AttributeDefinition's ParameterValidator.
This works fine when DMR operations are executed against the server.
However, this fails when XML is parsed as the XML parser is validating the value without correcting it first.
I encounter this issue in WFLY-9706 when the validator constrains to use only -1 instead of any negative value.
If I had a ParameterCorrect that correct any negative values (e.g. -3) to -1, the XML parser fails because the value (-3) is not valid (must be -1).
Using :write-attribute works fine as the ParameterCorrect will correct -3 to -1 before it is validated.
The simple short term fix is to call the ParameterCorrect when the XML parser read the attribute before it validates its value.
However this duplicates code that is already done in AttributeDefinition.validateAndSet.
We could handle all this logic (correction/validation) only when the DMP operations are executed.
However doing so would make it impossible to report informative XML errors as the user would have to find how the faulty DMR op map to the XML file he provided.
So keeping this logic of correction/validation when XML is parsed is useful for error reporting but it should delegate to some methods of AttributeDefinition instead of duplicating the code (and missing some cases such as parameter correction)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3651) ParameterCorrector are not taken into account by XML parser
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3651?page=com.atlassian.jira.plugi... ]
Jeff Mesnil updated WFCORE-3651:
--------------------------------
Summary: ParameterCorrector are not taken into account by XML parser (was: ParameterCorrector are not taken into account when XML is parsed)
> ParameterCorrector are not taken into account by XML parser
> -----------------------------------------------------------
>
> Key: WFCORE-3651
> URL: https://issues.jboss.org/browse/WFCORE-3651
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 4.0.0.Beta2
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Fix For: 4.0.0.CR1
>
>
> The ParameterCorrector of an AttributeDefinition must attempt to correct the value before the value is validated against the AttributeDefinition's ParameterValidator.
> This works fine when DMR operations are executed against the server.
> However, this fails when XML is parsed as the XML parser is validating the value without correcting it first.
> I encounter this issue in WFLY-9706 when the validator constrains to use only -1 instead of any negative value.
> If I had a ParameterCorrect that correct any negative values (e.g. -3) to -1, the XML parser fails because the value (-3) is not valid (must be -1).
> Using :write-attribute works fine as the ParameterCorrect will correct -3 to -1 before it is validated.
> The simple short term fix is to call the ParameterCorrect when the XML parser read the attribute before it validates its value.
> However this duplicates code that is already done in AttributeDefinition.validateAndSet.
> We could handle all this logic (correction/validation) only when the DMP operations are executed.
> However doing so would make it impossible to report informative XML errors as the user would have to find how the faulty DMR op map to the XML file he provided.
> So keeping this logic of correction/validation when XML is parsed is useful for error reporting but it should delegate to some methods of AttributeDefinition instead of duplicating the code (and missing some cases such as parameter correction)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3651) ParameterCorrector are not taken into account by XML parser
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3651?page=com.atlassian.jira.plugi... ]
Jeff Mesnil updated WFCORE-3651:
--------------------------------
Description:
The ParameterCorrector of an AttributeDefinition must attempt to correct the value before the value is validated against the AttributeDefinition's ParameterValidator.
This works fine when DMR operations are executed against the server.
However, this fails when XML is parsed as the XML parser is validating the value without correcting it first.
I encounter this issue in WFLY-9706 when the validator constrains to use only -1 instead of any negative value.
If I had a ParameterCorrect that correct any negative values (e.g. -3) to -1, the XML parser fails because the value (-3) is not valid (must be -1).
Using :write-attribute works fine as the ParameterCorrect will correct -3 to -1 before it is validated.
The simple short term fix is to call the ParameterCorrect when the XML parser read the attribute before it validates its value.
However this duplicates code that is already done in AttributeDefinition.validateAndSet.
We could handle all this logic (correction/validation) only when the DMR operations are executed.
However doing so would make it impossible to report informative XML errors as the user would have to find how the faulty DMR op map to the XML file he provided.
So keeping this logic of correction/validation when XML is parsed is useful for error reporting but it should delegate to some methods of AttributeDefinition instead of duplicating the code (and missing some cases such as parameter correction)
was:
The ParameterCorrector of an AttributeDefinition must attempt to correct the value before the value is validated against the AttributeDefinition's ParameterValidator.
This works fine when DMR operations are executed against the server.
However, this fails when XML is parsed as the XML parser is validating the value without correcting it first.
I encounter this issue in WFLY-9706 when the validator constrains to use only -1 instead of any negative value.
If I had a ParameterCorrect that correct any negative values (e.g. -3) to -1, the XML parser fails because the value (-3) is not valid (must be -1).
Using :write-attribute works fine as the ParameterCorrect will correct -3 to -1 before it is validated.
The simple short term fix is to call the ParameterCorrect when the XML parser read the attribute before it validates its value.
However this duplicates code that is already done in AttributeDefinition.validateAndSet.
We could handle all this logic (correction/validation) only when the DMP operations are executed.
However doing so would make it impossible to report informative XML errors as the user would have to find how the faulty DMR op map to the XML file he provided.
So keeping this logic of correction/validation when XML is parsed is useful for error reporting but it should delegate to some methods of AttributeDefinition instead of duplicating the code (and missing some cases such as parameter correction)
> ParameterCorrector are not taken into account by XML parser
> -----------------------------------------------------------
>
> Key: WFCORE-3651
> URL: https://issues.jboss.org/browse/WFCORE-3651
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 4.0.0.Beta2
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Fix For: 4.0.0.CR1
>
>
> The ParameterCorrector of an AttributeDefinition must attempt to correct the value before the value is validated against the AttributeDefinition's ParameterValidator.
> This works fine when DMR operations are executed against the server.
> However, this fails when XML is parsed as the XML parser is validating the value without correcting it first.
> I encounter this issue in WFLY-9706 when the validator constrains to use only -1 instead of any negative value.
> If I had a ParameterCorrect that correct any negative values (e.g. -3) to -1, the XML parser fails because the value (-3) is not valid (must be -1).
> Using :write-attribute works fine as the ParameterCorrect will correct -3 to -1 before it is validated.
> The simple short term fix is to call the ParameterCorrect when the XML parser read the attribute before it validates its value.
> However this duplicates code that is already done in AttributeDefinition.validateAndSet.
> We could handle all this logic (correction/validation) only when the DMR operations are executed.
> However doing so would make it impossible to report informative XML errors as the user would have to find how the faulty DMR op map to the XML file he provided.
> So keeping this logic of correction/validation when XML is parsed is useful for error reporting but it should delegate to some methods of AttributeDefinition instead of duplicating the code (and missing some cases such as parameter correction)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9900) EJB client rarely hangs
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-9900?page=com.atlassian.jira.plugin.... ]
Kabir Khan commented on WFLY-9900:
----------------------------------
I think it should not block this late in the 12 cycle, but it would be good to address this early in the 13 cycle
> EJB client rarely hangs
> -----------------------
>
> Key: WFLY-9900
> URL: https://issues.jboss.org/browse/WFLY-9900
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 12.0.0.Beta1
> Reporter: Richard Janík
> Assignee: David Lloyd
>
> Seen in our clustering tests where remote EJB clients invoke beans on 4 servers in cluster, while each of those is being killed and restarted. This is done in sequence and there's plenty of time in between the kill/start/kill-another (1 minute).
> In two ouf our tests, we saw a small number of clients hang and resist termination at the end. The scenarios are:
> [jvmkill-dist-sync|https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/jo...] (36 clients)
> [shutdown-dist-sync|https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/j...] (1 client)
> The hangs are not related to any error or warning message on the server-side. There are ClosedChannelExceptions on the client side, but these seem to be unrelated as the numbers of clients reporting the exceptions are not the same (lower) as the numbers of hanging clients.
> No thread dump as I didn't manage to reproduce yet.
> Might be related to JBEAP-12074 or JBEAP-13169.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9854) jgroups-channel cannot use name which is already used by jgroups/stacks
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-9854?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-9854:
-----------------------------
Affects: Documentation (Ref Guide, User Guide, etc.),Compatibility/Configuration (was: Compatibility/Configuration)
> jgroups-channel cannot use name which is already used by jgroups/stacks
> -----------------------------------------------------------------------
>
> Key: WFLY-9854
> URL: https://issues.jboss.org/browse/WFLY-9854
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, JMS
> Affects Versions: 12.0.0.Beta1
> Reporter: Erich Duda
> Assignee: Paul Ferraro
> Priority: Blocker
>
> The configuration \[1\] results to an error \[2\]. This is backward compatibility issue since the configuration works with previous releases of Wildfly.
> \[1\]
> {code:xml}
> <broadcast-group name="bg-group1" jgroups-stack="udp" jgroups-channel="udp" broadcast-period="2000" connectors="connector"/>
> {code}
> \[2\]
> {code}
> 10:52:29,982 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 15) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "jgroups"),
> ("channel" => "udp")
> ]) - failure description: "WFLYCTL0436: Cannot register capability 'org.wildfly.clustering.jgroups.channel-factory.udp' at location '[
> (\"subsystem\" => \"jgroups\"),
> (\"channel\" => \"udp\")
> ]' as it is already registered in context 'global' at location(s) '[[
> (\"subsystem\" => \"jgroups\"),
> (\"stack\" => \"udp\")
> ]]'"
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months