[JBoss JIRA] (ISPN-7313) AbstractFileLookup.lookupFileStrict broken on Windows
by Stefan Engel (JIRA)
[ https://issues.jboss.org/browse/ISPN-7313?page=com.atlassian.jira.plugin.... ]
Stefan Engel commented on ISPN-7313:
------------------------------------
Possible fix is to use an {{URLConnection}} instead of {{ClassLoader.getResourceAsStream()}}.
This is a 'works for me' solution. Proper handling should then either wrap the exceptions in {{FileNotFoundException}} or change exception handling in {{AbstractFileLookup.getConfiguratuonBuilderHolder()}}.
{code}
public InputStream lookupFileStrict(URI uri, ClassLoader cl) throws FileNotFoundException {
InputStream stream = null;
try {
URL url = new URL(uri.toString());
URLConnection connection = url.openConnection();
if (!(connection instanceof HttpURLConnection)) {
stream = connection.getInputStream();
} else {
throw new IllegalArgumentException("URL of type 'http' not supported");
}
} catch (IOException e) {
throw new IllegalStateException("Something went wrong", e);
}
return stream;
}
{code}
> AbstractFileLookup.lookupFileStrict broken on Windows
> -----------------------------------------------------
>
> Key: ISPN-7313
> URL: https://issues.jboss.org/browse/ISPN-7313
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.0.0.Alpha4, 9.0.0.Beta1, 8.2.5.Final
> Environment: Using Infinispan as JCache provider in Spring Boot (v1.3.5) application on Windows (either IDE (Eclipse) or fat jar).
> Reporter: Stefan Engel
>
> The fix in ISPN-5949 breaks Windows compatibility.
> infinispan.xml is configured in application.properties
> {noformat}
> spring.cache.jcache.config=classpath:spring/infinispan.xml
> {noformat}
> When using Infinispan in a Spring Boot application (fat jar or Eclipse IDE) the following exception is thrown:
> {noformat}
> Caused by: org.infinispan.commons.CacheConfigurationException:
> com.ctc.wstx.exc.WstxIOException: Stream closed
> at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:119)
> at org.infinispan.jcache.embedded.JCacheManager.getConfigurationBuilderHolder(JCacheManager.java:100)
> at org.infinispan.jcache.embedded.JCacheManager.<init>(JCacheManager.java:56)
> at org.infinispan.jcache.embedded.JCachingProvider.createCacheManager(JCachingProvider.java:46)
> at org.infinispan.jcache.AbstractJCachingProvider.getCacheManager(AbstractJCachingProvider.java:67)
> at org.springframework.boot.autoconfigure.cache.JCacheCacheConfiguration.createCacheManager(JCacheCacheConfiguration.java:101)
> ...
> {noformat}
> When {{AbstractFileLookup.lookupFileStrict()}} is called in {{JCacheManager.getConfigurationHolder()}} the URI used for infinispan.xml looks something like this:
> * fat jar
> {noformat}
> jar:file:/C:/projects/myapp/myservice-0.0.1.jar!/spring/infinispan.xml
> {noformat}
> * running app from within IDE
> {noformat}
> file:/C:/projects/workspace/myservice/target/classes/spring/infinispan.xml
> {noformat}
> The problem ist now twofold:
> # First this nasty 'C:' in the Windows path breaks the parsing code in {{AbstractFileLookup.lookupFileStrict()}}, as {{lastIndexOf(':')}} cuts the drive letter from the path and not just 'jar:file:' as intended. The resulting {{fileName}} cannot be resolved and {{cl.getResourceAsStream(fileName)}} returns {{null}}.
> {code}
> public InputStream lookupFileStrict(URI uri, ClassLoader cl) throws FileNotFoundException {
> //in case we don't have only file schema, but {{jar:file}} schema too, we have to get rid of all schemas
> int startIndex = uri.toString().lastIndexOf(':');
> String fileName = uri.toString().substring(startIndex + 1);
> return cl.getResourceAsStream(fileName);
> }
> {code}
> # This method gets called too when running from within an IDE (at least Eclipse with Maven integration). But in this case Spring JCacheCacheConfiguration magic (createCachemanager() - configLocation.getURI()) resolves this path to a full path as seen above (not a classpath relative to {{/target/classes}}). As this path ist not on the classpath, {{cl.getResourceAsStream(fileName)}} returns {{null}}.
> In both cases {{lookupFileStrict}} returns {{null}} as {{InputStream}} which in turn leads to the exception mentioned above.
> The old code of {{lookupFileStrict()}}
> {code}
> return new FileInputStream(new File(uri));
> {code}
> works fine from within the IDE, but is broken for a fat jar (ISPN-5949).
> I am currently trying to find a workaround for this. But as far as I can see, the current behaviour (fix or no fix) is going to a problem when developing/running Infinispan enabled applications on Windows.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (ISPN-7160) RemoteSpringSessionTest random failures
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-7160?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec updated ISPN-7160:
--------------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/4679, https://github.com/infinispan/infinispan/pull/4726 (was: https://github.com/infinispan/infinispan/pull/4679)
> RemoteSpringSessionTest random failures
> ---------------------------------------
>
> Key: ISPN-7160
> URL: https://issues.jboss.org/browse/ISPN-7160
> Project: Infinispan
> Issue Type: Bug
> Components: Spring Integration
> Reporter: Dan Berindei
> Assignee: Sebastian Łaskawiec
> Priority: Critical
> Labels: testsuite_stability
> Fix For: 9.0.0.Beta2
>
>
> {{RemoteSpringSessionTest}} and {{EmbeddedSpringSessionTest}} use the default cache jmx configuration, so they try to register the same JMX object names. If they run in parallel, one of them will fail to start the cache manager:
> {noformat}
> org.infinispan.jmx.JmxDomainConflictException: ISPN000034: There's already a JMX MBean instance type=CacheManager,name="DefaultCacheManager" already registered under 'org.infinispan' JMX domain. If you want to allow multiple instances configured with same JMX domain enable 'allowDuplicateDomains' attribute in 'globalJmxStatistics' config element
> at org.infinispan.jmx.JmxUtil.buildJmxDomain(JmxUtil.java:53)
> at org.infinispan.jmx.CacheManagerJmxRegistration.updateDomain(CacheManagerJmxRegistration.java:79)
> at org.infinispan.jmx.CacheManagerJmxRegistration.buildRegistrar(CacheManagerJmxRegistration.java:73)
> at org.infinispan.jmx.AbstractJmxRegistration.registerMBeans(AbstractJmxRegistration.java:37)
> at org.infinispan.jmx.CacheManagerJmxRegistration.start(CacheManagerJmxRegistration.java:41)
> at org.infinispan.manager.DefaultCacheManager.start(DefaultCacheManager.java:661)
> at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:235)
> at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:147)
> at org.infinispan.integrationtests.spring.boot.session.remote.RemoteSpringSessionTest.beforeclass(RemoteSpringSessionTest.java:29)
> {noformat}
> If the cache manager was not created, teardown also fails with a NPE:
> {noformat}
> java.lang.NullPointerException
> at org.infinispan.integrationtests.spring.boot.session.remote.RemoteSpringSessionTest.afterClass(RemoteSpringSessionTest.java:41)
> {noformat}
> The test should use the {{TestCacheManagerFactory}} methods to create the cache manager, which will set a unique JMX domain name for each instance.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (ISPN-7160) RemoteSpringSessionTest random failures
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-7160?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec reopened ISPN-7160:
---------------------------------------
> RemoteSpringSessionTest random failures
> ---------------------------------------
>
> Key: ISPN-7160
> URL: https://issues.jboss.org/browse/ISPN-7160
> Project: Infinispan
> Issue Type: Bug
> Components: Spring Integration
> Reporter: Dan Berindei
> Assignee: Sebastian Łaskawiec
> Priority: Critical
> Labels: testsuite_stability
> Fix For: 9.0.0.Beta2
>
>
> {{RemoteSpringSessionTest}} and {{EmbeddedSpringSessionTest}} use the default cache jmx configuration, so they try to register the same JMX object names. If they run in parallel, one of them will fail to start the cache manager:
> {noformat}
> org.infinispan.jmx.JmxDomainConflictException: ISPN000034: There's already a JMX MBean instance type=CacheManager,name="DefaultCacheManager" already registered under 'org.infinispan' JMX domain. If you want to allow multiple instances configured with same JMX domain enable 'allowDuplicateDomains' attribute in 'globalJmxStatistics' config element
> at org.infinispan.jmx.JmxUtil.buildJmxDomain(JmxUtil.java:53)
> at org.infinispan.jmx.CacheManagerJmxRegistration.updateDomain(CacheManagerJmxRegistration.java:79)
> at org.infinispan.jmx.CacheManagerJmxRegistration.buildRegistrar(CacheManagerJmxRegistration.java:73)
> at org.infinispan.jmx.AbstractJmxRegistration.registerMBeans(AbstractJmxRegistration.java:37)
> at org.infinispan.jmx.CacheManagerJmxRegistration.start(CacheManagerJmxRegistration.java:41)
> at org.infinispan.manager.DefaultCacheManager.start(DefaultCacheManager.java:661)
> at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:235)
> at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:147)
> at org.infinispan.integrationtests.spring.boot.session.remote.RemoteSpringSessionTest.beforeclass(RemoteSpringSessionTest.java:29)
> {noformat}
> If the cache manager was not created, teardown also fails with a NPE:
> {noformat}
> java.lang.NullPointerException
> at org.infinispan.integrationtests.spring.boot.session.remote.RemoteSpringSessionTest.afterClass(RemoteSpringSessionTest.java:41)
> {noformat}
> The test should use the {{TestCacheManagerFactory}} methods to create the cache manager, which will set a unique JMX domain name for each instance.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (ISPN-7314) Remove duplication code in AbstractListenerImpl and CacheNotifierImpl
by Galder Zamarreño (JIRA)
Galder Zamarreño created ISPN-7314:
--------------------------------------
Summary: Remove duplication code in AbstractListenerImpl and CacheNotifierImpl
Key: ISPN-7314
URL: https://issues.jboss.org/browse/ISPN-7314
Project: Infinispan
Issue Type: Enhancement
Affects Versions: 9.0.0.Beta2
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
Fix For: 9.0.0.Final
To speed up introduction of addFilteredListener, some code was duplicated in AbstractListenerImpl and CacheNotifierImpl. Refactor/deduplicate code.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (ISPN-7283) Make remote event supporting cluster listener more fine grained
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-7283?page=com.atlassian.jira.plugin.... ]
William Burns commented on ISPN-7283:
-------------------------------------
8.2.x has been integrated.
> Make remote event supporting cluster listener more fine grained
> ---------------------------------------------------------------
>
> Key: ISPN-7283
> URL: https://issues.jboss.org/browse/ISPN-7283
> Project: Infinispan
> Issue Type: Bug
> Components: Listeners, Remote Protocols
> Affects Versions: 9.0.0.Alpha4, 8.2.5.Final
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 9.0.0.Beta2, 8.2.6.Final
>
>
> Make server side cluster listener used for supporting remote events more fine grained. Right now if a client registers for created events, server side all nodes push all currently supported events over to the node where the remote listener is located: created, modified, removed and expired. Having all these events being passed around the cluster creates unnecessary load which can create problems in other nodes.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (ISPN-7207) Cache creation requires specific permissions when using security manager
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/ISPN-7207?page=com.atlassian.jira.plugin.... ]
Kabir Khan commented on ISPN-7207:
----------------------------------
IMO the aim should be to remove as many of the deployment permissions as possible from https://github.com/wildfly/wildfly/pull/9254
> Cache creation requires specific permissions when using security manager
> ------------------------------------------------------------------------
>
> Key: ISPN-7207
> URL: https://issues.jboss.org/browse/ISPN-7207
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Reporter: Paul Ferraro
> 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.InfinispanResourceRefTestCase -Dsecurity.manager}}
> {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 "ModuleClassLoader for Module "deployment.infinispan-resource-ref.war:main" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> 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:163)
> at org.infinispan.commons.util.ReflectionUtil.getClassForName(ReflectionUtil.java:319)
> at org.infinispan.commons.util.ReflectionUtil.toClassArray(ReflectionUtil.java:313)
> at org.infinispan.factories.AbstractComponentRegistry$Component.buildInjectionMethodsList(AbstractComponentRegistry.java:810)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:213)
> at org.infinispan.factories.ComponentRegistry.registerComponentInternal(ComponentRegistry.java:193)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:171)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:163)
> at org.infinispan.factories.ComponentRegistry.<init>(ComponentRegistry.java:79)
> ... 210 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months