[JBoss JIRA] (WFLY-10463) Weak affinity set up by EJB client 4 is not followed with invocations running against stateful bean deploment on WildFly 13
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-10463?page=com.atlassian.jira.plugin... ]
Paul Ferraro reopened WFLY-10463:
---------------------------------
Spoke too soon. The issue isn't that the client isn't honoring the weak affinity. The problem is that the server can report an incorrect weak affinity - and the client does as it is told.
Fix on the way.
> Weak affinity set up by EJB client 4 is not followed with invocations running against stateful bean deploment on WildFly 13
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10463
> URL: https://issues.jboss.org/browse/WFLY-10463
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 13.0.0.Beta1
> Environment: WildFly 13 beta runtimes. EJB client version does not matter (tested with {{org.wildfly:wildfly-ejb-client-bom:12.0.0.Final}}).
> Reporter: Michal Jurc
> Assignee: Paul Ferraro
> Priority: Blocker
> Attachments: repro.zip
>
>
> Remote EJB client with {{InitialContext}} setting up weak affinity will not hold up the affinity, resulting in a behaviour that's different to previous releases of WildFly. In previous versions of WildFly, {{java.naming.provider.url}} property of {{InitialContext}} was enough to enforce weak affinity to a node in remote EJB client.
> This is a regression compared to WildFly 12. The client version does not change the behaviour, which leads me to believe the issue is server-side.
> Update: The issue affects only stateful bean invocations.
> {code}
> while (true) {
> try {
> final Properties props = new Properties();
> props.put(Context.INITIAL_CONTEXT_FACTORY, WildFlyInitialContextFactory.class.getName());
> props.put(Context.PROVIDER_URL, "remote+http://127.0.0.1:8080");
> final InitialContext ejbCtx = new InitialContext(props);
> final HelloBeanRemote bean = (HelloBeanRemote) ejbCtx
> .lookup("ejb:/server/HelloBean!" + HelloBeanRemote.class.getName() + "?stateful");
> for (int i = 0; i < 10; i++) {
> System.out.println(bean.hello());
> }
> } catch(Exception e) {
> System.out.println("Call failed!!!!");
> e.printStackTrace();
> }
> final Properties props = new Properties();
> props.put(Context.INITIAL_CONTEXT_FACTORY, WildFlyInitialContextFactory.class.getName());
> props.put(Context.PROVIDER_URL, "remote+http://127.0.0.1:8080");
> {code}
> {code}11:56:02,452 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"):
> node1, 0
> 11:56:02,460 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"):
> node1, 1
> 11:56:02,465 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"):
> node1, 2
> 11:56:02,472 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"):
> node1, 3
> 11:56:02,477 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"):
> node1, 4
> 11:56:02,488 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"):
> node1, 5
> 11:56:02,496 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"):
> node1, 6
> 11:56:02,502 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"):
> node1, 7
> 11:56:02,507 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"):
> node1, 8
> 11:56:02,515 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"):
> node1, 9
> 11:56:03,535 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"):
> node2, 0
> 11:56:03,544 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"):
> node2, 1
> 11:56:03,555 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"):
> node2, 2
> 11:56:03,561 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"):
> node2, 3
> 11:56:03,568 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"):
> node2, 4
> 11:56:03,586 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"):
> node2, 5
> 11:56:03,595 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"):
> node2, 6
> 11:56:03,602 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"):
> node2, 7
> 11:56:03,616 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"):
> node2, 8
> 11:56:03,628 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"):
> node2, 9
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10476) 7.2 - Migration Guide: Upgrade org.apache.santuario.xmlsec to 2.1.1. caused regression in PicketLinkSTS
by Sande Gilda (JIRA)
Sande Gilda created WFLY-10476:
----------------------------------
Summary: 7.2 - Migration Guide: Upgrade org.apache.santuario.xmlsec to 2.1.1. caused regression in PicketLinkSTS
Key: WFLY-10476
URL: https://issues.jboss.org/browse/WFLY-10476
Project: WildFly
Issue Type: Bug
Components: Security
Affects Versions: 12.0.0.Beta1
Reporter: Sande Gilda
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)
7 years, 11 months
[JBoss JIRA] (WFLY-9892) Upgrade org.apache.santuario.xmlsec to 2.1.1. caused regression in PicketLinkSTS
by Derek Horton (JIRA)
[ https://issues.jboss.org/browse/WFLY-9892?page=com.atlassian.jira.plugin.... ]
Derek Horton commented on WFLY-9892:
------------------------------------
Does using -Dorg.apache.xml.security.ignoreLineBreaks=true cause the xml to be generated without the line breaks? If so, perhaps it is possible to set this option directly on the xml signature code?
> 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)
7 years, 11 months
[JBoss JIRA] (WFCORE-3891) Cannot create xml-formatter and json-formatter with the same name as existing resources in logging subsystem
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3891?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFCORE-3891:
---------------------------------------
I suppose we could create a new resource when the {{formatter}} attribute is used. We could also come up with a better naming convention to hopefully avoid conflicts. We could use something like {{$HANDLER_NAME-pattern-formatter}} which could still create a conflict, but would be less likely to.
> Cannot create xml-formatter and json-formatter with the same name as existing resources in logging subsystem
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3891
> URL: https://issues.jboss.org/browse/WFCORE-3891
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: Nikoleta Žiaková
> Assignee: James Perkins
>
> When trying to create an {{xml-formatter}} or {{json-formatter}} with the same name as another resource (e.g. a {{file-handler}}), the operation fails:
> {code}
> [standalone@localhost:9990 /] /subsystem=logging/file-handler=test:add(file={path=aaa.log})
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=logging/xml-formatter=test:add
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: No property \"dateFormat\" setter found for formatter \"test\"",
> "rolled-back" => true
> }
> {code}
> Similarly vice-versa, when trying to create another resource in logging subsystem with the same name as an {{xml-formatter}} or a {{json-formatter}}, the operation fails:
> {code}
> [standalone@localhost:9990 /] /subsystem=logging/json-formatter=test:add
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=logging/file-handler=test:add(file={path=test.log})
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: No property \"pattern\" setter found for formatter \"test\"",
> "rolled-back" => true
> }
> {code}
> The same scenario works for e.g. {{pattern-formatter}}:
> {code}
> [standalone@localhost:9990 /] /subsystem=logging/file-handler=test:add(file={path=test.log})
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=logging/pattern-formatter=test:add
> {"outcome" => "success"}
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months