[JBoss JIRA] (WFLY-13055) Permission check failed when using SecurityManager with IBM JDK
by Francesco Marchioni (Jira)
Francesco Marchioni created WFLY-13055:
------------------------------------------
Summary: Permission check failed when using SecurityManager with IBM JDK
Key: WFLY-13055
URL: https://issues.redhat.com/browse/WFLY-13055
Project: WildFly
Issue Type: Bug
Components: Security Manager, Test Suite
Affects Versions: 19.0.0.Beta1
Reporter: Francesco Marchioni
Assignee: Stefan Guilhen
When using IBM JDK in combination with SecurityManager a Permission check fails for classes using packages com.sun.org.apache.xerces.internal.jaxp
{code:java}
INFO] Running org.jboss.as.test.integration.ws.basic.PojoEndpointTestCase
[ERROR] Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 9.002 s <<< FAILURE! - in org.jboss.as.test.integration.ws.basic.PojoEndpointTestCase
[ERROR] testHelloError(org.jboss.as.test.integration.ws.basic.PojoEndpointTestCase) Time elapsed: 0.188 s <<< FAILURE!
org.junit.ComparisonFailure: expected:<[Fault for test purpose]> but was:<[Provider com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl could not be instantiated: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessClassInPackage.com.sun.org.apache.xerces.internal.jaxp")" in code source "(vfs:/content/jaxws-basic-pojo.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.jaxws-basic-pojo.war" from Service Module Loader")]>
at org.junit.Assert.assertEquals(Assert.java:115)
at org.junit.Assert.assertEquals(Assert.java:144)
at org.jboss.as.test.integration.ws.basic.BasicTests.testHelloError(BasicTests.java:69)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
at java.lang.reflect.Method.invoke(Method.java:508)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
{code}
Affected Tests in the AS Testsuite:
org.jboss.as.test.integration.ws.basic.PojoEndpointTestCase#testHelloError
org.jboss.as.test.xts.wsat.client.ATTestCase#testWSATVoteReadOnly
org.jboss.as.test.xts.wsat.client.ATTestCase#testWSATClientRollback
org.jboss.as.test.xts.wsat.client.ATTestCase#testWSATVoteRollback
org.jboss.as.test.xts.wsat.client.ATTestCase#testWSATApplicationException
org.jboss.as.test.xts.wsat.client.ATTestCase#testWSATSimple
org.jboss.as.test.xts.wsat.client.ATTestCase#testWSATSingleSimple
org.jboss.as.test.xts.wsat.client.ATTestCase#testWSATVoteRollbackPrePrepare
org.jboss.as.test.xts.wsat.client.ATTestCase#testWSATApplicationExceptionCommit
org.jboss.as.test.xts.wsat.client.ATTestCase#testWSATRollbackOnly
org.jboss.as.test.xts.wsba.coordinatorcompletion.client.BACoordinatorCompletionTestCase#testWSBACoordinatorSimple
org.jboss.as.test.xts.wsba.coordinatorcompletion.client.BACoordinatorCompletionTestCase#testWSBACoordinatorSingle
org.jboss.as.test.xts.wsba.coordinatorcompletion.client.BACoordinatorCompletionTestCase#testWSBACoordinatorApplicationException
org.jboss.as.test.xts.wsba.coordinatorcompletion.client.BACoordinatorCompletionTestCase#testWSBACoordinatorClientCancel
org.jboss.as.test.txbridge.fromjta.BridgeFromJTATestCase#testRollback
org.jboss.as.test.txbridge.fromjta.BridgeFromJTATestCase#testCommit
org.jboss.as.test.xts.suspend.wsat.AtomicTransactionSuspendTestCase#testRollbackAfterSuspend
org.jboss.as.test.xts.suspend.wsat.AtomicTransactionSuspendTestCase#testRemoteServiceAfterSuspend
org.jboss.as.test.xts.suspend.wsat.AtomicTransactionSuspendTestCase#testCommitAfterSuspend
org.jboss.as.test.xts.annotation.client.CompensatableTestCase#testNoTransaction
org.jboss.as.test.xts.annotation.client.CompensatableTestCase#testActiveTransaction
org.jboss.as.test.xts.annotation.client.TransactionalTestCase#testNoTransaction
org.jboss.as.test.xts.annotation.client.TransactionalTestCase#testActiveTransaction
org.jboss.as.test.xts.suspend.wsba.BusinessActivitySuspendTestCase#testRemoteServiceAfterSuspend
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (JGRP-2445) MessageBatch: removal on iteration is inefficient
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2445?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2445:
--------------------------------
The above code occurrences have been replaced with
{code:java}
MessageIterator it=batch.iterator();
while(it.hasNext()) {
Message msg=it.next();
if(condition)
it.remove(); // or it.replace(other_msg)
}
{code}
> MessageBatch: removal on iteration is inefficient
> -------------------------------------------------
>
> Key: JGRP-2445
> URL: https://issues.redhat.com/browse/JGRP-2445
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.0, 4.2.0
>
>
> We oftentimes have iteration through a MessageBatch and removal, e.g.
> {code:java}
> for(Message msg: batch) {
> if(condition)
> batch.remove(msg);
> }
> }
> {code}
> This is inefficient for large batches, as {{MessageBatch.remove()}} iterates through the batch until it finds the message to be nulled.
> It is more efficient to use {{BatchIterator.remove()}}.
> Also include a {{BatchIterator.replace()}} method.
> Pedro's code: [1] https://github.com/pruivo/JGroups/tree/t_msg_batch_iterator
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-12948) When shutting down, JDBC_PING tries to use a closed connection
by Sebastian Laskawiec (Jira)
[ https://issues.redhat.com/browse/WFLY-12948?page=com.atlassian.jira.plugi... ]
Sebastian Laskawiec commented on WFLY-12948:
--------------------------------------------
[~axelmak] It seems I found the root cause - in my examples I used {{info_writer_sleep_time=500}}, which resulted in JGroups trying to write a database, which was already closed.
I fixed it in https://github.com/keycloak/keycloak-containers/pull/255
> When shutting down, JDBC_PING tries to use a closed connection
> --------------------------------------------------------------
>
> Key: WFLY-12948
> URL: https://issues.redhat.com/browse/WFLY-12948
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Reporter: Sebastian Laskawiec
> Assignee: Radoslav Husar
> Priority: Minor
>
> One of the Keycloak demos use {{JDBC_PING}} as discovery protocol (see [here|https://github.com/keycloak/keycloak-containers/blob/master/docker-c...]). One of our users noticed (and I confirmed it) that when shutting Keycloak down, {{JDBC_PING}} tries to use a closed Connection Factory:
> {code}
> keycloak_2 | 09:14:34,807 ERROR [org.jgroups.protocols.JDBC_PING] (ServerService Thread Pool -- 23) JGRP000115: Could not open connection to database: java.sql.SQLException: javax.resource.ResourceException: IJ000470: You are trying to use a connection factory that has been shut down: java:jboss/datasources/KeycloakDS
> keycloak_2 | at org.jboss.ironjacamar.jdbcadapters@1.4.17.Final//org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:159)
> keycloak_2 | at org.jboss.as.connector@18.0.1.Final//org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:64)
> keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.getConnection(JDBC_PING.java:310)
> keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.clearTable(JDBC_PING.java:361)
> keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.removeAll(JDBC_PING.java:190)
> keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.stop(JDBC_PING.java:119)
> keycloak_2 | at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
> keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.stack.ProtocolStack.stopStack(ProtocolStack.java:906)
> keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.JChannel.stopStack(JChannel.java:1076)
> keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.JChannel._close(JChannel.java:1063)
> keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.JChannel.close(JChannel.java:454)
> keycloak_2 | at org.jboss.as.clustering.jgroups@18.0.1.Final//org.jboss.as.clustering.jgroups.subsystem.ChannelServiceConfigurator.accept(ChannelServiceConfigurator.java:132)
> keycloak_2 | at org.jboss.as.clustering.jgroups@18.0.1.Final//org.jboss.as.clustering.jgroups.subsystem.ChannelServiceConfigurator.accept(ChannelServiceConfigurator.java:58)
> keycloak_2 | at org.wildfly.clustering.service@18.0.1.Final//org.wildfly.clustering.service.FunctionalService.stop(FunctionalService.java:77)
> keycloak_2 | at org.wildfly.clustering.service@18.0.1.Final//org.wildfly.clustering.service.AsyncServiceConfigurator$AsyncService.lambda$stop$1(AsyncServiceConfigurator.java:142)
> keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> keycloak_2 | at java.base/java.lang.Thread.run(Thread.java:834)
> keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.JBossThread.run(JBossThread.java:485)
> keycloak_2 | Caused by: javax.resource.ResourceException: IJ000470: You are trying to use a connection factory that has been shut down: java:jboss/datasources/KeycloakDS
> keycloak_2 | at org.jboss.ironjacamar.impl@1.4.17.Final//org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:777)
> keycloak_2 | at org.jboss.ironjacamar.jdbcadapters@1.4.17.Final//org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:151)
> keycloak_2 | ... 20 more
> keycloak_2 | 09:14:34,807 ERROR [org.jgroups.JChannel] (ServerService Thread Pool -- 23) JGRP000020: failed destroying the protocol stack: java.lang.NullPointerException
> keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.clearTable(JDBC_PING.java:362)
> keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.removeAll(JDBC_PING.java:190)
> keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.protocols.JDBC_PING.stop(JDBC_PING.java:119)
> keycloak_2 | at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
> keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.stack.ProtocolStack.stopStack(ProtocolStack.java:906)
> keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.JChannel.stopStack(JChannel.java:1076)
> keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.JChannel._close(JChannel.java:1063)
> keycloak_2 | at org.jgroups@4.1.4.Final//org.jgroups.JChannel.close(JChannel.java:454)
> keycloak_2 | at org.jboss.as.clustering.jgroups@18.0.1.Final//org.jboss.as.clustering.jgroups.subsystem.ChannelServiceConfigurator.accept(ChannelServiceConfigurator.java:132)
> keycloak_2 | at org.jboss.as.clustering.jgroups@18.0.1.Final//org.jboss.as.clustering.jgroups.subsystem.ChannelServiceConfigurator.accept(ChannelServiceConfigurator.java:58)
> keycloak_2 | at org.wildfly.clustering.service@18.0.1.Final//org.wildfly.clustering.service.FunctionalService.stop(FunctionalService.java:77)
> keycloak_2 | at org.wildfly.clustering.service@18.0.1.Final//org.wildfly.clustering.service.AsyncServiceConfigurator$AsyncService.lambda$stop$1(AsyncServiceConfigurator.java:142)
> keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> keycloak_2 | at java.base/java.lang.Thread.run(Thread.java:834)
> keycloak_2 | at org.jboss.threads@2.3.3.Final//org.jboss.threads.JBossThread.run(JBossThread.java:485)
> keycloak_2 | 09:14:34,819 INFO [org.jboss.as] (MSC service thread 1-5) WFLYSRV0050: Keycloak 8.0.1 (WildFly Core 10.0.3.Final) stopped in 160ms
> keycloak_2 | *** JBossAS process (510) received TERM signal ***
> {code}
> More information:
> * Generated {{standalone-ha.xml}} used by the example: https://gist.github.com/slaskawi/7cb8eefdfa3e27f7c0f0e62e26bb0216
> * Full logs from Docker Compose: https://gist.github.com/slaskawi/239a2a1ea83d7bc98c8d0d884480c77e
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (JGRP-2445) MessageBatch: removal on iteration is inefficient
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2445?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2445:
---------------------------
Description:
We oftentimes have iteration through a MessageBatch and removal, e.g.
{code:java}
for(Message msg: batch) {
if(condition)
batch.remove(msg);
}
}
{code}
This is inefficient for large batches, as {{MessageBatch.remove()}} iterates through the batch until it finds the message to be nulled.
It is more efficient to use {{BatchIterator.remove()}}.
Also include a {{BatchIterator.replace()}} method.
Pedro's code: [1] https://github.com/pruivo/JGroups/tree/t_msg_batch_iterator
was:
We oftentimes have iteration through a MessageBatch and removal, e.g.
{code:java}
for(Message msg: batch) {
if(condition)
batch.remove(msg);
}
}
{code}
This is inefficient for large batches, as {{MessageBatch.remove()}} iterates through the batch until it finds the message to be nulled.
It is more efficient to use {{BatchIterator.remove()}}.
Pedro's code: [1] https://github.com/pruivo/JGroups/tree/t_msg_batch_iterator
> MessageBatch: removal on iteration is inefficient
> -------------------------------------------------
>
> Key: JGRP-2445
> URL: https://issues.redhat.com/browse/JGRP-2445
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.0, 4.2.0
>
>
> We oftentimes have iteration through a MessageBatch and removal, e.g.
> {code:java}
> for(Message msg: batch) {
> if(condition)
> batch.remove(msg);
> }
> }
> {code}
> This is inefficient for large batches, as {{MessageBatch.remove()}} iterates through the batch until it finds the message to be nulled.
> It is more efficient to use {{BatchIterator.remove()}}.
> Also include a {{BatchIterator.replace()}} method.
> Pedro's code: [1] https://github.com/pruivo/JGroups/tree/t_msg_batch_iterator
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (JGRP-2445) MessageBatch: removal on iteration is inefficient
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2445?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2445:
---------------------------
Description:
We oftentimes have iteration through a MessageBatch and removal, e.g.
{code:java}
for(Message msg: batch) {
if(condition)
batch.remove(msg);
}
}
{code}
This is inefficient for large batches, as {{MessageBatch.remove()}} iterates through the batch until it finds the message to be nulled.
It is more efficient to use {{BatchIterator.remove()}}.
Pedro's code: [1] https://github.com/pruivo/JGroups/tree/t_msg_batch_iterator
was:
We oftentimes have iteration through a MessageBatch and removal, e.g.
{code:java}
for(Message msg: batch) {
if(condition)
batch.remove(msg);
}
}
{code}
This is inefficient for large batches, as {{MessageBatch.remove()}} iterates through the batch until it finds the message to be nulled.
It is more efficient to use {{BatchIterator.remove()}}.
> MessageBatch: removal on iteration is inefficient
> -------------------------------------------------
>
> Key: JGRP-2445
> URL: https://issues.redhat.com/browse/JGRP-2445
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.0, 4.2.0
>
>
> We oftentimes have iteration through a MessageBatch and removal, e.g.
> {code:java}
> for(Message msg: batch) {
> if(condition)
> batch.remove(msg);
> }
> }
> {code}
> This is inefficient for large batches, as {{MessageBatch.remove()}} iterates through the batch until it finds the message to be nulled.
> It is more efficient to use {{BatchIterator.remove()}}.
> Pedro's code: [1] https://github.com/pruivo/JGroups/tree/t_msg_batch_iterator
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months