[JBoss JIRA] (ISPN-6649) org.infinispan.server.hotrod.HotRodSingleClusteredNonLoopbackTest.createBeforeClass fail on Windows
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-6649?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero updated ISPN-6649:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> org.infinispan.server.hotrod.HotRodSingleClusteredNonLoopbackTest.createBeforeClass fail on Windows
> ----------------------------------------------------------------------------------------------------
>
> Key: ISPN-6649
> URL: https://issues.jboss.org/browse/ISPN-6649
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Server
> Reporter: Anna Manukyan
> Assignee: Tristan Tarrant
> Fix For: 9.0.0.Alpha3
>
>
> The {{ org.infinispan.server.hotrod.HotRodSingleClusteredNonLoopbackTest.createBeforeClass}} fails on withdows with the following exception:
> {code}
> java.util.NoSuchElementException
> at java.net.NetworkInterface$1checkedAddresses.nextElement(NetworkInterface.java:144)
> at java.net.NetworkInterface$1checkedAddresses.nextElement(NetworkInterface.java:112)
> at org.infinispan.server.hotrod.HotRodSingleClusteredNonLoopbackTest.createBeforeClass(HotRodSingleClusteredNonLoopbackTest.scala:42)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
> at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:564)
> at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:213)
> at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:138)
> at org.testng.internal.TestMethodWorker.invokeBeforeClassMethods(TestMethodWorker.java:175)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:107)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:348)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:38)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:382)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (ISPN-6742) Console shows cache available and disabled at the same time
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-6742?page=com.atlassian.jira.plugin.... ]
Ryan Emerson resolved ISPN-6742.
--------------------------------
Fix Version/s: 9.0.0.Alpha3
Resolution: Done
> Console shows cache available and disabled at the same time
> -----------------------------------------------------------
>
> Key: ISPN-6742
> URL: https://issues.jboss.org/browse/ISPN-6742
> Project: Infinispan
> Issue Type: Bug
> Components: Console
> Affects Versions: 8.2.2.Final
> Reporter: Jiří Holuša
> Assignee: Vladimir Blagojevic
> Fix For: 9.0.0.Alpha3
>
> Attachments: attachment.png
>
>
> Page: go to cache detail and click "Actions" -> "Disable".
> After confirmation, the cache status is still "Available", but new red box appears with text "Disabled", see the attachment. This doesn't seem to me very intuitive, if the cache is disabled, it should be IMO unavailable and this should be also reflected in the caches list.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (ISPN-6747) Disabled buttons in dropdown menus are still functional
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-6747?page=com.atlassian.jira.plugin.... ]
Ryan Emerson resolved ISPN-6747.
--------------------------------
Fix Version/s: 9.0.0.Alpha3
Resolution: Done
> Disabled buttons in dropdown menus are still functional
> -------------------------------------------------------
>
> Key: ISPN-6747
> URL: https://issues.jboss.org/browse/ISPN-6747
> Project: Infinispan
> Issue Type: Bug
> Components: Console
> Affects Versions: 8.2.2.Final
> Reporter: Jiří Holuša
> Assignee: Vladimir Blagojevic
> Fix For: 9.0.0.Alpha3
>
>
> For example, on cache detail page, in "Actions" dropdown menu, if cache is enabled than the "Enable" option is disabled. Currently, the button is grey, but when you try clicking on it, it will execute the operation anyway. Please note that this affects every button in the dropdown menus, more specifically every <a> link, because you cannot use disabled="disabled" (therefore ng-disabled) on the <a> link as you do with the <button> elements.
> I found a root cause and also a fix, however, I wasn't able to find a place, where to modify the CSS style, since the hierarchy is quite complicated. To fix the issue, you have to add
> {code}
> li.disabled {
> cursor: not-allowed;
> }
> {code}
> to the CSS of the directly encapsulating <li>, and following
> {code}
> li.disabled a {
> pointer-events: none;
> }
> {code}
> to the CSS of the disabled <a> tag. The reason to split this two is that the cursor and pointer-events don't work well together and we want to have both "not-allowed" cursor and not-clickable link. See https://github.com/twbs/bootstrap/issues/16088 for details.
> I would be happy to implement the fix and send a PR, just give me a hint which one is the CSS style to be modified. I essentially need to modify the CSS on the URL http://localhost:9990/console/built_components/patternfly/dist/css/patter... . Or should it be overwritten somewhere else?
> I've tested the fix via modifying the CSS directly in the browser on the fly, so I can confirm that it works.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (ISPN-6747) Disabled buttons in dropdown menus are still functional
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-6747?page=com.atlassian.jira.plugin.... ]
Ryan Emerson updated ISPN-6747:
-------------------------------
Status: Open (was: New)
> Disabled buttons in dropdown menus are still functional
> -------------------------------------------------------
>
> Key: ISPN-6747
> URL: https://issues.jboss.org/browse/ISPN-6747
> Project: Infinispan
> Issue Type: Bug
> Components: Console
> Affects Versions: 8.2.2.Final
> Reporter: Jiří Holuša
> Assignee: Vladimir Blagojevic
> Fix For: 9.0.0.Alpha3
>
>
> For example, on cache detail page, in "Actions" dropdown menu, if cache is enabled than the "Enable" option is disabled. Currently, the button is grey, but when you try clicking on it, it will execute the operation anyway. Please note that this affects every button in the dropdown menus, more specifically every <a> link, because you cannot use disabled="disabled" (therefore ng-disabled) on the <a> link as you do with the <button> elements.
> I found a root cause and also a fix, however, I wasn't able to find a place, where to modify the CSS style, since the hierarchy is quite complicated. To fix the issue, you have to add
> {code}
> li.disabled {
> cursor: not-allowed;
> }
> {code}
> to the CSS of the directly encapsulating <li>, and following
> {code}
> li.disabled a {
> pointer-events: none;
> }
> {code}
> to the CSS of the disabled <a> tag. The reason to split this two is that the cursor and pointer-events don't work well together and we want to have both "not-allowed" cursor and not-clickable link. See https://github.com/twbs/bootstrap/issues/16088 for details.
> I would be happy to implement the fix and send a PR, just give me a hint which one is the CSS style to be modified. I essentially need to modify the CSS on the URL http://localhost:9990/console/built_components/patternfly/dist/css/patter... . Or should it be overwritten somewhere else?
> I've tested the fix via modifying the CSS directly in the browser on the fly, so I can confirm that it works.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (ISPN-6747) Disabled buttons in dropdown menus are still functional
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-6747?page=com.atlassian.jira.plugin.... ]
Ryan Emerson updated ISPN-6747:
-------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan-management-console/pull/110
> Disabled buttons in dropdown menus are still functional
> -------------------------------------------------------
>
> Key: ISPN-6747
> URL: https://issues.jboss.org/browse/ISPN-6747
> Project: Infinispan
> Issue Type: Bug
> Components: Console
> Affects Versions: 8.2.2.Final
> Reporter: Jiří Holuša
> Assignee: Vladimir Blagojevic
> Fix For: 9.0.0.Alpha3
>
>
> For example, on cache detail page, in "Actions" dropdown menu, if cache is enabled than the "Enable" option is disabled. Currently, the button is grey, but when you try clicking on it, it will execute the operation anyway. Please note that this affects every button in the dropdown menus, more specifically every <a> link, because you cannot use disabled="disabled" (therefore ng-disabled) on the <a> link as you do with the <button> elements.
> I found a root cause and also a fix, however, I wasn't able to find a place, where to modify the CSS style, since the hierarchy is quite complicated. To fix the issue, you have to add
> {code}
> li.disabled {
> cursor: not-allowed;
> }
> {code}
> to the CSS of the directly encapsulating <li>, and following
> {code}
> li.disabled a {
> pointer-events: none;
> }
> {code}
> to the CSS of the disabled <a> tag. The reason to split this two is that the cursor and pointer-events don't work well together and we want to have both "not-allowed" cursor and not-clickable link. See https://github.com/twbs/bootstrap/issues/16088 for details.
> I would be happy to implement the fix and send a PR, just give me a hint which one is the CSS style to be modified. I essentially need to modify the CSS on the URL http://localhost:9990/console/built_components/patternfly/dist/css/patter... . Or should it be overwritten somewhere else?
> I've tested the fix via modifying the CSS directly in the browser on the fly, so I can confirm that it works.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (ISPN-6755) Functional API's metadata support is unusable when using CacheLoaders
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-6755?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-6755:
----------------------------------------
Moved to ISPN-6773 and ISPN-6756.
> Functional API's metadata support is unusable when using CacheLoaders
> ---------------------------------------------------------------------
>
> Key: ISPN-6755
> URL: https://issues.jboss.org/browse/ISPN-6755
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 9.0.0.Alpha2
> Reporter: Krzysztof Sobolewski
> Assignee: Krzysztof Sobolewski
>
> These are the meta parameters used by the Functional API. They are created and updated when we call EntryView.WriteEntryView.set(value, params...), but this is not the only source of these parameters. The other is the cache loaders: the return value of CacheLoader.load() is a MarshalledEntry that contains three values: the key, the value and the metadata. This is a place where the implementations will want to inject information like the lifetime (for expiration). The only way to do that currently is to create a custom implementation of the Metadata interface, but that won't work, partialy because the Functional API is unfinished in these darker, dustier corners. So when we call MetaParam.Lookup.findMetaParam(Class<T>), the only supported Metadata implementation is the MetaParamsInternalMetadata (which external classes can't create because all the constructors of MetaParams are package-private), and there is a TODO to add interoperability support.
> The PR I'm about to send fixes this by just allowing external classes to instantiate MetaParams so that they can create MetaParamsInternalMetadata which in turn can be returned from CacheLoader.load(). But this is just a RFC, as usual.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (ISPN-6755) Functional API's metadata support is unusable when using CacheLoaders
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-6755?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño resolved ISPN-6755.
------------------------------------
Assignee: Krzysztof Sobolewski
Resolution: Won't Fix
> Functional API's metadata support is unusable when using CacheLoaders
> ---------------------------------------------------------------------
>
> Key: ISPN-6755
> URL: https://issues.jboss.org/browse/ISPN-6755
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 9.0.0.Alpha2
> Reporter: Krzysztof Sobolewski
> Assignee: Krzysztof Sobolewski
>
> These are the meta parameters used by the Functional API. They are created and updated when we call EntryView.WriteEntryView.set(value, params...), but this is not the only source of these parameters. The other is the cache loaders: the return value of CacheLoader.load() is a MarshalledEntry that contains three values: the key, the value and the metadata. This is a place where the implementations will want to inject information like the lifetime (for expiration). The only way to do that currently is to create a custom implementation of the Metadata interface, but that won't work, partialy because the Functional API is unfinished in these darker, dustier corners. So when we call MetaParam.Lookup.findMetaParam(Class<T>), the only supported Metadata implementation is the MetaParamsInternalMetadata (which external classes can't create because all the constructors of MetaParams are package-private), and there is a TODO to add interoperability support.
> The PR I'm about to send fixes this by just allowing external classes to instantiate MetaParams so that they can create MetaParamsInternalMetadata which in turn can be returned from CacheLoader.load(). But this is just a RFC, as usual.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (ISPN-6760) Comparing a sum of an attribute fails with ClassCastException
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-6760?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-6760:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Comparing a sum of an attribute fails with ClassCastException
> -------------------------------------------------------------
>
> Key: ISPN-6760
> URL: https://issues.jboss.org/browse/ISPN-6760
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 9.0.0.Alpha2
> Reporter: Jakub Markos
> Assignee: Adrian Nistor
> Fix For: 9.0.0.Alpha3, 9.0.0.Final, 8.2.3.Final
>
>
> The following query (in the context of QueryDslConditionsTest)
> {code}
> public void testSum2() throws Exception {
> QueryFactory qf = getQueryFactory();
> Query q = qf.from(getModelFactory().getUserImplClass())
> .select(sum("age"))
> .groupBy("name")
> .having(sum("age")).gt(50000).toBuilder()
> .build();
> List<Object[]> list = q.list();
> }
> {code}
> fails with
> {code}
> java.lang.ClassCastException: java.lang.Long cannot be cast to java.lang.Integer
> at java.lang.Integer.compareTo(Integer.java:52)
> at org.infinispan.objectfilter.impl.util.Interval.contains(Interval.java:92)
> at org.infinispan.objectfilter.impl.predicateindex.IntervalCondition.match(IntervalCondition.java:19)
> at org.infinispan.objectfilter.impl.predicateindex.IntervalCondition.match(IntervalCondition.java:9)
> at org.infinispan.objectfilter.impl.predicateindex.Predicate.match(Predicate.java:37)
> at org.infinispan.objectfilter.impl.predicateindex.Predicates.notifyMatchingSubscribers(Predicates.java:118)
> at org.infinispan.objectfilter.impl.predicateindex.AttributeNode.processValue(AttributeNode.java:114)
> at org.infinispan.objectfilter.impl.predicateindex.RowMatcherEvalContext.processAttributes(RowMatcherEvalContext.java:30)
> at org.infinispan.objectfilter.impl.predicateindex.MatcherEvalContext.process(MatcherEvalContext.java:129)
> at org.infinispan.objectfilter.impl.ObjectFilterImpl.filter(ObjectFilterImpl.java:213)
> at org.infinispan.query.dsl.embedded.impl.HybridQuery$1.updateNext(HybridQuery.java:80)
> at org.infinispan.query.dsl.embedded.impl.HybridQuery$1.hasNext(HybridQuery.java:59)
> at org.infinispan.query.dsl.embedded.impl.BaseEmbeddedQuery.listInternal(BaseEmbeddedQuery.java:66)
> at org.infinispan.query.dsl.embedded.impl.BaseEmbeddedQuery.list(BaseEmbeddedQuery.java:57)
> at org.infinispan.query.dsl.embedded.impl.DelegatingQuery.list(DelegatingQuery.java:49)
> at org.infinispan.query.dsl.embedded.QueryDslConditionsTest.testSum2(QueryDslConditionsTest.java:2001)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:348)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:38)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:382)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> Using {code}.having(sum("age")).gt(new Long(50000)).toBuilder(){code} doesn't have any effect.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (ISPN-6773) Metadata updates get dropped with Functional API
by Krzysztof Sobolewski (JIRA)
[ https://issues.jboss.org/browse/ISPN-6773?page=com.atlassian.jira.plugin.... ]
Krzysztof Sobolewski updated ISPN-6773:
---------------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/4412, https://github.com/infinispan/infinispan/pull/4413
> Metadata updates get dropped with Functional API
> ------------------------------------------------
>
> Key: ISPN-6773
> URL: https://issues.jboss.org/browse/ISPN-6773
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.0.0.Alpha2, 8.2.2.Final
> Reporter: Krzysztof Sobolewski
>
> I have a CacheLoader that injects EmbeddedMetadata so that I can specify the lifetime of the newly loaded entry. EmbeddedMetadata is supposed to be used when only lifespan or maxIdle are required (I only need lifespan); this works because the lifespan (and maxIdle) information is copied into the internal node itself - no extra Metadata object is allocated.
> The InternalNode has several implementations, each used for the different combination of lifespan and maxIdle. Let's proceed with MortalCacheEntry (lifespan only). Its metadata-aware sibling is MetadataMortalCacheEntry. Each of those has a special code path in EntryWrappingInterceptor for updates of metadata. This path is chosen not based on the type of the InternalEntry (so that it can also work for new entries, where there's no internal entry object yet) but instead the decision is made in InternalEntryFactoryImpl.isStoreMetadata() based on the type of the Metadata object - if it returns true, then the path for MetadataMortalCacheEntry is used. This path then inspects the actual type of the internal entry object so that can update it accordingly.
> Enter Functional API.
> After I return EmbeddedMetadata from the CacheLoader, the expiration parameters are updated just fine - the EmbeddedMetadata is recognized and a MortalCacheEntry is created with the expected lifespan. Then, when we use {code:java}EntryView.WriteEntryView.set(value, params...){code} to update the metadata (which is the only way to do that in Functional API), the Metadata object in the entry gets replaced with an instance of MetaParamsInternalMetadata. This makes isStoreMetadata() return true (because the Metadata object is no longer EmbeddedMetadata). EntryWrappingInterceptor then goes into the metadata-aware code path where MortalCacheEntry is not handled (MetadataMortalCacheEntry is instead) and the metadata update is not performed at all.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months