[JBoss JIRA] (WFLY-13793) Attribute enable-amq1-prefix doesn't work (remote artemis)
by Chao Wang (Jira)
[ https://issues.redhat.com/browse/WFLY-13793?page=com.atlassian.jira.plugi... ]
Chao Wang updated WFLY-13793:
-----------------------------
Component/s: Management
> Attribute enable-amq1-prefix doesn't work (remote artemis)
> ----------------------------------------------------------
>
> Key: WFLY-13793
> URL: https://issues.redhat.com/browse/WFLY-13793
> Project: WildFly
> Issue Type: Bug
> Components: JMS, Management
> Affects Versions: 17.0.1.Final
> Reporter: Nicolas De Amicis
> Assignee: Chao Wang
> Priority: Major
>
> I need to connect Wildfly 17.0.1 to a remote Artemis server. I follow the doc here: [https://docs.wildfly.org/17/Admin_Guide.html#Messaging_Connect_a_pooled-c...] No problem for point 1 to 3. But when I follow the instruction for disabling the compatibility mode (enable-amq1-prefix) I have this error:
> {quote}{{[standalone@localhost:9990 /] /subsystem=messaging-activemq/pooled-connection-factory=remote-artemis:write-attribute(name="enable-amq1-prefix", value="false")}}
> \{{{}}
> \{{ "outcome" => "failed",}}
> \{{ "failure-description" => "WFLYCTL0248: Invalid value false for enable-amq1-prefix; legal values are [XA_GENERIC, GENERIC, XA_T}}
> {{OPIC, TOPIC, QUEUE, XA_QUEUE]",}}
> \{{ "rolled-back" => true}}
> {{}}}
> {quote}
> If I deploy my MDB that connects to queue myqueue, I see in artemis console my MDB is connected to jms.queue.myqueue.
> I also tried to add the attribute manually but it seems it doesn't work:
> {quote}{{<pooled-connection-factory name="remote-artemis" entries="java:/}}{{jms/remoteCF}}{{" connectors="remote-artemis" enable-amq1-prefix="false"/>}}
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[JBoss JIRA] (WFLY-13793) Attribute enable-amq1-prefix doesn't work (remote artemis)
by Chao Wang (Jira)
[ https://issues.redhat.com/browse/WFLY-13793?page=com.atlassian.jira.plugi... ]
Chao Wang reassigned WFLY-13793:
--------------------------------
Assignee: Chao Wang (was: Brian Stansberry)
> Attribute enable-amq1-prefix doesn't work (remote artemis)
> ----------------------------------------------------------
>
> Key: WFLY-13793
> URL: https://issues.redhat.com/browse/WFLY-13793
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 17.0.1.Final
> Reporter: Nicolas De Amicis
> Assignee: Chao Wang
> Priority: Major
>
> I need to connect Wildfly 17.0.1 to a remote Artemis server. I follow the doc here: [https://docs.wildfly.org/17/Admin_Guide.html#Messaging_Connect_a_pooled-c...] No problem for point 1 to 3. But when I follow the instruction for disabling the compatibility mode (enable-amq1-prefix) I have this error:
> {quote}{{[standalone@localhost:9990 /] /subsystem=messaging-activemq/pooled-connection-factory=remote-artemis:write-attribute(name="enable-amq1-prefix", value="false")}}
> \{{{}}
> \{{ "outcome" => "failed",}}
> \{{ "failure-description" => "WFLYCTL0248: Invalid value false for enable-amq1-prefix; legal values are [XA_GENERIC, GENERIC, XA_T}}
> {{OPIC, TOPIC, QUEUE, XA_QUEUE]",}}
> \{{ "rolled-back" => true}}
> {{}}}
> {quote}
> If I deploy my MDB that connects to queue myqueue, I see in artemis console my MDB is connected to jms.queue.myqueue.
> I also tried to add the attribute manually but it seems it doesn't work:
> {quote}{{<pooled-connection-factory name="remote-artemis" entries="java:/}}{{jms/remoteCF}}{{" connectors="remote-artemis" enable-amq1-prefix="false"/>}}
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[JBoss JIRA] (WFWIP-335) Test SslCiphersTest.testAvailableProtocolsWithTLS13CipherSuites fails on RHEL8
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/WFWIP-335?page=com.atlassian.jira.plugin... ]
Farah Juma commented on WFWIP-335:
----------------------------------
[~jstourac] Thanks very much for the detailed information. The comparison failure is due to a bug in OpenSSL 1.1.1c that prevents the enabled TLS 1.3 cipher suites from being set properly when no pre-TLSv1.3 cipher suites have been specified. The bug was fixed in OpenSSL 1.1.1d (see [https://github.com/openssl/openssl/commit/432717135c3f42adc74e0fde49...). I've updated {{SslCiphersTest.testAvailableProtocolsWithTLS13CipherSuites}} so that a pre-TLSv1.3 cipher suite is also configured and the test now passes. With this test fix, I also don't see the different failure that you hit with JDK 11.0.4.
For WildFly, even when only TLS 1.3 cipher suites are configured by the user, we still set the pre-TLSv1.3 cipher suites to the default value. This means that WildFly isn't affected by this bug when running against OpenSSL 1.1.1c (I verified that the {{TlsTestCase}} from WildFly Core does pass with OpenSSL 1.1.1c).
I think we can resolve this WFWIP issue. WDYT?
> Test SslCiphersTest.testAvailableProtocolsWithTLS13CipherSuites fails on RHEL8
> ------------------------------------------------------------------------------
>
> Key: WFWIP-335
> URL: https://issues.redhat.com/browse/WFWIP-335
> Project: WildFly WIP
> Issue Type: Bug
> Components: Security
> Reporter: Jan Stourac
> Assignee: Farah Juma
> Priority: Major
>
> There is failing a new test directly in your PR for 'wildfly-openssl' project - [org.wildfly.openssl.SslCiphersTest.testAvailableProtocolsWithTLS13CipherS...]. I encountered this failure on RHEL8 with OpenSSL 1.1.1c installed:
> {code:title=ComparisonFailure}
> testAvailableProtocolsWithTLS13CipherSuites(org.wildfly.openssl.SslCiphersTest) Time elapsed: 0.112 sec <<< FAILURE!
> org.junit.ComparisonFailure: expected:<TLS_[AES_256_GCM_SHA384]> but was:<TLS_[CHACHA20_POLY1305_SHA256]>
> at org.junit.Assert.assertEquals(Assert.java:123)
> at org.junit.Assert.assertEquals(Assert.java:145)
> at org.wildfly.openssl.SslCiphersTest.testAvailableProtocolsWithTLS13CipherSuites(SslCiphersTest.java:170)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {code}
> After some investigation, it looks like this failure is tied with this version of OpenSSL and does not occur with newer 1.1.1g version. I also saw another failure with combination of OpenJDK 11.0.4 and OpenSSL 1.1.1c:
> {code:title=different failure - API incompatibility?}
> testAvailableProtocolsWithTLS13CipherSuites(org.wildfly.openssl.SslCiphersTest) Time elapsed: 0.031 sec <<< ERROR!
> javax.net.ssl.SSLException: error:0D0680A8:asn1 encoding routines:asn1_check_tlen:wrong tag
> at org.wildfly.openssl.OpenSSLEngine.handshake(OpenSSLEngine.java:1129)
> at org.wildfly.openssl.OpenSSLEngine.beginHandshakeImplicitly(OpenSSLEngine.java:1071)
> at org.wildfly.openssl.OpenSSLEngine.wrap(OpenSSLEngine.java:435)
> at java.base/javax.net.ssl.SSLEngine.wrap(SSLEngine.java:479)
> at org.wildfly.openssl.OpenSSLSocket.runHandshake(OpenSSLSocket.java:305)
> at org.wildfly.openssl.OpenSSLSocket.write(OpenSSLSocket.java:509)
> at org.wildfly.openssl.OpenSSLSocket.write(OpenSSLSocket.java:555)
> at org.wildfly.openssl.OpenSSLOutputStream.write(OpenSSLOutputStream.java:51)
> at org.wildfly.openssl.SslCiphersTest.testAvailableProtocolsWithTLS13CipherSuites(SslCiphersTest.java:159)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {code}
> Here is a summary, see:
> {quote}
> OpenJDK 11.0.4 + OpenSSL 1.1.1c = fail - different failure - some API incompatibilty???
> OpenJDK 11.0.4 + OpenSSL 1.1.1g = pass
> OpenJDK 11.0.6 + OpenSSL 1.1.1c = ComparisonFailure as mentioned above
> OpenJDK 11.0.6 + OpenSSL 1.1.1g = pass
> OpenJDK 11.0.8 + OpenSSL 1.1.1c = ComparisonFailure as mentioned above
> OpenJDK 11.0.8 + OpenSSL 1.1.1g = pass
> {quote}
> Basically means that newer OpenSSL works okay. Although, this may still be problem for customers of RHEL8 until OpenSSL there is not updated.
> Not sure whether this test failure may have any real bad effect on customers, still I wanted to point this out here
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[JBoss JIRA] (WFLY-13806) Add subsystem parsing of persistence.xml documents in the EE 9 namespace
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13806?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFLY-13806:
------------------------------------
Labels: EE9 (was: )
> Add subsystem parsing of persistence.xml documents in the EE 9 namespace
> ------------------------------------------------------------------------
>
> Key: WFLY-13806
> URL: https://issues.redhat.com/browse/WFLY-13806
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Major
> Labels: EE9
>
> The schema used for persistence.xml documents in EE 9 is functionally equivalent to what was used in EE 8; it just has a different namespace, schemaLocation and version, plus various documentation text or type name changes.
> So the existing PersistenceUnitXmlParser could easily parse these if it were made aware of how to recognize the schema version. Doing this is necessary to allow the EE 9 variant of WildFly to parse native EE 9 descriptors. Doing this in the EE 8 variant of the server does not harm.
> Note this is not about producing objects that use EE 9 APIs (i.e. jakarta.* packages instead of javax.*.)
> See also JBMETA-419.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[JBoss JIRA] (WFLY-13806) Add subsystem parsing of persistence.xml documents in the EE 9 namespace
by Brian Stansberry (Jira)
Brian Stansberry created WFLY-13806:
---------------------------------------
Summary: Add subsystem parsing of persistence.xml documents in the EE 9 namespace
Key: WFLY-13806
URL: https://issues.redhat.com/browse/WFLY-13806
Project: WildFly
Issue Type: Feature Request
Components: JPA / Hibernate
Reporter: Brian Stansberry
Assignee: Brian Stansberry
The schema used for persistence.xml documents in EE 9 is functionally equivalent to what was used in EE 8; it just has a different namespace, schemaLocation and version, plus various documentation text or type name changes.
So the existing PersistenceUnitXmlParser could easily parse these if it were made aware of how to recognize the schema version. Doing this is necessary to allow the EE 9 variant of WildFly to parse native EE 9 descriptors. Doing this in the EE 8 variant of the server does not harm.
Note this is not about producing objects that use EE 9 APIs (i.e. jakarta.* packages instead of javax.*.)
See also JBMETA-419.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[JBoss JIRA] (WFLY-13805) Bind address of Wildfly cannot be passed with Eclipse Runtime
by Andre Kreienbring (Jira)
Andre Kreienbring created WFLY-13805:
----------------------------------------
Summary: Bind address of Wildfly cannot be passed with Eclipse Runtime
Key: WFLY-13805
URL: https://issues.redhat.com/browse/WFLY-13805
Project: WildFly
Issue Type: Enhancement
Affects Versions: 18.0.1.Final
Reporter: Andre Kreienbring
Assignee: Brian Stansberry
This solution
[https://access.redhat.com/solutions/18664]
says that one must pass the bind address with the start up command. And YES that works. But because neither adding
{{{{<interface name="public">
<inet-address value="${jboss.bind.address:<IP>}"/>}}}}
{{{{}}{{ </interface>}}}}
to standalone.xml
nor passing -Djboss.bind.address={{{{<IP>}}}} in the Eclipse Launch Configuration (JAVA Options) works, I'm obviously not able to start the server with a specific bind address from Eclipse. It's only running on localhost and 127.0.0.1.
This is annoying for example during the development of a mobile app. The server simply can't be reached when started with Eclipse.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[JBoss JIRA] (WFWIP-338) Bootable JAR - Cloud - Enable json logging
by Jean Francois Denise (Jira)
Jean Francois Denise created WFWIP-338:
------------------------------------------
Summary: Bootable JAR - Cloud - Enable json logging
Key: WFWIP-338
URL: https://issues.redhat.com/browse/WFWIP-338
Project: WildFly WIP
Issue Type: Enhancement
Reporter: Jean Francois Denise
Assignee: Jean Francois Denise
In an openshift context it would be interesting to enable json logging. For Bootable JAR we would evolve the <cloud> element with <enable-json-logging>true|false</enable-json-logging>.
Logging subsystem and logging.properties would have to be updated during packaging.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[JBoss JIRA] (DROOLS-5605) [DMN Designer] Enabled elements in Read Only Mode
by Jozef Marko (Jira)
Jozef Marko created DROOLS-5605:
-----------------------------------
Summary: [DMN Designer] Enabled elements in Read Only Mode
Key: DROOLS-5605
URL: https://issues.redhat.com/browse/DROOLS-5605
Project: Drools
Issue Type: Bug
Components: DMN Editor
Affects Versions: 7.43.0.Final
Reporter: Jozef Marko
Assignee: Guilherme Gomes
Attachments: Screenshot from 2020-08-27 15-45-51.png, Screenshot from 2020-08-27 15-46-21.png
This issue is related to KOGITO-543. There are still two places to disable for Read Only mode.
h1. Navigate To Expression Editor
Currently an exception is thrown if user tries to open an expression editor for DMN node in read only mode.
!Screenshot from 2020-08-27 15-45-51.png|thumbnail!
h1. Import Data Object
There is button to generate DMN data type according to a java class. This button should be disabled in Read Only mode.
!Screenshot from 2020-08-27 15-46-21.png|thumbnail!
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months