[JBoss JIRA] (WFLY-13809) Get application name from BatchEnvironment instead of jndi lookup
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-13809?page=com.atlassian.jira.plugi... ]
Cheng Fang updated WFLY-13809:
------------------------------
Description:
AbstractJobOperator currently gets application name via jndi lookup. It is an expensive operation for this task. Also in non-EE environment, lookup of application name will always return null. So it is better to retrieve application name from {{BatchEnvironment}}, and different impl of {{BatchEnvironment}} can provide application name differently.
Need to adjust {{BatchEnvironmentService}} to provide application name.
was:AbstractJobOperator currently gets application name via jndi lookup. It is an expensive operation for this task. Also in non-EE environment, lookup of application name will always return null. So it is better to retrieve application name from {{BatchEnvironment}}, and different impl of {{BatchEnvironment}} can provide application name differently.
> Get application name from BatchEnvironment instead of jndi lookup
> -----------------------------------------------------------------
>
> Key: WFLY-13809
> URL: https://issues.redhat.com/browse/WFLY-13809
> Project: WildFly
> Issue Type: Enhancement
> Components: Batch
> Affects Versions: 20.0.1.Final
> Reporter: Cheng Fang
> Assignee: Cheng Fang
> Priority: Major
>
> AbstractJobOperator currently gets application name via jndi lookup. It is an expensive operation for this task. Also in non-EE environment, lookup of application name will always return null. So it is better to retrieve application name from {{BatchEnvironment}}, and different impl of {{BatchEnvironment}} can provide application name differently.
> Need to adjust {{BatchEnvironmentService}} to provide application name.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFLY-13809) Get application name from BatchEnvironment instead of jndi lookup
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-13809?page=com.atlassian.jira.plugi... ]
Cheng Fang moved JBERET-496 to WFLY-13809:
------------------------------------------
Project: WildFly (was: JBeret)
Key: WFLY-13809 (was: JBERET-496)
Component/s: Batch
(was: jberet-core)
Affects Version/s: 20.0.1.Final
(was: 1.4.0.Alpha1)
Fix Version/s: (was: 1.4.0.Final)
> Get application name from BatchEnvironment instead of jndi lookup
> -----------------------------------------------------------------
>
> Key: WFLY-13809
> URL: https://issues.redhat.com/browse/WFLY-13809
> Project: WildFly
> Issue Type: Enhancement
> Components: Batch
> Affects Versions: 20.0.1.Final
> Reporter: Cheng Fang
> Assignee: Cheng Fang
> Priority: Major
>
> AbstractJobOperator currently gets application name via jndi lookup. It is an expensive operation for this task. Also in non-EE environment, lookup of application name will always return null. So it is better to retrieve application name from {{BatchEnvironment}}, and different impl of {{BatchEnvironment}} can provide application name differently.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFWIP-339) OpenSSL security provider seems to be used when not defined now
by Jan Stourac (Jira)
[ https://issues.redhat.com/browse/WFWIP-339?page=com.atlassian.jira.plugin... ]
Jan Stourac updated WFWIP-339:
------------------------------
Description:
It looks like the OpenSSL security provider is now used as a default when I configure reverse-proxy feature on the server. Not sure what is the root-cause for this change of behavior.
Attaching relevant configuration. There can be also seen that during the startup, relevant log message about OpenSSL provider is logged during the server boot, e.g.:
{quote}
16:44:42,676 INFO [org.wildfly.openssl.SSL] (MSC service thread 1-3) WFOPENSSL0002 OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016
{quote}
There are two questions from this:
# Is this change of OpenSSL provider being initialized during the boot in this configuration case expected?
# I believe that even in case that answer to question above is `yes`, then we should not change default security provider, which in this case it should be JSSE.
Hope I don't have any misconfiguration in the configuration itself.
was:
It looks like the OpenSSL security provider is now used as a default when I configure reverse-proxy feature on the server. Not sure what is the root-cause for this change of behavior.
Attaching relevant configuration. There can be also seen that during the startup, relevant log message about OpenSSL provider is logged during the server boot, e.g.:
{quote}
16:44:42,676 INFO [org.wildfly.openssl.SSL] (MSC service thread 1-3) WFOPENSSL0002 OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016
{quote}
> OpenSSL security provider seems to be used when not defined now
> ---------------------------------------------------------------
>
> Key: WFWIP-339
> URL: https://issues.redhat.com/browse/WFWIP-339
> Project: WildFly WIP
> Issue Type: Bug
> Components: Security
> Reporter: Jan Stourac
> Assignee: Farah Juma
> Priority: Major
> Attachments: client.jks, server.jks, standalone-full.xml
>
>
> It looks like the OpenSSL security provider is now used as a default when I configure reverse-proxy feature on the server. Not sure what is the root-cause for this change of behavior.
> Attaching relevant configuration. There can be also seen that during the startup, relevant log message about OpenSSL provider is logged during the server boot, e.g.:
> {quote}
> 16:44:42,676 INFO [org.wildfly.openssl.SSL] (MSC service thread 1-3) WFOPENSSL0002 OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016
> {quote}
> There are two questions from this:
> # Is this change of OpenSSL provider being initialized during the boot in this configuration case expected?
> # I believe that even in case that answer to question above is `yes`, then we should not change default security provider, which in this case it should be JSSE.
> Hope I don't have any misconfiguration in the configuration itself.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFWIP-339) OpenSSL security provider seems to be used when not defined now
by Jan Stourac (Jira)
[ https://issues.redhat.com/browse/WFWIP-339?page=com.atlassian.jira.plugin... ]
Jan Stourac updated WFWIP-339:
------------------------------
Steps to Reproduce:
# unzip server
# copy `server.jks`, `client.jks` and `standalone-full.xml` files into the `EAP_HOME/standalone/configuration` directory
# start server
{code:java}
./bin/standalone.sh -c standalone-full.xml
{code}
# see relevant `WFOPENSSL0002` message is present during the server boot
was:
# unzip server
# copy `server.jks`, `client.jks` and `standalone-full.xml` files into the `EAP_HOME/standalone/configuration` directory
# start server
{code}
./bin/standalone.sh -c standalone-full.xml
{code}
> OpenSSL security provider seems to be used when not defined now
> ---------------------------------------------------------------
>
> Key: WFWIP-339
> URL: https://issues.redhat.com/browse/WFWIP-339
> Project: WildFly WIP
> Issue Type: Bug
> Components: Security
> Reporter: Jan Stourac
> Assignee: Farah Juma
> Priority: Major
> Attachments: client.jks, server.jks, standalone-full.xml
>
>
> It looks like the OpenSSL security provider is now used as a default when I configure reverse-proxy feature on the server. Not sure what is the root-cause for this change of behavior.
> Attaching relevant configuration. There can be also seen that during the startup, relevant log message about OpenSSL provider is logged during the server boot, e.g.:
> {quote}
> 16:44:42,676 INFO [org.wildfly.openssl.SSL] (MSC service thread 1-3) WFOPENSSL0002 OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFWIP-339) OpenSSL security provider seems to be used when not defined now
by Jan Stourac (Jira)
[ https://issues.redhat.com/browse/WFWIP-339?page=com.atlassian.jira.plugin... ]
Jan Stourac updated WFWIP-339:
------------------------------
Attachment: client.jks
server.jks
standalone-full.xml
> OpenSSL security provider seems to be used when not defined now
> ---------------------------------------------------------------
>
> Key: WFWIP-339
> URL: https://issues.redhat.com/browse/WFWIP-339
> Project: WildFly WIP
> Issue Type: Bug
> Components: Security
> Reporter: Jan Stourac
> Assignee: Farah Juma
> Priority: Major
> Attachments: client.jks, server.jks, standalone-full.xml
>
>
> It looks like the OpenSSL security provider is now used as a default when I configure reverse-proxy feature on the server. Not sure what is the root-cause for this change of behavior.
> Attaching relevant configuration. There can be also seen that during the startup, relevant log message about OpenSSL provider is logged during the server boot, e.g.:
> {quote}
> 16:44:42,676 INFO [org.wildfly.openssl.SSL] (MSC service thread 1-3) WFOPENSSL0002 OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFWIP-339) OpenSSL security provider seems to be used when not defined now
by Jan Stourac (Jira)
Jan Stourac created WFWIP-339:
---------------------------------
Summary: OpenSSL security provider seems to be used when not defined now
Key: WFWIP-339
URL: https://issues.redhat.com/browse/WFWIP-339
Project: WildFly WIP
Issue Type: Bug
Components: Security
Reporter: Jan Stourac
Assignee: Farah Juma
It looks like the OpenSSL security provider is now used as a default when I configure reverse-proxy feature on the server. Not sure what is the root-cause for this change of behavior.
Attaching relevant configuration. There can be also seen that during the startup, relevant log message about OpenSSL provider is logged during the server boot, e.g.:
{quote}
16:44:42,676 INFO [org.wildfly.openssl.SSL] (MSC service thread 1-3) WFOPENSSL0002 OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016
{quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFLY-13793) Attribute enable-amq1-prefix doesn't work (remote artemis)
by Nicolas De Amicis (Jira)
[ https://issues.redhat.com/browse/WFLY-13793?page=com.atlassian.jira.plugi... ]
Nicolas De Amicis commented on WFLY-13793:
------------------------------------------
I tried the same case under wildfly 20 and it seems that the MDB listen on the right queue (without jms.queue prefix). The problem was corrected between wildfly 17 and wildfly 20.
> 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, 10 months
[JBoss JIRA] (WFWIP-335) Test SslCiphersTest.testAvailableProtocolsWithTLS13CipherSuites fails on RHEL8
by Jan Stourac (Jira)
[ https://issues.redhat.com/browse/WFWIP-335?page=com.atlassian.jira.plugin... ]
Jan Stourac resolved WFWIP-335.
-------------------------------
Resolution: Done
> 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, 10 months