[JBoss JIRA] (WFCORE-4848) Illegal reflective access by org.wildfly.extension.elytron.SSLDefinitions
by Wagner Queiroz (Jira)
[ https://issues.redhat.com/browse/WFCORE-4848?page=com.atlassian.jira.plug... ]
Wagner Queiroz deleted WFCORE-4848:
-----------------------------------
> Illegal reflective access by org.wildfly.extension.elytron.SSLDefinitions
> -------------------------------------------------------------------------
>
> Key: WFCORE-4848
> URL: https://issues.redhat.com/browse/WFCORE-4848
> Project: WildFly Core
> Issue Type: Bug
> Environment: Windows 7 x64. Java 11: OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11+28-201810022317, mixed mode)
> Reporter: Wagner Queiroz
> Priority: Major
> Labels: Java11, access, elytron, illegal, reflective, wildfly
>
> After configuring HTTPS using the following guide: [Enable One-way SSL/TLS for Applications|http://docs.wildfly.org/14/WildFly_Elytron_Security.html#con...], configuration seems ok and server boots fine however an illegal reflective access warning comes up from jar within Elytron:
> {color:red}
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by org.wildfly.extension.elytron.SSLDefinitions (jar:file:/D:/wildfly-14.0.1.Final_FleetManager/modules/system/layers/base/org/wildfly/extension/elytron/main/wildfly-elytron-integration-6.0.2.Final.jar!/) to method com.sun.net.ssl.internal.ssl.Provider.isFIPS()
> WARNING: Please consider reporting this to the maintainers of org.wildfly.extension.elytron.SSLDefinitions
> WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> {color}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFCORE-4848) Illegal reflective access by org.wildfly.extension.elytron.SSLDefinitions
by Wagner Queiroz (Jira)
Wagner Queiroz created WFCORE-4848:
--------------------------------------
Summary: Illegal reflective access by org.wildfly.extension.elytron.SSLDefinitions
Key: WFCORE-4848
URL: https://issues.redhat.com/browse/WFCORE-4848
Project: WildFly Core
Issue Type: Bug
Components: Security
Environment: Windows 7 x64. Java 11: OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11+28-201810022317, mixed mode)
Reporter: Wagner Queiroz
After configuring HTTPS using the following guide: [Enable One-way SSL/TLS for Applications|http://docs.wildfly.org/14/WildFly_Elytron_Security.html#con...], configuration seems ok and server boots fine however an illegal reflective access warning comes up from jar within Elytron:
{color:red}
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.wildfly.extension.elytron.SSLDefinitions (jar:file:/D:/wildfly-14.0.1.Final_FleetManager/modules/system/layers/base/org/wildfly/extension/elytron/main/wildfly-elytron-integration-6.0.2.Final.jar!/) to method com.sun.net.ssl.internal.ssl.Provider.isFIPS()
WARNING: Please consider reporting this to the maintainers of org.wildfly.extension.elytron.SSLDefinitions
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
{color}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (JBJCA-1403) Make connection Validation (at ConnectionValidator) outside of lock
by Flavia Rainone (Jira)
[ https://issues.redhat.com/browse/JBJCA-1403?page=com.atlassian.jira.plugi... ]
Flavia Rainone updated JBJCA-1403:
----------------------------------
Git Pull Request: https://github.com/ironjacamar/ironjacamar/pull/700
> Make connection Validation (at ConnectionValidator) outside of lock
> -------------------------------------------------------------------
>
> Key: JBJCA-1403
> URL: https://issues.redhat.com/browse/JBJCA-1403
> Project: IronJacamar
> Issue Type: Enhancement
> Reporter: Flavia Rainone
> Assignee: Flavia Rainone
> Priority: Major
>
> As can be seen in the following stack trace, connection validation inside the connection validator lock might lock the entire prefill of other pools:
> {code}
> "default task-1122" #4743 prio=5 os_prio=0 tid=0x000000000929f800 nid=0x12067 waiting for monitor entry [0x00007fe6c7305000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getManagedConnectionPool(AbstractPool.java:299)
> - waiting to lock <0x0000000083be8028> (a org.jboss.jca.core.connectionmanager.pool.strategy.PoolBySubject)
> at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:596)
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:624)
> at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:440)
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:789)
> at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:151)
> at org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:64)
> ...
> "default task-1144" #4839 prio=5 os_prio=0 tid=0x000000000ccca800 nid=0x12718 waiting on condition [0x00007fe6cc532000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x000000008082b8f8> (a java.util.concurrent.locks.ReentrantLock$FairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at java.util.concurrent.locks.ReentrantLock$FairSync.lock(ReentrantLock.java:224)
> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
> at org.jboss.jca.core.connectionmanager.pool.validator.ConnectionValidator.internalRegisterPool(ConnectionValidator.java:185)
> at org.jboss.jca.core.connectionmanager.pool.validator.ConnectionValidator.registerPool(ConnectionValidator.java:167)
> at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.initialize(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:196)
> at org.jboss.jca.core.connectionmanager.pool.mcp.ManagedConnectionPoolFactory.init(ManagedConnectionPoolFactory.java:191)
> at org.jboss.jca.core.connectionmanager.pool.mcp.ManagedConnectionPoolFactory.create(ManagedConnectionPoolFactory.java:173)
> at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getManagedConnectionPool(AbstractPool.java:306)
> - locked <0x0000000083be8028> (a org.jboss.jca.core.connectionmanager.pool.strategy.PoolBySubject)
> at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:596)
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:624)
> at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:440)
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:789)
> at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:151)
> at org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:64)
> {code}
> The reason for this is that a new pool must be registered, and currently this operation is being blocked by connection validation. If connection validation is slow, this could compromise other threads creating pools and connections as shown in the example.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (JBJCA-1403) Make connection Validation (at ConnectionValidator) outside of lock
by Flavia Rainone (Jira)
Flavia Rainone created JBJCA-1403:
-------------------------------------
Summary: Make connection Validation (at ConnectionValidator) outside of lock
Key: JBJCA-1403
URL: https://issues.redhat.com/browse/JBJCA-1403
Project: IronJacamar
Issue Type: Enhancement
Reporter: Flavia Rainone
As can be seen in the following stack trace, connection validation inside the connection validator lock might lock the entire prefill of other pools:
{code}
"default task-1122" #4743 prio=5 os_prio=0 tid=0x000000000929f800 nid=0x12067 waiting for monitor entry [0x00007fe6c7305000]
java.lang.Thread.State: BLOCKED (on object monitor)
at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getManagedConnectionPool(AbstractPool.java:299)
- waiting to lock <0x0000000083be8028> (a org.jboss.jca.core.connectionmanager.pool.strategy.PoolBySubject)
at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:596)
at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:624)
at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:440)
at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:789)
at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:151)
at org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:64)
...
"default task-1144" #4839 prio=5 os_prio=0 tid=0x000000000ccca800 nid=0x12718 waiting on condition [0x00007fe6cc532000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x000000008082b8f8> (a java.util.concurrent.locks.ReentrantLock$FairSync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
at java.util.concurrent.locks.ReentrantLock$FairSync.lock(ReentrantLock.java:224)
at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
at org.jboss.jca.core.connectionmanager.pool.validator.ConnectionValidator.internalRegisterPool(ConnectionValidator.java:185)
at org.jboss.jca.core.connectionmanager.pool.validator.ConnectionValidator.registerPool(ConnectionValidator.java:167)
at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.initialize(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:196)
at org.jboss.jca.core.connectionmanager.pool.mcp.ManagedConnectionPoolFactory.init(ManagedConnectionPoolFactory.java:191)
at org.jboss.jca.core.connectionmanager.pool.mcp.ManagedConnectionPoolFactory.create(ManagedConnectionPoolFactory.java:173)
at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getManagedConnectionPool(AbstractPool.java:306)
- locked <0x0000000083be8028> (a org.jboss.jca.core.connectionmanager.pool.strategy.PoolBySubject)
at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:596)
at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:624)
at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:440)
at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:789)
at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:151)
at org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:64)
{code}
The reason for this is that a new pool must be registered, and currently this operation is being blocked by connection validation. If connection validation is slow, this could compromise other threads creating pools and connections as shown in the example.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (JBJCA-1403) Make connection Validation (at ConnectionValidator) outside of lock
by Flavia Rainone (Jira)
[ https://issues.redhat.com/browse/JBJCA-1403?page=com.atlassian.jira.plugi... ]
Flavia Rainone reassigned JBJCA-1403:
-------------------------------------
Assignee: Flavia Rainone
> Make connection Validation (at ConnectionValidator) outside of lock
> -------------------------------------------------------------------
>
> Key: JBJCA-1403
> URL: https://issues.redhat.com/browse/JBJCA-1403
> Project: IronJacamar
> Issue Type: Enhancement
> Reporter: Flavia Rainone
> Assignee: Flavia Rainone
> Priority: Major
>
> As can be seen in the following stack trace, connection validation inside the connection validator lock might lock the entire prefill of other pools:
> {code}
> "default task-1122" #4743 prio=5 os_prio=0 tid=0x000000000929f800 nid=0x12067 waiting for monitor entry [0x00007fe6c7305000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getManagedConnectionPool(AbstractPool.java:299)
> - waiting to lock <0x0000000083be8028> (a org.jboss.jca.core.connectionmanager.pool.strategy.PoolBySubject)
> at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:596)
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:624)
> at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:440)
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:789)
> at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:151)
> at org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:64)
> ...
> "default task-1144" #4839 prio=5 os_prio=0 tid=0x000000000ccca800 nid=0x12718 waiting on condition [0x00007fe6cc532000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x000000008082b8f8> (a java.util.concurrent.locks.ReentrantLock$FairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at java.util.concurrent.locks.ReentrantLock$FairSync.lock(ReentrantLock.java:224)
> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
> at org.jboss.jca.core.connectionmanager.pool.validator.ConnectionValidator.internalRegisterPool(ConnectionValidator.java:185)
> at org.jboss.jca.core.connectionmanager.pool.validator.ConnectionValidator.registerPool(ConnectionValidator.java:167)
> at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.initialize(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:196)
> at org.jboss.jca.core.connectionmanager.pool.mcp.ManagedConnectionPoolFactory.init(ManagedConnectionPoolFactory.java:191)
> at org.jboss.jca.core.connectionmanager.pool.mcp.ManagedConnectionPoolFactory.create(ManagedConnectionPoolFactory.java:173)
> at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getManagedConnectionPool(AbstractPool.java:306)
> - locked <0x0000000083be8028> (a org.jboss.jca.core.connectionmanager.pool.strategy.PoolBySubject)
> at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:596)
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:624)
> at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:440)
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:789)
> at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:151)
> at org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:64)
> {code}
> The reason for this is that a new pool must be registered, and currently this operation is being blocked by connection validation. If connection validation is slow, this could compromise other threads creating pools and connections as shown in the example.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFCORE-4847) The quoted FILE parameter in the galleon configuration causes the server to fail to build
by James Perkins (Jira)
James Perkins created WFCORE-4847:
-------------------------------------
Summary: The quoted FILE parameter in the galleon configuration causes the server to fail to build
Key: WFCORE-4847
URL: https://issues.redhat.com/browse/WFCORE-4847
Project: WildFly Core
Issue Type: Bug
Components: Build System
Reporter: James Perkins
Assignee: James Perkins
In the {{domain-profile.xml}} and the {{domain-load-balancer.xml}} Galleon configuration files there is a parameter value of {{["&quot;FILE&quot;"]}}. Galleon attempts to use the quoted value, {{"FILE"}}, in the capability name. This results in the capability not being found as the quotes are stripped for the capability name.
As a workaround the quotes should be removed from the XML configurations.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFCORE-4847) The quoted FILE parameter in the Galleon configuration causes the server to fail to build
by James Perkins (Jira)
[ https://issues.redhat.com/browse/WFCORE-4847?page=com.atlassian.jira.plug... ]
James Perkins updated WFCORE-4847:
----------------------------------
Summary: The quoted FILE parameter in the Galleon configuration causes the server to fail to build (was: The quoted FILE parameter in the galleon configuration causes the server to fail to build)
> The quoted FILE parameter in the Galleon configuration causes the server to fail to build
> -----------------------------------------------------------------------------------------
>
> Key: WFCORE-4847
> URL: https://issues.redhat.com/browse/WFCORE-4847
> Project: WildFly Core
> Issue Type: Bug
> Components: Build System
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Major
>
> In the {{domain-profile.xml}} and the {{domain-load-balancer.xml}} Galleon configuration files there is a parameter value of {{["&quot;FILE&quot;"]}}. Galleon attempts to use the quoted value, {{"FILE"}}, in the capability name. This results in the capability not being found as the quotes are stripped for the capability name.
> As a workaround the quotes should be removed from the XML configurations.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13092) The quoted FILE parameter in the Galleon configuration causes the server to fail to build
by James Perkins (Jira)
[ https://issues.redhat.com/browse/WFLY-13092?page=com.atlassian.jira.plugi... ]
James Perkins moved WFCORE-4847 to WFLY-13092:
----------------------------------------------
Project: WildFly (was: WildFly Core)
Key: WFLY-13092 (was: WFCORE-4847)
Component/s: Build System
(was: Build System)
> The quoted FILE parameter in the Galleon configuration causes the server to fail to build
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-13092
> URL: https://issues.redhat.com/browse/WFLY-13092
> Project: WildFly
> Issue Type: Bug
> Components: Build System
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Major
>
> In the {{domain-profile.xml}} and the {{domain-load-balancer.xml}} Galleon configuration files there is a parameter value of {{["&quot;FILE&quot;"]}}. Galleon attempts to use the quoted value, {{"FILE"}}, in the capability name. This results in the capability not being found as the quotes are stripped for the capability name.
> As a workaround the quotes should be removed from the XML configurations.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months