[JBoss JIRA] (JGRP-1914) S3_PING doesn't work with S3 buckets created in Frankfurt region
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1914?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1914:
--------------------------------
So I deprecated {{S3_PING}}, but it will only be removed in 5.0.
[~glebleonov] Can you take a look at NATIVE_S3_PING [1] ? I'd like to know if it solves your original problem of working with S3 buckets in the Franfurt region.
I'm closing this issue for now. If NATIVE_S3_PING does *not* solve your problem, please create a *new* issue on NATIVE_S3_PING.
Cheers,
[1] https://github.com/jgroups-extras/native-s3-ping
> S3_PING doesn't work with S3 buckets created in Frankfurt region
> -----------------------------------------------------------------
>
> Key: JGRP-1914
> URL: https://issues.jboss.org/browse/JGRP-1914
> Project: JGroups
> Issue Type: Bug
> Reporter: Gleb Leonov
> Assignee: Bela Ban
> Fix For: 4.1
>
> Attachments: AWS4.png
>
>
> I tried to use S3_PING with access and secret key pair. However, I got 400 (Bad Request) error. After some investigation, I found that modern S3 buckets created in Frankfurt needs amazon v4 authentication, which needs hmac-sha256. But now S3_PING supports only hmac-sha1, so I see no way to use S3_PING with buckets in Frankfurt region.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (JGRP-1914) S3_PING doesn't work with S3 buckets created in Frankfurt region
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1914?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1914 at 5/16/17 7:00 AM:
---------------------------------------------------------
I recently ported Zalando's NATIVE_S3_PING to 4.0 and refactored it quite a bit. The port is at [1]. This is what I'd recommend if you're running on EC2.
As mentioned elsewhere, I want to deprecate S3_PING as soon as I have a native discovery protocol for Google Cloud Platform [2].
[1] https://github.com/jgroups-extras
[2] https://issues.jboss.org/browse/JGRP-2170
was (Author: belaban):
I recently ported Zalando's NATVE_S3_PING to 4.0 and refactored it quite a bit. The port is at [1]. This is what I'd recommend if you're running on EC2.
As mentioned elsewhere, I want to deprecate S3_PING as soon as I have a native discovery protocol for Google Cloud Platform [2].
[1] https://github.com/jgroups-extras
[2] https://issues.jboss.org/browse/JGRP-2170
> S3_PING doesn't work with S3 buckets created in Frankfurt region
> -----------------------------------------------------------------
>
> Key: JGRP-1914
> URL: https://issues.jboss.org/browse/JGRP-1914
> Project: JGroups
> Issue Type: Bug
> Reporter: Gleb Leonov
> Assignee: Bela Ban
> Fix For: 4.1
>
> Attachments: AWS4.png
>
>
> I tried to use S3_PING with access and secret key pair. However, I got 400 (Bad Request) error. After some investigation, I found that modern S3 buckets created in Frankfurt needs amazon v4 authentication, which needs hmac-sha256. But now S3_PING supports only hmac-sha1, so I see no way to use S3_PING with buckets in Frankfurt region.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (JGRP-2162) Failed to send broadcast when opening the connection
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2162?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2162:
--------------------------------
I did change the description of {{initial_hosts}}. This will show up in the schema and gthe documentation now.
> Failed to send broadcast when opening the connection
> ----------------------------------------------------
>
> Key: JGRP-2162
> URL: https://issues.jboss.org/browse/JGRP-2162
> Project: JGroups
> Issue Type: Bug
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 4.0.4
>
> Attachments: TcpNio2McastTest.java, infinispan_2.log.gz
>
>
> IRC discussion:
> {quote}
> bela_: Hi Bela, I have a weird failure in one test that seem to be rooted in JGroups. TCP_NIO2 is in charge, and there's a broadcast message to all nodes, but it seems it's not received on the other side.
> <bela_> rvansa: reproducible?
> <rvansa> bela_: it happens when the connection to a node is just being opened: I have added some trace logs and just a moment before writing to the NioConnection.send_buf it was in state "connection pending"
> <rvansa> bela_: sort of, after tens of runs of that test (on my machine) - and I've seen it first time in CI, so it could be
> <bela_> rvansa: NioConnection buffers writes up to a certain extent, then discards anything over the buffer limit
> <bela_> rvansa: max_send_buffers (default: 10). But retransmission should fix this, unless you don’t wait long enough
> <rvansa> bela_: I don't think it should go over the limit
> <rvansa> bela_: the test is not doing anything else, just sending CommitCommand (that should be couple hundred bytes at most) and then waiting
> <rvansa> bela_: according to the traces I've added, Buffers.write returned false when writing the local address, and then true when writing the actual message
> {quote}
> I have been trying to write a reproducer, and found that it's related to the fact that the failing test uses custom (fake) discovery protocol, that doesn't open the connection during startup. In my ~reproducer I had to modify tcp-nio.xml to use TCPPING with only the first node in hosts list (localhost[7800]):
> {code:xml}
> <TCPPING async_discovery="true" initial_hosts="${jgroups.tcpping.initial_hosts:localhost[7800]}" port_range="0"/>
> {code}
> This causes that the physical connection is not opened by discovery. However, the reproducer suffers from (always reproducible) flaw - it does not send the message to third node at all (and the test fails, therefore).
> Note that increasing the timeout in request options does not help.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ELY-1159) Windows delimiter '\' cannot be used in any path in Elytron client configuration file
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/ELY-1159?page=com.atlassian.jira.plugin.s... ]
Ondrej Lukas updated ELY-1159:
------------------------------
Affects Version/s: 1.1.0.Beta42
> Windows delimiter '\' cannot be used in any path in Elytron client configuration file
> -------------------------------------------------------------------------------------
>
> Key: ELY-1159
> URL: https://issues.jboss.org/browse/ELY-1159
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta42
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Critical
>
> When Elytron client configuration file includes some path (e.g. for keystore) with Windows delimiter '\' then this path cannot be parsed. When Windows delimiter '\' is replaced by linux delimiter '/' then resource on given path can be loaded correctly. That means it is user experience issue since common Windows path cannot be used in Elytron client configuration file, but wokraround (using '/') is simple.
> None of following types of path work:
> {code}
> C:\some\path\to\client.truststore
> C:\\some\\path\\to\\client.truststore
> {code}
> Following type of path works on Windows correctly:
> {code}
> C:/some/path/to/client.truststore
> {code}
> Following exception is thrown when '\' is used in Elytron client configuration file (the same exception is thrown when '\' is escaped in path):
> {code}
> org.wildfly.client.config.ConfigXMLParseException: CONF0020: Failed to parse expression value of attribute "name"
> at vfs:/W:/workspace/eap-7x-security-elytron-testsuite-windows/f43f9016/tests-security/elytron/content/wildfly-config-xml-dep.war/META-INF/wildfly-config.xml:18:1
> at org.wildfly.client.config.ConfigurationXMLStreamReader.getExpressionAttributeValue(ConfigurationXMLStreamReader.java:685)
> at org.wildfly.client.config.ConfigurationXMLStreamReader.getAttributeValueResolved(ConfigurationXMLStreamReader.java:330)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseNameType(ElytronXmlParser.java:1697)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseNameType(ElytronXmlParser.java:1680)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseKeyStoreType(ElytronXmlParser.java:1225)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseKeyStoresType(ElytronXmlParser.java:1113)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:279)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:180)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:141)
> at com.redhat.eap.qe.elytron.authnctx.WildflyConfigXmlServlet.parseAndCreateAuthenticationClientConfiguration(WildflyConfigXmlServlet.java:116)
> ... 41 more
> Caused by: java.lang.IllegalArgumentException: COM00009: Invalid expression syntax at position 2
> W:\workspace\eap-7x-security-elytron-testsuite-windows\f43f9016\tests-security\elytron\target\client.keystore
> ^
> at org.wildfly.common.expression.Expression.invalidExpressionSyntax(Expression.java:654)
> at org.wildfly.common.expression.Expression.parseString(Expression.java:610)
> at org.wildfly.common.expression.Expression.compile(Expression.java:203)
> at org.wildfly.common.expression.Expression.compile(Expression.java:183)
> at org.wildfly.client.config.ConfigurationXMLStreamReader.getExpressionAttributeValue(ConfigurationXMLStreamReader.java:683)
> ... 50 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ELY-1159) Windows delimiter '\' cannot be used in any path in Elytron client configuration file
by Ondrej Lukas (JIRA)
Ondrej Lukas created ELY-1159:
---------------------------------
Summary: Windows delimiter '\' cannot be used in any path in Elytron client configuration file
Key: ELY-1159
URL: https://issues.jboss.org/browse/ELY-1159
Project: WildFly Elytron
Issue Type: Bug
Reporter: Ondrej Lukas
Assignee: Darran Lofthouse
Priority: Critical
When Elytron client configuration file includes some path (e.g. for keystore) with Windows delimiter '\' then this path cannot be parsed. When Windows delimiter '\' is replaced by linux delimiter '/' then resource on given path can be loaded correctly. That means it is user experience issue since common Windows path cannot be used in Elytron client configuration file, but wokraround (using '/') is simple.
None of following types of path work:
{code}
C:\some\path\to\client.truststore
C:\\some\\path\\to\\client.truststore
{code}
Following type of path works on Windows correctly:
{code}
C:/some/path/to/client.truststore
{code}
Following exception is thrown when '\' is used in Elytron client configuration file (the same exception is thrown when '\' is escaped in path):
{code}
org.wildfly.client.config.ConfigXMLParseException: CONF0020: Failed to parse expression value of attribute "name"
at vfs:/W:/workspace/eap-7x-security-elytron-testsuite-windows/f43f9016/tests-security/elytron/content/wildfly-config-xml-dep.war/META-INF/wildfly-config.xml:18:1
at org.wildfly.client.config.ConfigurationXMLStreamReader.getExpressionAttributeValue(ConfigurationXMLStreamReader.java:685)
at org.wildfly.client.config.ConfigurationXMLStreamReader.getAttributeValueResolved(ConfigurationXMLStreamReader.java:330)
at org.wildfly.security.auth.client.ElytronXmlParser.parseNameType(ElytronXmlParser.java:1697)
at org.wildfly.security.auth.client.ElytronXmlParser.parseNameType(ElytronXmlParser.java:1680)
at org.wildfly.security.auth.client.ElytronXmlParser.parseKeyStoreType(ElytronXmlParser.java:1225)
at org.wildfly.security.auth.client.ElytronXmlParser.parseKeyStoresType(ElytronXmlParser.java:1113)
at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:279)
at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:180)
at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:141)
at com.redhat.eap.qe.elytron.authnctx.WildflyConfigXmlServlet.parseAndCreateAuthenticationClientConfiguration(WildflyConfigXmlServlet.java:116)
... 41 more
Caused by: java.lang.IllegalArgumentException: COM00009: Invalid expression syntax at position 2
W:\workspace\eap-7x-security-elytron-testsuite-windows\f43f9016\tests-security\elytron\target\client.keystore
^
at org.wildfly.common.expression.Expression.invalidExpressionSyntax(Expression.java:654)
at org.wildfly.common.expression.Expression.parseString(Expression.java:610)
at org.wildfly.common.expression.Expression.compile(Expression.java:203)
at org.wildfly.common.expression.Expression.compile(Expression.java:183)
at org.wildfly.client.config.ConfigurationXMLStreamReader.getExpressionAttributeValue(ConfigurationXMLStreamReader.java:683)
... 50 more
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-2813) ls output is unfriendly if any element in return contents is longer than terminal width
by Chao Wang (JIRA)
Chao Wang created WFCORE-2813:
---------------------------------
Summary: ls output is unfriendly if any element in return contents is longer than terminal width
Key: WFCORE-2813
URL: https://issues.jboss.org/browse/WFCORE-2813
Project: WildFly Core
Issue Type: Bug
Components: CLI, Security
Affects Versions: 3.0.0.Beta21
Reporter: Chao Wang
Assignee: Chao Wang
When 'ls' operation is performed over 'provider-loader' element, the output is very ugly - I get many empty lines with one very long attribute value and few more attributes with simple values.
Expected: no empty lines between printed attributes so the output does not take like 4 screen size.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (DROOLS-1564) Change oopath syntax
by Mario Fusco (JIRA)
Mario Fusco created DROOLS-1564:
-----------------------------------
Summary: Change oopath syntax
Key: DROOLS-1564
URL: https://issues.jboss.org/browse/DROOLS-1564
Project: Drools
Issue Type: Enhancement
Components: core engine
Reporter: Mario Fusco
Assignee: Mario Fusco
It is required to change the oopath syntax to make it closer to xpath one. This means that constraints will have to be put between square brackets instead of curly ones and inline cast should be expressed out of constraints. In other words the following oopath:
{code}
/list{#SubClass, prop == 0}
{code}
should become:
{code}
/list#SubClass[prop == 0]
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-2812) ls output is unfriendly if any element in return contents is longer than terminal width
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2812?page=com.atlassian.jira.plugi... ]
Chao Wang moved JBEAP-10927 to WFCORE-2812:
-------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-2812 (was: JBEAP-10927)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: CLI
Security
(was: CLI)
(was: Security)
Affects Version/s: 3.0.0.Beta21
(was: 7.1.0.DR18)
> ls output is unfriendly if any element in return contents is longer than terminal width
> ---------------------------------------------------------------------------------------
>
> Key: WFCORE-2812
> URL: https://issues.jboss.org/browse/WFCORE-2812
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Security
> Affects Versions: 3.0.0.Beta21
> Reporter: Chao Wang
> Assignee: Chao Wang
>
> When 'ls' operation is performed over 'provider-loader' element, the output is very ugly - I get many empty lines with one very long attribute value and few more attributes with simple values.
> Expected: no empty lines between printed attributes so the output does not take like 4 screen size.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month