[JBoss JIRA] (WFCORE-2664) Eliminate MSC optional dependency usage in RemotingServices
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2664?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2664:
-------------------------------------
Fix Version/s: 3.0.0.Beta18
(was: 3.0.0.Beta17)
> Eliminate MSC optional dependency usage in RemotingServices
> -----------------------------------------------------------
>
> Key: WFCORE-2664
> URL: https://issues.jboss.org/browse/WFCORE-2664
> Project: WildFly Core
> Issue Type: Enhancement
> Affects Versions: 3.0.0.Beta14
> Reporter: Richard Opalka
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Beta18
>
>
> RemotingServices.installConnectorServices() uses MSC optional dependency.
> Any change this MSC optional dependency usage might be eliminated there?
> Maybe OperationContext.hasOptionalCapability() could be used
> in ManagementRemotingServices.installDomainConnectorServices() method?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2720) Adding keystore with generate-self-signed-certificate-host and without key-password specified fails upon first request
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2720?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2720:
-------------------------------------
Fix Version/s: 3.0.0.Beta18
(was: 3.0.0.Beta17)
> Adding keystore with generate-self-signed-certificate-host and without key-password specified fails upon first request
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2720
> URL: https://issues.jboss.org/browse/WFCORE-2720
> Project: WildFly Core
> Issue Type: Bug
> Components: Security, Server
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
> Priority: Critical
> Labels: legacy
> Fix For: 3.0.0.Beta18
>
>
> If I create keystore with generate-self-signed-certificate-host defined, and define https listener to use such keystore, upon first request, when it is being created it fails with \[1\]. Any following requests results in this log message \[2\]. All the requests are hanging till client timeouts them.
> If the key-password is really needed, I believe it should be validated upon configuration creation.
> Also the requests should be terminated and rejected with 500 due server failing to initialize the ssl context due server being incorrectly configured.
>
> \[1\]
> {noformat}
> 13:15:45,781 ERROR [org.xnio.listener] (default I/O-6) XNIO001007: A channel event listener threw an exception: java.lang.RuntimeException: WFLYDM0114: Failed to lazily initialize SSL context
> at org.jboss.as.domain.management.security.SSLContextService$LazyInitSSLContext$LazyInitSpi.doInit(SSLContextService.java:231)
> at org.jboss.as.domain.management.security.SSLContextService$LazyInitSSLContext$LazyInitSpi.engineCreateSSLEngine(SSLContextService.java:257)
> at javax.net.ssl.SSLContext.createSSLEngine(SSLContext.java:361)
> at io.undertow.protocols.ssl.UndertowAcceptingSslChannel.accept(UndertowAcceptingSslChannel.java:139)
> at io.undertow.protocols.ssl.UndertowAcceptingSslChannel.accept(UndertowAcceptingSslChannel.java:56)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:289)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:131)
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:468)
> Caused by: java.lang.RuntimeException: WFLYDM0112: Failed to generate self signed certificate
> at org.jboss.as.domain.management.security.FileKeyManagerService.generateFileKeyStore(FileKeyManagerService.java:219)
> at org.jboss.as.domain.management.security.FileKeyManagerService.loadKeyStore(FileKeyManagerService.java:185)
> at org.jboss.as.domain.management.security.AbstractKeyManagerService.createKeyManagers(AbstractKeyManagerService.java:125)
> at org.jboss.as.domain.management.security.AbstractKeyManagerService.getKeyManagers(AbstractKeyManagerService.java:104)
> at org.jboss.as.domain.management.security.SSLContextService$LazyInitSSLContext$LazyInitSpi.doInit(SSLContextService.java:228)
> ... 12 more
> Caused by: java.lang.IllegalArgumentException: password can't be null
> at sun.security.provider.KeyProtector.<init>(KeyProtector.java:135)
> at sun.security.provider.JavaKeyStore.engineSetKeyEntry(JavaKeyStore.java:266)
> at sun.security.provider.JavaKeyStore$JKS.engineSetKeyEntry(JavaKeyStore.java:56)
> at sun.security.provider.KeyStoreDelegator.engineSetKeyEntry(KeyStoreDelegator.java:117)
> at sun.security.provider.JavaKeyStore$DualFormatJKS.engineSetKeyEntry(JavaKeyStore.java:70)
> at java.security.KeyStore.setKeyEntry(KeyStore.java:1140)
> at org.jboss.as.domain.management.security.FileKeyManagerService.generateFileKeyStore(FileKeyManagerService.java:212)
> ... 16 more
> {noformat}
> \[2\]
> {noformat}
> 13:34:05,862 ERROR [org.xnio.listener] (default I/O-2) XNIO001007: A channel event listener threw an exception: java.lang.IllegalStateException: SSLContextImpl is not initialized
> at sun.security.ssl.SSLContextImpl.engineCreateSSLEngine(SSLContextImpl.java:207)
> at javax.net.ssl.SSLContext.createSSLEngine(SSLContext.java:361)
> at org.jboss.as.domain.management.security.SSLContextService$LazyInitSSLContext$LazyInitSpi.engineCreateSSLEngine(SSLContextService.java:258)
> at javax.net.ssl.SSLContext.createSSLEngine(SSLContext.java:361)
> at io.undertow.protocols.ssl.UndertowAcceptingSslChannel.accept(UndertowAcceptingSslChannel.java:139)
> at io.undertow.protocols.ssl.UndertowAcceptingSslChannel.accept(UndertowAcceptingSslChannel.java:56)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:289)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:131)
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:468)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8414) EJBContext.getCallerPrincipal behaves differently in Elytron and legacy security
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-8414?page=com.atlassian.jira.plugin.... ]
Farah Juma reassigned WFLY-8414:
--------------------------------
Assignee: Farah Juma (was: Darran Lofthouse)
> EJBContext.getCallerPrincipal behaves differently in Elytron and legacy security
> --------------------------------------------------------------------------------
>
> Key: WFLY-8414
> URL: https://issues.jboss.org/browse/WFLY-8414
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Security
> Reporter: Josef Cacek
> Assignee: Farah Juma
>
> The {{EJBContext.getCallerPrincipal()}} used in unsecured EJB method returns "anonymous" (i.e. unauthenticatedIdentity) in legacy security and it returns authenticated user-name when the default security domain ("other") is mapped to Elytron.
> This could complicate users migration from legacy security to Elytron.
> I'm not sure if this behavior was intended or if it's just a problem of how the Elytron default domain mapping works in ejb3 subsystem.
> If the current {{getCallerPrincipal}} behavior is correct, then we should either reuse this JIRA for Documentation changes (especially Migration guide) or close this and create a new Documentation one.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8661) Transaction is marked disassociated from application thread when transaction manager reaper thread suspends transaction
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-8661?page=com.atlassian.jira.plugin.... ]
Scott Marlow updated WFLY-8661:
-------------------------------
Component/s: JPA / Hibernate
> Transaction is marked disassociated from application thread when transaction manager reaper thread suspends transaction
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-8661
> URL: https://issues.jboss.org/browse/WFLY-8661
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 11.0.0.Alpha1
> Reporter: Scott Marlow
> Assignee: Scott Marlow
>
> I created a pull request to enable the TxTimeoutTestCase ([JBEAP-10550] + [WFLY-5319]) which required a test change, however, the test is failing for me locally, due to org.wildfly.transaction.client.LocalTransaction.suspend() calling notifyAssociationListeners(false) in the TM reaper "tx timeout" thread, which is wrong, as the app client thread may still be associated with the same transaction.
> [https://gist.github.com/scottmarlow/1ae4a4abe98851b3fe6b1e602ba273d7] shows another reaper thread association call being made, that shouldn't be.
> I'm not sure of how the Narayana org.jboss.tm.listener.TransactionListenerRegistry SPI, internally ensured that the reaper thread didn't incorrectly perform association/disassociation but what we have now in WildFly (appears) to be different.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8661) Transaction is marked disassociated from application thread when transaction manager reaper thread suspends transaction
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-8661?page=com.atlassian.jira.plugin.... ]
Scott Marlow moved WFTC-19 to WFLY-8661:
----------------------------------------
Project: WildFly (was: WildFly Transaction Client)
Key: WFLY-8661 (was: WFTC-19)
Affects Version/s: 11.0.0.Alpha1
(was: 1.0.0.Beta21)
> Transaction is marked disassociated from application thread when transaction manager reaper thread suspends transaction
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-8661
> URL: https://issues.jboss.org/browse/WFLY-8661
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 11.0.0.Alpha1
> Reporter: Scott Marlow
>
> I created a pull request to enable the TxTimeoutTestCase ([JBEAP-10550] + [WFLY-5319]) which required a test change, however, the test is failing for me locally, due to org.wildfly.transaction.client.LocalTransaction.suspend() calling notifyAssociationListeners(false) in the TM reaper "tx timeout" thread, which is wrong, as the app client thread may still be associated with the same transaction.
> [https://gist.github.com/scottmarlow/1ae4a4abe98851b3fe6b1e602ba273d7] shows another reaper thread association call being made, that shouldn't be.
> I'm not sure of how the Narayana org.jboss.tm.listener.TransactionListenerRegistry SPI, internally ensured that the reaper thread didn't incorrectly perform association/disassociation but what we have now in WildFly (appears) to be different.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2734) ParallelBootOperationContext should add "foreign" steps to the main context
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-2734:
----------------------------------------
Summary: ParallelBootOperationContext should add "foreign" steps to the main context
Key: WFCORE-2734
URL: https://issues.jboss.org/browse/WFCORE-2734
Project: WildFly Core
Issue Type: Enhancement
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
The ParallelBootOperationContext addStep impl always adds steps for the same stage to its own queue. It should check the address of those steps and if not for its own subsystem it should add them to the main context's queue. This will allow subsystem A to add steps that affect subsystem B safe in the knowledge they will execute after completion of the parallel part of B's execution.
In Stage.MODEL addition of such steps for Stage.RUNTIME should be rejected. Such steps will not execute in any reasonable order vs the non-foreign steps that B itself will add.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years