[JBoss JIRA] (WFLY-9884) WeldResourceInjectionServices runs into NoSuchElementException when deploying multiple EJBs
by Jacob Ilsø (JIRA)
[ https://issues.jboss.org/browse/WFLY-9884?page=com.atlassian.jira.plugin.... ]
Jacob Ilsø commented on WFLY-9884:
----------------------------------
I have tested the most recent PR and still cannot reproduce the issue, so it looks good to me. :)
> WeldResourceInjectionServices runs into NoSuchElementException when deploying multiple EJBs
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-9884
> URL: https://issues.jboss.org/browse/WFLY-9884
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 11.0.0.Final, 12.0.0.Beta1
> Environment: Windows 8.1 Enterprise.
> Reporter: Jacob Ilsø
> Assignee: Jason Greene
> Attachments: log.txt
>
>
> I have an EAR file with several "@Singleton @Startup" beans. Each bean having a number of @Inject and @Resource fields. When I deploy the EAR in WildFly 11 it sometimes fails with a NoSuchElementException (see [^log.txt] for a full stacktrace).
> I cannot reproduce it consistently but it seems to only happen on a "clean" WildFly installation. I haven't seen this on earlier versions of WildFly.
> Let me know if you want me to try to build an EAR for reproducing this.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (ELY-1524) Elytron error message less comprehensive in jdk9 compared to jdk8
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/ELY-1524?page=com.atlassian.jira.plugin.s... ]
Martin Choma commented on ELY-1524:
-----------------------------------
[~jdenise] any idea?
> Elytron error message less comprehensive in jdk9 compared to jdk8
> -----------------------------------------------------------------
>
> Key: ELY-1524
> URL: https://issues.jboss.org/browse/ELY-1524
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Mechanisms
> Affects Versions: 1.2.0.Final
> Reporter: Martin Choma
>
> I like jdk8 error message where there is obvious GS2-KRB5 has been attempted but failed for some reason, PLAIN has been attempted, but failed for some reason.
> {code:title=jdk8}
> Failed to connect to the controller: Unable to authenticate against controller at localhost:9993: Authentication failed: all available authentication mechanisms failed:
> GS2-KRB5: javax.security.sasl.SaslException: GS2-KRB5: Server rejected authentication
> PLAIN: javax.security.sasl.SaslException: ELY05053: Callback handler failed for unknown reason [Caused by java.io.IOException: Failed to read username: Invalid Usage. Prompt attempted in non-interactive mode. Please check commands or change CLI mode.]
> {code}
> Whereas in jdk9 error message hides the fact GS2-KRB5 was attempted and just prints error for PLAIN mechanism, but does not mention explicitely it is PLAIN mechanism
> {code:title=jdk9}
> Failed to connect to the controller: Unable to authenticate against controller at localhost:9993: Cannot get password: Failed to read username: Invalid Usage. Prompt attempted in non-interactive mode. Please check commands or change CLI mode.
> {code}
> This is general question, but I have hit this with this specific use case:
> 1. server is configured to use GS2-KRB5 and PLAIN
> 2. server is configured with TLS
> 3. client is configured to use GS2-KRB5
> 4. expectation is authentication should be not successful because channel binding GS2-KRB5-PLUS should be used.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (JGRP-2253) FD_SOCK is not working in AWS environment
by Sibin Karnavar (JIRA)
[ https://issues.jboss.org/browse/JGRP-2253?page=com.atlassian.jira.plugin.... ]
Sibin Karnavar commented on JGRP-2253:
--------------------------------------
Sure. I will try your suggestion.
external_addr -> All our EC2 nodes are with in same security group and we do not have an external address to expose. All the nodes will be able to communicate with the IP address. Do we really need to define external address? We have not defined this even for TCP configurations .
> FD_SOCK is not working in AWS environment
> -----------------------------------------
>
> Key: JGRP-2253
> URL: https://issues.jboss.org/browse/JGRP-2253
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.10
> Environment: AWS - EC2
> Reporter: Sibin Karnavar
> Assignee: Bela Ban
>
> We have our failure detection defined like below.
> <FD_SOCK external_port="7804" />
> <FD timeout="3000" max_tries="3" />
> <VERIFY_SUSPECT timeout="3000" />
> Please note that we have used FD instead of FD_ALL in AWS. We will be changing it to FD_ALL later after detailed testing.
> In my local, this is working perfect. As soon as I kill my node, I was able to see that view change was happening immediately with FD_SOCK.
> We were not mentioning the external_port in the FD_SOCK but later I thought it may be an issue with the port and defined it as 7804 and added the same port to the security group that allows to access this port among all the nodes. So no issue with the port.
> Can you please let us know if we need any additional configurations to make FD_SOCK works well in AWS.
> Thanks,
> Sibin
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (JGRP-2253) FD_SOCK is not working in AWS environment
by Sibin Karnavar (JIRA)
[ https://issues.jboss.org/browse/JGRP-2253?page=com.atlassian.jira.plugin.... ]
Sibin Karnavar commented on JGRP-2253:
--------------------------------------
When I kill a node , not gracefully, like using kill -9 .
In my local: With FD_SOCK, With in 4 seconds, I can see that other node is detecting that view change. Without FD_SOCK, it was taking around 13 seconds.
In AWS : With/Without FD_SOCK, it was always taking 13 seconds to detect the view change.
> FD_SOCK is not working in AWS environment
> -----------------------------------------
>
> Key: JGRP-2253
> URL: https://issues.jboss.org/browse/JGRP-2253
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.10
> Environment: AWS - EC2
> Reporter: Sibin Karnavar
> Assignee: Bela Ban
>
> We have our failure detection defined like below.
> <FD_SOCK external_port="7804" />
> <FD timeout="3000" max_tries="3" />
> <VERIFY_SUSPECT timeout="3000" />
> Please note that we have used FD instead of FD_ALL in AWS. We will be changing it to FD_ALL later after detailed testing.
> In my local, this is working perfect. As soon as I kill my node, I was able to see that view change was happening immediately with FD_SOCK.
> We were not mentioning the external_port in the FD_SOCK but later I thought it may be an issue with the port and defined it as 7804 and added the same port to the security group that allows to access this port among all the nodes. So no issue with the port.
> Can you please let us know if we need any additional configurations to make FD_SOCK works well in AWS.
> Thanks,
> Sibin
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (WFLY-9892) Upgrade org.apache.santuario.xmlsec to 2.1.1. caused regression in PicketLinkSTS
by Ondrej Lukas (JIRA)
Ondrej Lukas created WFLY-9892:
----------------------------------
Summary: 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: Darran Lofthouse
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)
6 years, 7 months
[JBoss JIRA] (WFLY-9884) WeldResourceInjectionServices runs into NoSuchElementException when deploying multiple EJBs
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-9884?page=com.atlassian.jira.plugin.... ]
jaikiran pai commented on WFLY-9884:
------------------------------------
Martin suggested a change which has been now done and approved in that PR, so you can try it out in the current state and see how it goes. Thanks for the testing.
> WeldResourceInjectionServices runs into NoSuchElementException when deploying multiple EJBs
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-9884
> URL: https://issues.jboss.org/browse/WFLY-9884
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 11.0.0.Final, 12.0.0.Beta1
> Environment: Windows 8.1 Enterprise.
> Reporter: Jacob Ilsø
> Assignee: Jason Greene
> Attachments: log.txt
>
>
> I have an EAR file with several "@Singleton @Startup" beans. Each bean having a number of @Inject and @Resource fields. When I deploy the EAR in WildFly 11 it sometimes fails with a NoSuchElementException (see [^log.txt] for a full stacktrace).
> I cannot reproduce it consistently but it seems to only happen on a "clean" WildFly installation. I haven't seen this on earlier versions of WildFly.
> Let me know if you want me to try to build an EAR for reproducing this.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (JGRP-2253) FD_SOCK is not working in AWS environment
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2253?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2253 at 2/22/18 9:50 AM:
---------------------------------------------------------
*What* exactly isn't working?
You may want to define {{bind_addr}} and {{external_addr}} in FD_SOCK, as described in \[1\]. And you may want to enable logging for FD_SOCK at TRACE level.
\[1\] https://github.com/belaban/jgroups-docker
was (Author: belaban):
*What* exactly isn't working?
You may want to define {{bind_addr}} and {{external_addr}} in FD_SOCK, as described in \[1\].
\[1\] https://github.com/belaban/jgroups-docker
> FD_SOCK is not working in AWS environment
> -----------------------------------------
>
> Key: JGRP-2253
> URL: https://issues.jboss.org/browse/JGRP-2253
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.10
> Environment: AWS - EC2
> Reporter: Sibin Karnavar
> Assignee: Bela Ban
>
> We have our failure detection defined like below.
> <FD_SOCK external_port="7804" />
> <FD timeout="3000" max_tries="3" />
> <VERIFY_SUSPECT timeout="3000" />
> Please note that we have used FD instead of FD_ALL in AWS. We will be changing it to FD_ALL later after detailed testing.
> In my local, this is working perfect. As soon as I kill my node, I was able to see that view change was happening immediately with FD_SOCK.
> We were not mentioning the external_port in the FD_SOCK but later I thought it may be an issue with the port and defined it as 7804 and added the same port to the security group that allows to access this port among all the nodes. So no issue with the port.
> Can you please let us know if we need any additional configurations to make FD_SOCK works well in AWS.
> Thanks,
> Sibin
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (JGRP-2253) FD_SOCK is not working in AWS environment
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2253?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2253:
--------------------------------
*What* exactly isn't working?
You may want to define {{bind_addr}} and {{external_addr}} in FD_SOCK, as described in \[1\].
\[1\] https://github.com/belaban/jgroups-docker
> FD_SOCK is not working in AWS environment
> -----------------------------------------
>
> Key: JGRP-2253
> URL: https://issues.jboss.org/browse/JGRP-2253
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.10
> Environment: AWS - EC2
> Reporter: Sibin Karnavar
> Assignee: Bela Ban
>
> We have our failure detection defined like below.
> <FD_SOCK external_port="7804" />
> <FD timeout="3000" max_tries="3" />
> <VERIFY_SUSPECT timeout="3000" />
> Please note that we have used FD instead of FD_ALL in AWS. We will be changing it to FD_ALL later after detailed testing.
> In my local, this is working perfect. As soon as I kill my node, I was able to see that view change was happening immediately with FD_SOCK.
> We were not mentioning the external_port in the FD_SOCK but later I thought it may be an issue with the port and defined it as 7804 and added the same port to the security group that allows to access this port among all the nodes. So no issue with the port.
> Can you please let us know if we need any additional configurations to make FD_SOCK works well in AWS.
> Thanks,
> Sibin
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months