[JBoss JIRA] (WFLY-6294) Session draining always takes maximum configured timeout
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-6294?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-6294:
-----------------------------------------------
Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1314792|https://bugzilla.redhat.com/show_bug.cgi?id=1314792] from VERIFIED to CLOSED
> Session draining always takes maximum configured timeout
> --------------------------------------------------------
>
> Key: WFLY-6294
> URL: https://issues.jboss.org/browse/WFLY-6294
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Reporter: Aaron Ogburn
> Assignee: Radoslav Husar
> Priority: Blocker
> Labels: downstream_dependency
> Fix For: 10.1.0.CR1, 10.1.0.Final
>
>
> The mod_cluster session drain wait is not ending as expected. mod_cluster adds a session listener to be notified of session destruction. That is fired appropriately, but when the listener is invoked, the infinispan session manager still reports the session as active. Thus, this drain loop doesn't end after the notify because it still sees the active session:
> {code}
> while ((remainingSessions > 0) && (noTimeout || (timeout > 0))) {
> ModClusterLogger.LOGGER.drainSessions(remainingSessions, context.getHost(), context);
> listener.wait(noTimeout ? 0 : timeout);
> current = System.currentTimeMillis();
> timeout = end - current;
> remainingSessions = context.getActiveSessionCount();
> }
> {code}
> Can the listeners be invoked when the session is fully removed and no longer considered active?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7885) Persistent calendar timer force logging for each invocation if the deployed-class has changed
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-7885?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-7885:
-----------------------------------------------
wfink(a)redhat.com changed the Status of [bug 1413033|https://bugzilla.redhat.com/show_bug.cgi?id=1413033] from NEW to POST
> Persistent calendar timer force logging for each invocation if the deployed-class has changed
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-7885
> URL: https://issues.jboss.org/browse/WFLY-7885
> Project: WildFly
> Issue Type: Enhancement
> Components: EJB
> Reporter: Wolf-Dieter Fink
> Priority: Minor
> Labels: ejb, ejb3.1, timers, timerservice
>
> It will be common to change classes which contains @Schedule timer methods.
> In case such methods are removed or renamed (for persistent calendar timers) the server will log the following warning forever for each invocation.
> WARN [org.jboss.as.ejb3.timer] (EJB default - 1) WFLYEJB0161: Failed to reinstate timer 'ejb31-timer.ejb31-timer.SimpleScheduleSingletonTimerBean' (id=1a419372-d807-43d8-ac77-5be6696b022d) from its persistent state
> As this is intentional there should be a WARN message at (first) deployment time and the timer should be removed from the persistence.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7704) JVM segfault: mod_cluster subsystem cannot handle wildfly-openssl integration
by Radim Hatlapatka (JIRA)
[ https://issues.jboss.org/browse/WFLY-7704?page=com.atlassian.jira.plugin.... ]
Radim Hatlapatka updated WFLY-7704:
-----------------------------------
Git Pull Request: https://github.com/wildfly/wildfly-openssl/pull/10
> JVM segfault: mod_cluster subsystem cannot handle wildfly-openssl integration
> -----------------------------------------------------------------------------
>
> Key: WFLY-7704
> URL: https://issues.jboss.org/browse/WFLY-7704
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.1.0.Final
> Reporter: Michal Karm Babacek
> Assignee: Stuart Douglas
> Priority: Critical
> Fix For: 11.0.0.Alpha1
>
>
> h3. Preface
> mod_cluster subsystem doesn't use Security Realms, unfortunately, so one must replicate SSL configuration both in security realms and in mod_cluster subsystem.
> Apparently, there is a confusion about setting protocol and cipher suite in integration between mod_cluster subsystem and wildfly-openssl:
> {noformat}
> at org.wildfly.openssl.OpenSSLEngine.setEnabledProtocols(OpenSSLEngine.java:754)
> at org.wildfly.openssl.OpenSSLSocket.setEnabledCipherSuites(OpenSSLSocket.java:204)
> at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.initSocket(JSSESocketFactory.java:384)
> at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.createSocket(JSSESocketFactory.java:124)
> {noformat}
> h3. Configuration
> {code}
> <security-realm name="JBossTestServer">
> <server-identities>
> <ssl protocol="openssl.TLS">
> <engine enabled-cipher-suites="TLS_RSA_WITH_AES_128_GCM_SHA256"/>
> <keystore provider="JKS" path="/opt/noe-tests/resources/ssl/proper/server-cert-key.jks" keystore-password="tomcat" alias="javaserver"/>
> </ssl>
> </server-identities>
> <authentication>
> <truststore path="/opt/noe-tests/resources/ssl/proper/ca-cert.jks" keystore-password="tomcat"/>
> </authentication>
> </security-realm>
> <subsystem xmlns="urn:jboss:domain:modcluster:2.0">
> <mod-cluster-config advertise-socket="modcluster" connector="https">
> <dynamic-load-provider>
> <load-metric type="cpu"/>
> </dynamic-load-provider>
> <ssl key-alias="javaclient" password="tomcat" certificate-key-file="/opt/noe-tests/resources/ssl/proper/client-cert-key.jks" cipher-suite="TLS_RSA_WITH_AES_128_GCM_SHA256" protocol="openssl.TLS" ca-certificate-file="/opt/noe-tests/resources/ssl/proper/ca-cert.jks"/>
> </mod-cluster-config>
> </subsystem>
> [org.wildfly.openssl.SSL] OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016
> {code}
> h3. JVM segfault
> Java Stackstrace on MCMP handler registration: [OpenSSLEngine.java:L754|https://github.com/wildfly/wildfly-openssl/blob/1...]
> {noformat}
> 12:01:02,249 ERROR [org.jboss.mod_cluster.undertow] (UndertowEventHandlerAdapter - 1) Unsupported protocol TLS_RSA_WITH_AES_128_GCM_SHA256: java.lang.IllegalArgumentException: Unsupported protocol TLS_RSA_WITH_AES_128_GCM_SHA256
> at org.wildfly.openssl.OpenSSLEngine.setEnabledProtocols(OpenSSLEngine.java:754)
> at org.wildfly.openssl.OpenSSLSocket.setEnabledCipherSuites(OpenSSLSocket.java:204)
> at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.initSocket(JSSESocketFactory.java:384)
> at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.createSocket(JSSESocketFactory.java:124)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler$Proxy.getConnection(DefaultMCMPHandler.java:850)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler$Proxy.getConnectionWriter(DefaultMCMPHandler.java:886)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:514)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:605)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:387)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:365)
> at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:454)
> at org.wildfly.mod_cluster.undertow.UndertowEventHandlerAdapter.run(UndertowEventHandlerAdapter.java:179)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {noformat}causes JVM segfault: {noformat}#
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGSEGV (0xb) at pc=0x00007fd40e7798c5, pid=29489, tid=0x00007fd44f7f7700
> #{noformat}
> Java and Native stacktrace: for a call from Java [byte\[\] getSessionId0(long ssl)|https://github.com/wildfly/wildfly-openssl/blob/1.0.0.Alpha4/java/sr...] to C [getting session from underlying OpenSSL integration fails|https://github.com/wildfly/wildfly-openssl/blob/1.0.0.Alpha4/libwfs...: [0x00007fd44f6f7000,0x00007fd44f7f8000], sp=0x00007fd44f7f6358, free space=1020k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C [libssl.so+0x478c5] SSL_SESSION_get_id+0x5
> C [libwfssl.so+0x4a0b] Java_org_wildfly_openssl_SSLImpl_getSessionId0+0x6b
> j org.wildfly.openssl.SSLImpl.getSessionId0(J)[B+0
> j org.wildfly.openssl.SSLImpl.getSessionId(J)[B+1
> j org.wildfly.openssl.OpenSSLEngine.shutdown()V+42
> j org.wildfly.openssl.OpenSSLEngine.finalize()V+5
> J 1218 C1 java.lang.ref.Finalizer.runFinalizer(Lsun/misc/JavaLangAccess;)V (62 bytes) @ 0x00007fd4593dbf84 [0x00007fd4593dba00+0x584]
> J 1217 C1 java.lang.ref.Finalizer.access$100(Ljava/lang/ref/Finalizer;Lsun/misc/JavaLangAccess;)V (6 bytes) @ 0x00007fd4593db69c [0x00007fd4593db640+0x5c]
> j java.lang.ref.Finalizer$FinalizerThread.run()V+45
> v ~StubRoutines::call_stub
> V [libjvm.so+0x657fbb]
> V [libjvm.so+0x6593b7]
> V [libjvm.so+0x659877]
> V [libjvm.so+0x6a9371]
> V [libjvm.so+0x9de335]
> V [libjvm.so+0x9de590]
> V [libjvm.so+0x8a18b2]
> C [libpthread.so.0+0x7aa1]
> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
> j org.wildfly.openssl.SSLImpl.getSessionId0(J)[B+0
> j org.wildfly.openssl.SSLImpl.getSessionId(J)[B+1
> j org.wildfly.openssl.OpenSSLEngine.shutdown()V+42
> j org.wildfly.openssl.OpenSSLEngine.finalize()V+5
> J 1218 C1 java.lang.ref.Finalizer.runFinalizer(Lsun/misc/JavaLangAccess;)V (62 bytes) @ 0x00007fd4593dbf84 [0x00007fd4593dba00+0x584]
> J 1217 C1 java.lang.ref.Finalizer.access$100(Ljava/lang/ref/Finalizer;Lsun/misc/JavaLangAccess;)V (6 bytes) @ 0x00007fd4593db69c [0x00007fd4593db640+0x5c]
> j java.lang.ref.Finalizer$FinalizerThread.run()V+45
> v ~StubRoutines::call_stub{noformat}
> h3. OpenSSL 1.0.2h
> This is the declaration of the called [SSL_SESSION_get_id|https://github.com/openssl/openssl/blob/OpenSSL_1_0_2h...] and this is the definition in [ssl_sess.c|https://github.com/openssl/openssl/blob/OpenSSL_1_0_2h/ssl/ssl...]
> h3. Conclusion
> IMHO it wouldn't do any harm to check whether {{session}} ain't NULL before passing it on down to OpenSSL, but it is only the aftermath, not the original cause I suppose. It might be worth checking whether the bug is actually not simply in the mod_cluster java part, in calling {{org.wildfly.openssl.OpenSSLEngine}} with confused protocols/cipher suites.
> Cheers
> -K-
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7704) JVM segfault: mod_cluster subsystem cannot handle wildfly-openssl integration
by Radim Hatlapatka (JIRA)
[ https://issues.jboss.org/browse/WFLY-7704?page=com.atlassian.jira.plugin.... ]
Radim Hatlapatka reopened WFLY-7704:
------------------------------------
The issue is still not fixed.
The issue is caused by improper method call in https://github.com/wildfly/wildfly-openssl/blob/master/java/src/main/java...
> JVM segfault: mod_cluster subsystem cannot handle wildfly-openssl integration
> -----------------------------------------------------------------------------
>
> Key: WFLY-7704
> URL: https://issues.jboss.org/browse/WFLY-7704
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.1.0.Final
> Reporter: Michal Karm Babacek
> Assignee: Stuart Douglas
> Priority: Critical
> Fix For: 11.0.0.Alpha1
>
>
> h3. Preface
> mod_cluster subsystem doesn't use Security Realms, unfortunately, so one must replicate SSL configuration both in security realms and in mod_cluster subsystem.
> Apparently, there is a confusion about setting protocol and cipher suite in integration between mod_cluster subsystem and wildfly-openssl:
> {noformat}
> at org.wildfly.openssl.OpenSSLEngine.setEnabledProtocols(OpenSSLEngine.java:754)
> at org.wildfly.openssl.OpenSSLSocket.setEnabledCipherSuites(OpenSSLSocket.java:204)
> at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.initSocket(JSSESocketFactory.java:384)
> at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.createSocket(JSSESocketFactory.java:124)
> {noformat}
> h3. Configuration
> {code}
> <security-realm name="JBossTestServer">
> <server-identities>
> <ssl protocol="openssl.TLS">
> <engine enabled-cipher-suites="TLS_RSA_WITH_AES_128_GCM_SHA256"/>
> <keystore provider="JKS" path="/opt/noe-tests/resources/ssl/proper/server-cert-key.jks" keystore-password="tomcat" alias="javaserver"/>
> </ssl>
> </server-identities>
> <authentication>
> <truststore path="/opt/noe-tests/resources/ssl/proper/ca-cert.jks" keystore-password="tomcat"/>
> </authentication>
> </security-realm>
> <subsystem xmlns="urn:jboss:domain:modcluster:2.0">
> <mod-cluster-config advertise-socket="modcluster" connector="https">
> <dynamic-load-provider>
> <load-metric type="cpu"/>
> </dynamic-load-provider>
> <ssl key-alias="javaclient" password="tomcat" certificate-key-file="/opt/noe-tests/resources/ssl/proper/client-cert-key.jks" cipher-suite="TLS_RSA_WITH_AES_128_GCM_SHA256" protocol="openssl.TLS" ca-certificate-file="/opt/noe-tests/resources/ssl/proper/ca-cert.jks"/>
> </mod-cluster-config>
> </subsystem>
> [org.wildfly.openssl.SSL] OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016
> {code}
> h3. JVM segfault
> Java Stackstrace on MCMP handler registration: [OpenSSLEngine.java:L754|https://github.com/wildfly/wildfly-openssl/blob/1...]
> {noformat}
> 12:01:02,249 ERROR [org.jboss.mod_cluster.undertow] (UndertowEventHandlerAdapter - 1) Unsupported protocol TLS_RSA_WITH_AES_128_GCM_SHA256: java.lang.IllegalArgumentException: Unsupported protocol TLS_RSA_WITH_AES_128_GCM_SHA256
> at org.wildfly.openssl.OpenSSLEngine.setEnabledProtocols(OpenSSLEngine.java:754)
> at org.wildfly.openssl.OpenSSLSocket.setEnabledCipherSuites(OpenSSLSocket.java:204)
> at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.initSocket(JSSESocketFactory.java:384)
> at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.createSocket(JSSESocketFactory.java:124)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler$Proxy.getConnection(DefaultMCMPHandler.java:850)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler$Proxy.getConnectionWriter(DefaultMCMPHandler.java:886)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:514)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:605)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:387)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:365)
> at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:454)
> at org.wildfly.mod_cluster.undertow.UndertowEventHandlerAdapter.run(UndertowEventHandlerAdapter.java:179)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {noformat}causes JVM segfault: {noformat}#
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGSEGV (0xb) at pc=0x00007fd40e7798c5, pid=29489, tid=0x00007fd44f7f7700
> #{noformat}
> Java and Native stacktrace: for a call from Java [byte\[\] getSessionId0(long ssl)|https://github.com/wildfly/wildfly-openssl/blob/1.0.0.Alpha4/java/sr...] to C [getting session from underlying OpenSSL integration fails|https://github.com/wildfly/wildfly-openssl/blob/1.0.0.Alpha4/libwfs...: [0x00007fd44f6f7000,0x00007fd44f7f8000], sp=0x00007fd44f7f6358, free space=1020k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C [libssl.so+0x478c5] SSL_SESSION_get_id+0x5
> C [libwfssl.so+0x4a0b] Java_org_wildfly_openssl_SSLImpl_getSessionId0+0x6b
> j org.wildfly.openssl.SSLImpl.getSessionId0(J)[B+0
> j org.wildfly.openssl.SSLImpl.getSessionId(J)[B+1
> j org.wildfly.openssl.OpenSSLEngine.shutdown()V+42
> j org.wildfly.openssl.OpenSSLEngine.finalize()V+5
> J 1218 C1 java.lang.ref.Finalizer.runFinalizer(Lsun/misc/JavaLangAccess;)V (62 bytes) @ 0x00007fd4593dbf84 [0x00007fd4593dba00+0x584]
> J 1217 C1 java.lang.ref.Finalizer.access$100(Ljava/lang/ref/Finalizer;Lsun/misc/JavaLangAccess;)V (6 bytes) @ 0x00007fd4593db69c [0x00007fd4593db640+0x5c]
> j java.lang.ref.Finalizer$FinalizerThread.run()V+45
> v ~StubRoutines::call_stub
> V [libjvm.so+0x657fbb]
> V [libjvm.so+0x6593b7]
> V [libjvm.so+0x659877]
> V [libjvm.so+0x6a9371]
> V [libjvm.so+0x9de335]
> V [libjvm.so+0x9de590]
> V [libjvm.so+0x8a18b2]
> C [libpthread.so.0+0x7aa1]
> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
> j org.wildfly.openssl.SSLImpl.getSessionId0(J)[B+0
> j org.wildfly.openssl.SSLImpl.getSessionId(J)[B+1
> j org.wildfly.openssl.OpenSSLEngine.shutdown()V+42
> j org.wildfly.openssl.OpenSSLEngine.finalize()V+5
> J 1218 C1 java.lang.ref.Finalizer.runFinalizer(Lsun/misc/JavaLangAccess;)V (62 bytes) @ 0x00007fd4593dbf84 [0x00007fd4593dba00+0x584]
> J 1217 C1 java.lang.ref.Finalizer.access$100(Ljava/lang/ref/Finalizer;Lsun/misc/JavaLangAccess;)V (6 bytes) @ 0x00007fd4593db69c [0x00007fd4593db640+0x5c]
> j java.lang.ref.Finalizer$FinalizerThread.run()V+45
> v ~StubRoutines::call_stub{noformat}
> h3. OpenSSL 1.0.2h
> This is the declaration of the called [SSL_SESSION_get_id|https://github.com/openssl/openssl/blob/OpenSSL_1_0_2h...] and this is the definition in [ssl_sess.c|https://github.com/openssl/openssl/blob/OpenSSL_1_0_2h/ssl/ssl...]
> h3. Conclusion
> IMHO it wouldn't do any harm to check whether {{session}} ain't NULL before passing it on down to OpenSSL, but it is only the aftermath, not the original cause I suppose. It might be worth checking whether the bug is actually not simply in the mod_cluster java part, in calling {{org.wildfly.openssl.OpenSSLEngine}} with confused protocols/cipher suites.
> Cheers
> -K-
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7905) Wildfly is missing jboss logging internationalization message in XTS
by Romain Pelisse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7905?page=com.atlassian.jira.plugin.... ]
Romain Pelisse commented on WFLY-7905:
--------------------------------------
WFLY-7905 is the upstream issue of JBEAP-8290.
> Wildfly is missing jboss logging internationalization message in XTS
> --------------------------------------------------------------------
>
> Key: WFLY-7905
> URL: https://issues.jboss.org/browse/WFLY-7905
> Project: WildFly
> Issue Type: Enhancement
> Reporter: Romain Pelisse
> Assignee: Romain Pelisse
> Priority: Minor
>
> There is one log warning message which is not properly internationalized in Wildfly 'xts' submodule:
> ./src/xts/src/main/java/org/jboss/as/xts/GracefulShutdownRejectionRule.java:45: XTSLogger.logger.warnf("rejecting call because it is not part of any XTS transaction")
> All logs of level WARN and higher should be internationalized.
> The message needs to be added to XTS in JBossTS and then xts module modified to use it.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7905) Wildfly is missing jboss logging internationalization message in XTS
by Romain Pelisse (JIRA)
Romain Pelisse created WFLY-7905:
------------------------------------
Summary: Wildfly is missing jboss logging internationalization message in XTS
Key: WFLY-7905
URL: https://issues.jboss.org/browse/WFLY-7905
Project: WildFly
Issue Type: Enhancement
Reporter: Romain Pelisse
Assignee: Romain Pelisse
Priority: Minor
There is one log warning message which is not properly internationalized in Wildfly 'xts' submodule:
./src/xts/src/main/java/org/jboss/as/xts/GracefulShutdownRejectionRule.java:45: XTSLogger.logger.warnf("rejecting call because it is not part of any XTS transaction")
All logs of level WARN and higher should be internationalized.
The message needs to be added to XTS in JBossTS and then xts module modified to use it.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7158) Working with multiple keys in key store
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-7158?page=com.atlassian.jira.plugin.... ]
Martin Choma commented on WFLY-7158:
------------------------------------
[~honza889], how is that meant to work now? I don't get that. I am missing proposed alias attribute on key-manager resource.
> Working with multiple keys in key store
> ---------------------------------------
>
> Key: WFLY-7158
> URL: https://issues.jboss.org/browse/WFLY-7158
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Critical
> Fix For: 11.0.0.Alpha1
>
>
> In case when 2 keys are present in keystore, then alias-filter (filtering into single key) on key-store resource has to be specified, otherwise key-manager can't be created. If user want to use keystore with multiple keys, user has to configure multiple key-store elements with specified alias-filter (filtering into single key).
> That is pretty inconvinient. Probably introducing *alias attribute on key-manager* would be more intuitive solution to this situation.
> {code}
> /subsystem=elytron/key-managers=server:add(key-store=server,algorithm="SunX509",password=key-password)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months