[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:
----------------------------------
Fix Version/s: 9.0.0.Alpha3
> 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)
9 years, 9 months
[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)
9 years, 9 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)
9 years, 9 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)
9 years, 9 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)
9 years, 9 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)
9 years, 9 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)
9 years, 9 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)
9 years, 9 months