February 2017 - infinispan-issues

[JBoss JIRA] (ISPN-7535) Cache creation requires specific permissions when using security manager

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/ISPN-7535?page=com.atlassian.jira.plugin.... ] Lin Gao updated ISPN-7535: -------------------------- Summary: Cache creation requires specific permissions when using security manager (was: java.lang.RuntimePermission("getClassLoader") is needed explicitly when using security manager) > Cache creation requires specific permissions when using security manager > ------------------------------------------------------------------------ > > Key: ISPN-7535 > URL: https://issues.jboss.org/browse/ISPN-7535 > Project: Infinispan > Issue Type: Bug > Components: Core > Reporter: Lin Gao > Assignee: Ingo Weiss > > *org.jboss.as.test.integration.ee.injection.resource.infinispan.InfinispanResourceRefTestCase#test* > {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=org.jboss.as.test.integration.ee.injection.resource.infinispan.* -Dsecurity.manager}} > {panel:title=NOTE} > specify the InfinispanResourceRefTestCase itself will succeed: > {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=org.jboss.as.test.integration.ee.injection.resource.infinispan.InfinispanResourceRefTestCase -Dsecurity.manager}} > {panel} > {code} > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/infinispan-resource-ref.war/WEB-INF/classes <no signer certificates>)" of "null") > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273) > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175) > at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1528) > at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1442) > at org.infinispan.commons.util.Util.getClassLoaders(Util.java:127) > at org.infinispan.commons.util.Util.loadClassStrict(Util.java:150) > at org.infinispan.commons.util.Util.loadClass(Util.java:101) > at org.infinispan.factories.AbstractComponentRegistry.instantiateFactory(AbstractComponentRegistry.java:359) > at org.infinispan.factories.AbstractComponentRegistry.createComponentFactoryInternal(AbstractComponentRegistry.java:339) > at org.infinispan.factories.ComponentRegistry.createComponentFactoryInternal(ComponentRegistry.java:202) > at org.infinispan.factories.AbstractComponentRegistry.getFactory(AbstractComponentRegistry.java:322) > at org.infinispan.factories.ComponentRegistry.getFactory(ComponentRegistry.java:183) > at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:288) > at org.infinispan.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:156) > at org.infinispan.factories.AbstractComponentRegistry.invokeInjectionMethod(AbstractComponentRegistry.java:241) > at org.infinispan.factories.AbstractComponentRegistry.access$000(AbstractComponentRegistry.java:70) > at org.infinispan.factories.AbstractComponentRegistry$Component.injectDependencies(AbstractComponentRegistry.java:815) > at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:215) > at org.infinispan.factories.ComponentRegistry.registerComponentInternal(ComponentRegistry.java:193) > at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:170) > at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:295) > at org.infinispan.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:156) > at org.infinispan.factories.AbstractComponentRegistry.invokeInjectionMethod(AbstractComponentRegistry.java:241) > at org.infinispan.factories.AbstractComponentRegistry.access$000(AbstractComponentRegistry.java:70) > at org.infinispan.factories.AbstractComponentRegistry$Component.injectDependencies(AbstractComponentRegistry.java:815) > at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:215) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5654) Make DeadlockDetectingLockManager aware of single-node locking

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5654?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-5654: ------------------------------------ Looking at the code, the deadlock detection doesn't seem to work at all in most cases. Lock intentions are only added in {{DeadlockDetectingLockManager.lock(key)}}, which doesn't get called on the transaction originator unless it's also the primary owner of the key. Thus lock intentions are never sent from the tx originator to the primary owners, and deadlock detection for multiple keys only works when all the keys are owned by the originator. And of course, same-key deadlocks cannot happen at all with the single-node locking. I propose to remove {{DeadlockDetectingLockManager}} altogether and to deprecate the related configuration. > Make DeadlockDetectingLockManager aware of single-node locking > -------------------------------------------------------------- > > Key: ISPN-5654 > URL: https://issues.jboss.org/browse/ISPN-5654 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 8.0.0.Beta2 > Reporter: Dan Berindei > > {{DeadlockDetectingLockManager}} seems to assume that the node that started a transaction acquires a local lock before replicating, which is wrong since we switched to locking only on the primary owner. > In particular, {{isSameKeyDeadlock}} can probably be removed altogether. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5654) Make DeadlockDetectingLockManager aware of single-node locking

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5654?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5654: ------------------------------- Status: Open (was: New) > Make DeadlockDetectingLockManager aware of single-node locking > -------------------------------------------------------------- > > Key: ISPN-5654 > URL: https://issues.jboss.org/browse/ISPN-5654 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 8.0.0.Beta2 > Reporter: Dan Berindei > > {{DeadlockDetectingLockManager}} seems to assume that the node that started a transaction acquires a local lock before replicating, which is wrong since we switched to locking only on the primary owner. > In particular, {{isSameKeyDeadlock}} can probably be removed altogether. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-7534) Support JCache on Wildfly/EAP

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-7534?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec edited comment on ISPN-7534 at 2/28/17 4:27 AM: -------------------------------------------------------------------- As mentioned in the [JEE mailing list|https://java.net/projects/javaee-spec/lists/users/archive/2016-09/me...], JCache 1.1 is only an errata release. There will be nothing new added. So if we need new features, JCache.next is the way to go. JCache 1.1 spec might be found here: https://docs.google.com/document/d/14BvLUyv5U3zhsbIGwA4hkLfFieBkaCPfaHazh... was (Author: sebastian.laskawiec): As mentioned in the [JEE mailing list|https://java.net/projects/javaee-spec/lists/users/archive/2016-09/me...], JCache 1.1 is only an errata release. There will be nothing new added. So if we need new features, JCache.next is the way to go. > Support JCache on Wildfly/EAP > ----------------------------- > > Key: ISPN-7534 > URL: https://issues.jboss.org/browse/ISPN-7534 > Project: Infinispan > Issue Type: Feature Request > Components: Integration > Reporter: Sebastian Łaskawiec > Assignee: Sebastian Łaskawiec > Priority: Critical > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-7523) Update cached RpcOptions when timeout changes

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-7523?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-7523: ------------------------------ Status: Open (was: New) > Update cached RpcOptions when timeout changes > --------------------------------------------- > > Key: ISPN-7523 > URL: https://issues.jboss.org/browse/ISPN-7523 > Project: Infinispan > Issue Type: Bug > Components: Core > Reporter: Radim Vansa > Assignee: Radim Vansa > Fix For: 9.0.0.Final > > > I thought these can be safely cached, but since remote timeout can be changed at runtime, we need to listen to these changes and update cached options accordingly. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-7523) Update cached RpcOptions when timeout changes

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-7523?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-7523: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/4897 > Update cached RpcOptions when timeout changes > --------------------------------------------- > > Key: ISPN-7523 > URL: https://issues.jboss.org/browse/ISPN-7523 > Project: Infinispan > Issue Type: Bug > Components: Core > Reporter: Radim Vansa > Assignee: Radim Vansa > Fix For: 9.0.0.Final > > > I thought these can be safely cached, but since remote timeout can be changed at runtime, we need to listen to these changes and update cached options accordingly. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-7523) Update cached RpcOptions when timeout changes

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-7523?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-7523: ------------------------------ Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.0.0.Final Resolution: Done > Update cached RpcOptions when timeout changes > --------------------------------------------- > > Key: ISPN-7523 > URL: https://issues.jboss.org/browse/ISPN-7523 > Project: Infinispan > Issue Type: Bug > Components: Core > Reporter: Radim Vansa > Assignee: Radim Vansa > Fix For: 9.0.0.Final > > > I thought these can be safely cached, but since remote timeout can be changed at runtime, we need to listen to these changes and update cached options accordingly. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-7534) Support JCache on Wildfly/EAP

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-7534?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec commented on ISPN-7534: ------------------------------------------- As mentioned in the [JEE mailing list|https://java.net/projects/javaee-spec/lists/users/archive/2016-09/me...], JCache 1.1 is only an errata release. There will be nothing new added. So if we need new features, JCache.next is the way to go. > Support JCache on Wildfly/EAP > ----------------------------- > > Key: ISPN-7534 > URL: https://issues.jboss.org/browse/ISPN-7534 > Project: Infinispan > Issue Type: Feature Request > Components: Integration > Reporter: Sebastian Łaskawiec > Assignee: Sebastian Łaskawiec > Priority: Critical > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-7534) Support JCache on Wildfly/EAP

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-7534?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec edited comment on ISPN-7534 at 2/28/17 4:13 AM: -------------------------------------------------------------------- Adam Bien created a bridge between JEE8 and JCache: https://github.com/Adopt-a-JSR/jcache-javaee A proposed [spec xml|https://github.com/Adopt-a-JSR/jcache-javaee/blob/master/jcache-javae...] looks very interesting: {code} <caches> <caching-provider>org.jsr107.ri.spi.RICachingProvider</caching-provider> <cache name="it" key="java.lang.String" value="java.lang.String"> <configuration> <property name="store.by.value" value="true"/> <property name="management.enabled" value="false"/> <property name="statistics.enabled" value="true"/> <property name="vendor.specific" value="unicorn"/> </configuration> </cache> <cache name="hack3rz" value="java.lang.String"> <configuration> <property name="store.by.value" value="false"/> <property name="management.enabled" value="true"/> <property name="statistics.enabled" value="false"/> <property name="java" value="duke"/> </configuration> </cache> </caches> {code} As mentioned in the [JEE mailing list|https://java.net/projects/javaee-spec/lists/users/archive/2016-09/me...] this is a Proof Of Concept repo. was (Author: sebastian.laskawiec): Adam Bien created a bridge between JEE8 and JCache: https://github.com/Adopt-a-JSR/jcache-javaee A proposed [spec xml|https://github.com/Adopt-a-JSR/jcache-javaee/blob/master/jcache-javae...] looks very interesting: {code} <caches> <caching-provider>org.jsr107.ri.spi.RICachingProvider</caching-provider> <cache name="it" key="java.lang.String" value="java.lang.String"> <configuration> <property name="store.by.value" value="true"/> <property name="management.enabled" value="false"/> <property name="statistics.enabled" value="true"/> <property name="vendor.specific" value="unicorn"/> </configuration> </cache> <cache name="hack3rz" value="java.lang.String"> <configuration> <property name="store.by.value" value="false"/> <property name="management.enabled" value="true"/> <property name="statistics.enabled" value="false"/> <property name="java" value="duke"/> </configuration> </cache> </caches> {code} > Support JCache on Wildfly/EAP > ----------------------------- > > Key: ISPN-7534 > URL: https://issues.jboss.org/browse/ISPN-7534 > Project: Infinispan > Issue Type: Feature Request > Components: Integration > Reporter: Sebastian Łaskawiec > Assignee: Sebastian Łaskawiec > Priority: Critical > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-7534) Support JCache on Wildfly/EAP

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-7534?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec commented on ISPN-7534: ------------------------------------------- Adam Bien created a bridge between JEE8 and JCache: https://github.com/Adopt-a-JSR/jcache-javaee A proposed [spec xml|https://github.com/Adopt-a-JSR/jcache-javaee/blob/master/jcache-javae...] looks very interesting: {code} <caches> <caching-provider>org.jsr107.ri.spi.RICachingProvider</caching-provider> <cache name="it" key="java.lang.String" value="java.lang.String"> <configuration> <property name="store.by.value" value="true"/> <property name="management.enabled" value="false"/> <property name="statistics.enabled" value="true"/> <property name="vendor.specific" value="unicorn"/> </configuration> </cache> <cache name="hack3rz" value="java.lang.String"> <configuration> <property name="store.by.value" value="false"/> <property name="management.enabled" value="true"/> <property name="statistics.enabled" value="false"/> <property name="java" value="duke"/> </configuration> </cache> </caches> {code} > Support JCache on Wildfly/EAP > ----------------------------- > > Key: ISPN-7534 > URL: https://issues.jboss.org/browse/ISPN-7534 > Project: Infinispan > Issue Type: Feature Request > Components: Integration > Reporter: Sebastian Łaskawiec > Assignee: Sebastian Łaskawiec > Priority: Critical > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues February 2017