[JBoss JIRA] (WFWIP-81) MP Health reports UP when there is port collision for port 8080
by Rostislav Svoboda (JIRA)
[ https://issues.jboss.org/browse/WFWIP-81?page=com.atlassian.jira.plugin.s... ]
Rostislav Svoboda commented on WFWIP-81:
----------------------------------------
Keeping OpenShift aside ...
Should MP Health report UP or DOWN in this scenario ? I'm still puzzled :)
> MP Health reports UP when there is port collision for port 8080
> ---------------------------------------------------------------
>
> Key: WFWIP-81
> URL: https://issues.jboss.org/browse/WFWIP-81
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP Health
> Reporter: Rostislav Svoboda
> Assignee: Jeff Mesnil
> Priority: Critical
>
> MP Health reports UP when there is port collision for port 8080.
> I have simple python app to acquire port 8080 and once it runs I start WF server
> {code}
> import SimpleHTTPServer
> import SocketServer
> PORT = 8080
> Handler = SimpleHTTPServer.SimpleHTTPRequestHandler
> httpd = SocketServer.TCPServer(("127.0.0.1", PORT), Handler)
> print "serving at port", PORT
> httpd.serve_forever()
> {code}
> WF reports Address already in use /127.0.0.1:8080, deployments are not deployed.
> Accessing http://localhost:9990/health/ reports "outcome":"UP"
> I think this is wrong and DOWN should be reported.
> Spec is misleading because it says {{A producer without health check procedures installed MUST returns positive overall outcome (i.e. HTTP 200)}} but it silently assumes server started correctly.
> I believe authors of the spec expected that if there is some trouble like port collision the server doesn't start, WildFly is a bit further as it allows to boot even if some services are not started properly.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-81) MP Health reports UP when there is port collision for port 8080
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFWIP-81?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry commented on WFWIP-81:
---------------------------------------
[~rsvoboda] I replied on CLOUD-2730.
We already have liveness and readiness probes on our images and MP Health is not replacing them. We are not relying on MP Health to deal with things like this.
We could in theory incorporate the existing checks the probes in our images already perform into the MP Health report and thus make it the sole source of checks, but I see no reason to do that in the first iteration.
> MP Health reports UP when there is port collision for port 8080
> ---------------------------------------------------------------
>
> Key: WFWIP-81
> URL: https://issues.jboss.org/browse/WFWIP-81
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP Health
> Reporter: Rostislav Svoboda
> Assignee: Jeff Mesnil
> Priority: Critical
>
> MP Health reports UP when there is port collision for port 8080.
> I have simple python app to acquire port 8080 and once it runs I start WF server
> {code}
> import SimpleHTTPServer
> import SocketServer
> PORT = 8080
> Handler = SimpleHTTPServer.SimpleHTTPRequestHandler
> httpd = SocketServer.TCPServer(("127.0.0.1", PORT), Handler)
> print "serving at port", PORT
> httpd.serve_forever()
> {code}
> WF reports Address already in use /127.0.0.1:8080, deployments are not deployed.
> Accessing http://localhost:9990/health/ reports "outcome":"UP"
> I think this is wrong and DOWN should be reported.
> Spec is misleading because it says {{A producer without health check procedures installed MUST returns positive overall outcome (i.e. HTTP 200)}} but it silently assumes server started correctly.
> I believe authors of the spec expected that if there is some trouble like port collision the server doesn't start, WildFly is a bit further as it allows to boot even if some services are not started properly.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-81) MP Health reports UP when there is port collision for port 8080
by Rostislav Svoboda (JIRA)
[ https://issues.jboss.org/browse/WFWIP-81?page=com.atlassian.jira.plugin.s... ]
Rostislav Svoboda commented on WFWIP-81:
----------------------------------------
[~brian.stansberry] this can be related to comment by [~tremes] added on https://issues.jboss.org/browse/CLOUD-2730
> MP Health reports UP when there is port collision for port 8080
> ---------------------------------------------------------------
>
> Key: WFWIP-81
> URL: https://issues.jboss.org/browse/WFWIP-81
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP Health
> Reporter: Rostislav Svoboda
> Assignee: Jeff Mesnil
> Priority: Critical
>
> MP Health reports UP when there is port collision for port 8080.
> I have simple python app to acquire port 8080 and once it runs I start WF server
> {code}
> import SimpleHTTPServer
> import SocketServer
> PORT = 8080
> Handler = SimpleHTTPServer.SimpleHTTPRequestHandler
> httpd = SocketServer.TCPServer(("127.0.0.1", PORT), Handler)
> print "serving at port", PORT
> httpd.serve_forever()
> {code}
> WF reports Address already in use /127.0.0.1:8080, deployments are not deployed.
> Accessing http://localhost:9990/health/ reports "outcome":"UP"
> I think this is wrong and DOWN should be reported.
> Spec is misleading because it says {{A producer without health check procedures installed MUST returns positive overall outcome (i.e. HTTP 200)}} but it silently assumes server started correctly.
> I believe authors of the spec expected that if there is some trouble like port collision the server doesn't start, WildFly is a bit further as it allows to boot even if some services are not started properly.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10777) Add WildFly Elytron / JASPI Integration Tests
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-10777?page=com.atlassian.jira.plugin... ]
Darran Lofthouse updated WFLY-10777:
------------------------------------
Summary: Add WildFly Elytron / JASPI Integration Tests (was: Add WildFly Elytron / JASPIC Integration Tests)
> Add WildFly Elytron / JASPI Integration Tests
> ---------------------------------------------
>
> Key: WFLY-10777
> URL: https://issues.jboss.org/browse/WFLY-10777
> Project: WildFly
> Issue Type: Task
> Components: Security, Test Suite
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 14.0.0.CR1
>
>
> The following key scenarios should be covered within the Elytron testsuite module: -
> * Pre-configured JASPIC
> In this case the SAMs are configured within the Elytron subsystem and applied at runtime to the web application.
> Two predominant modes to consider: -
> # Fully integrated, i.e. the Callbacks make use of the SecurityDomain for authentication.
> # Ad-Hoc Identity i.e. We still have a security domain but trust the SAM to establish an ad-hoc identity.
> * Programatically configured JASPIC
> During servlet initilisation the new JaspicConfigurationBuilder API can be used to dynamically register a configuration.
> Likely to need the same two modes.
> * Retrospective JASPIC
> In both the above cases the deployment can be deployed and either use Elytron HTTP authentication mechanisms or be unsecured, JASPIC for the deployment can be activated either via configuration or programatically and should take precedence over the existing authentication.
> * Programatic Authentication
> A servlet can use the authentication API on the HttpServletRequest and trigger authentication.
> * No SecurityDomain
> This one may not be as applicable at this stage but we should at some point support JASPIC being applied to a deployment not associated with any security domain, i.e. a new deployment on a clean install could programatically register a JASPIC configuration.
> Without any security domain the identity would only have relevance within the servlet container so establishing an ad-hoc identity is actually a better approach. Additionally this relies on no default being present in the default config.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10802) [EAT] : Download local testsuite dependencies needed for a specific subset without executing the test subset.
by Panagiotis Sotiropoulos (JIRA)
[ https://issues.jboss.org/browse/WFLY-10802?page=com.atlassian.jira.plugin... ]
Panagiotis Sotiropoulos moved JBEAP-15212 to WFLY-10802:
--------------------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-10802 (was: JBEAP-15212)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Test Suite
(was: Test Suite)
> [EAT] : Download local testsuite dependencies needed for a specific subset without executing the test subset.
> -------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10802
> URL: https://issues.jboss.org/browse/WFLY-10802
> Project: WildFly
> Issue Type: Task
> Components: Test Suite
> Reporter: Panagiotis Sotiropoulos
> Assignee: Panagiotis Sotiropoulos
>
> Download local testsuite dependencies needed for a specific subset without executing the test subset . This is used for dependency analysis with the list of ExternalDependencyPath of local dependencies that should be downloaded.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10736) Server in cluster hangs during start after previous kill
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-10736?page=com.atlassian.jira.plugin... ]
Miroslav Novak commented on WFLY-10736:
---------------------------------------
??I've looked at the logs - and there is a failure to start the singleton MDB service on node-1 (which doesn't seem to be used by this test?) - though we should file a separate issue for this, as eagerly started services needs to be more accommodating of cluster topology volatility on startup in the event that state-transfer is non-blocking.??
[~pferraro] [~tommaso-borgato] Is there already a jira for this?
> Server in cluster hangs during start after previous kill
> --------------------------------------------------------
>
> Key: WFLY-10736
> URL: https://issues.jboss.org/browse/WFLY-10736
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Reporter: Miroslav Novak
> Assignee: Paul Ferraro
> Priority: Blocker
> Labels: blocker-WF14
> Attachments: clusterKilTest.zip, logs-with-workaround.zip, node-1-thread-dump-before-kill-shutdown-sequence.txt, standalone-full-ha-1.xml, standalone-full-ha-2.xml
>
>
> There is regression in JGroups or Infinispan in one of our tests for fault tolerance of JMS bridges. However work on JMS bridge appears to be unrelated. Issue was hit in WF weekly run.
> Test Scenario:
> * There are two servers. InQueue is deployed on Node 1,
> * OutQueue is deployed on Node 2. Both servers are started.
> * Large byte messages are sent to InQueue deployed on Node 1. Bridge between servers/queues transfers messages from node 1 to node 2.
> * Node 1 is killed and started again.
> * All messages are received from OutQueue deployed on Node 2.
> Result:
> Node 1 does not start after kill and hangs. There is following exception logged in node 2:
> {code}
> :26:17,894 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN100000: Node node-1 joined the cluster
> 09:26:18,520 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN000094: Received new cluster view for channel ejb: [node-2|7] (2) [node-2, node-1]
> 09:26:18,521 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN100001: Node node-1 left the cluster
> 09:26:18,521 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN000094: Received new cluster view for channel ejb: [node-2|7] (2) [node-2, node-1]
> 09:26:18,522 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN100001: Node node-1 left the cluster
> 09:26:18,522 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN000094: Received new cluster view for channel ejb: [node-2|7] (2) [node-2, node-1]
> 09:26:18,522 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN100001: Node node-1 left the cluster
> 09:26:18,522 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN000094: Received new cluster view for channel ejb: [node-2|7] (2) [node-2, node-1]
> 09:26:18,523 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN100001: Node node-1 left the cluster
> 09:26:18,868 INFO [org.infinispan.CLUSTER] (remote-thread--p5-t2) ISPN000310: Starting cluster-wide rebalance for cache default, topology CacheTopology{id=17, phase=READ_OLD_WRITE_ALL, rebalanceId=6, currentCH=ReplicatedConsistentHash{ns = 256, owners = (2)[node-2: 122, node-1: 134]}, pendingCH=ReplicatedConsistentHash{ns = 256, owners = (3)[node-2: 84, node-1: 90, node-1: 82]}, unionCH=null, actualMembers=[node-2, node-1, node-1], persistentUUIDs=[12443bfb-e88a-46f3-919e-9213bf38ce19, 2873237f-d881-463f-8a5a-940bf1d764e5, a05ea8af-a83b-42a9-b937-dc2da1cae6d1]}
> 09:26:18,869 INFO [org.infinispan.CLUSTER] (remote-thread--p5-t2) [Context=default][Scope=node-2]ISPN100002: Started rebalance with topology id 17
> 09:26:18,870 INFO [org.infinispan.CLUSTER] (transport-thread--p14-t5) [Context=default][Scope=node-2]ISPN100003: Node node-2 finished rebalance phase with topology id 17
> 09:26:18,981 INFO [org.infinispan.CLUSTER] (remote-thread--p5-t2) [Context=default][Scope=node-1]ISPN100003: Node node-1 finished rebalance phase with topology id 17
> 09:27:18,530 WARN [org.infinispan.topology.ClusterTopologyManagerImpl] (transport-thread--p15-t4) ISPN000197: Error updating cluster member list: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
> Suppressed: java.util.concurrent.ExecutionException: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357) [rt.jar:1.8.0_131]
> at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1915) [rt.jar:1.8.0_131]
> at org.infinispan.util.concurrent.CompletableFutures.await(CompletableFutures.java:82)
> at org.infinispan.remoting.transport.Transport.invokeRemotely(Transport.java:71)
> at org.infinispan.topology.ClusterTopologyManagerImpl.confirmMembersAvailable(ClusterTopologyManagerImpl.java:540)
> at org.infinispan.topology.ClusterTopologyManagerImpl.updateCacheMembers(ClusterTopologyManagerImpl.java:523)
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleClusterView(ClusterTopologyManagerImpl.java:334)
> at org.infinispan.topology.ClusterTopologyManagerImpl.access$500(ClusterTopologyManagerImpl.java:85)
> at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener.lambda$handleViewChange$0(ClusterTopologyManagerImpl.java:745)
> at org.infinispan.executors.LimitedExecutor.runTasks(LimitedExecutor.java:144)
> at org.infinispan.executors.LimitedExecutor.access$100(LimitedExecutor.java:33)
> at org.infinispan.executors.LimitedExecutor$Runner.run(LimitedExecutor.java:174)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> at org.wildfly.clustering.service.concurrent.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:47)
> ... 1 more
> Caused by: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> ... 1 more
> [CIRCULAR REFERENCE:java.util.concurrent.ExecutionException: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1]
> 09:27:18,530 WARN [org.infinispan.topology.ClusterTopologyManagerImpl] (transport-thread--p16-t4) ISPN000197: Error updating cluster member list: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
> Suppressed: java.util.concurrent.ExecutionException: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357) [rt.jar:1.8.0_131]
> at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1915) [rt.jar:1.8.0_131]
> at org.infinispan.util.concurrent.CompletableFutures.await(CompletableFutures.java:82)
> at org.infinispan.remoting.transport.Transport.invokeRemotely(Transport.java:71)
> at org.infinispan.topology.ClusterTopologyManagerImpl.confirmMembersAvailable(ClusterTopologyManagerImpl.java:540)
> at org.infinispan.topology.ClusterTopologyManagerImpl.updateCacheMembers(ClusterTopologyManagerImpl.java:523)
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleClusterView(ClusterTopologyManagerImpl.java:334)
> at org.infinispan.topology.ClusterTopologyManagerImpl.access$500(ClusterTopologyManagerImpl.java:85)
> at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener.lambda$handleViewChange$0(ClusterTopologyManagerImpl.java:745)
> at org.infinispan.executors.LimitedExecutor.runTasks(LimitedExecutor.java:144)
> at org.infinispan.executors.LimitedExecutor.access$100(LimitedExecutor.java:33)
> at org.infinispan.executors.LimitedExecutor$Runner.run(LimitedExecutor.java:174)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> at org.wildfly.clustering.service.concurrent.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:47)
> ... 1 more
> Caused by: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> ... 1 more
> [CIRCULAR REFERENCE:java.util.concurrent.ExecutionException: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1]
> {code}
> There is default JGroups udp stack configured which is used by Infinispan. Both of the servers (jgroups udp) are bound to 127.0.0.1. Node 2 has port offset 1000.
> Attaching thread dump from node 1 when it hangs during start.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-2844) Show contextual (right click) menus
by Juraj Soltes (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2844?page=com.atlassian.jira.plugi... ]
Juraj Soltes updated DROOLS-2844:
---------------------------------
Tester: Juraj Soltes
> Show contextual (right click) menus
> -----------------------------------
>
> Key: DROOLS-2844
> URL: https://issues.jboss.org/browse/DROOLS-2844
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Gabriele Cardosi
> Assignee: Gabriele Cardosi
> Labels: ScenarioSimulation
>
> Show different contextual (right click) menus depending on click position (header/first cell in row/other cell in row).
> For this task menu should not have any behaviour - by default the menu should be hided when right clicked.
> For this task it is important to just show different menu/menu items depending on the position clicked.
> Implementation should be independent on the current context (Scenario Simulation) i.e. it should rely on common components (GWT/Errai/Uberfire) and should be re-usable
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-3677) get-provider-points return /profile addresses for host level resources
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3677?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFCORE-3677:
------------------------------------------
[~jmesnil] Does this make sense to come your way? Although reproduced in the Elytron subsystem which can be used across all process types this is really more a general capability resolution issue.
> get-provider-points return /profile addresses for host level resources
> ----------------------------------------------------------------------
>
> Key: WFCORE-3677
> URL: https://issues.jboss.org/browse/WFCORE-3677
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Management
> Reporter: Claudio Miranda
> Assignee: Jeff Mesnil
> Priority: Minor
>
> key-manager resource at /host=master/subsystem=elytron/key-manager=*
> contains the "key-store" attribute, which has a "capability-reference" => "org.wildfly.security.key-store"
> get-provider-points returns /profile addresses that should not be a valid reference for a host level resource
> {code}
> /host=master/core-service=capability-registry:get-provider-points(name="org.wildfly.security.key-store")
> {
> "outcome" => "success",
> "result" => [
> "/host=master/subsystem=elytron/key-store=*",
> "/host=master/subsystem=elytron/ldap-key-store=*",
> "/host=master/subsystem=elytron/filtering-key-store=*",
> "/profile=*/subsystem=elytron/key-store=*",
> "/profile=*/subsystem=elytron/ldap-key-store=*",
> "/profile=*/subsystem=elytron/filtering-key-store=*",
> "/profile=*/subsystem=security/elytron-key-store=*",
> "/profile=*/subsystem=security/elytron-trust-store=*"
> ]
> }
> {code}
> A test case
> {code}
> /profile=full/subsystem=elytron/key-store=ks_full:add(credential-reference={clear-text=senha},type=JKS)
> /host=master/subsystem=elytron/key-manager=my_km:add(key-store=ks_full,credential-reference={clear-text=senha})
> {
> "outcome" => "failed",
> "result" => {},
> "failure-description" => {"host-failure-descriptions" => {"master" => "WFLYCTL0369: Required capabilities are not available:
> org.wildfly.security.key-store.ks_full in context 'host'; Possible registration points for this capability:
> /host=master/subsystem=elytron/key-store=*
> /host=master/subsystem=elytron/ldap-key-store=*
> /host=master/subsystem=elytron/filtering-key-store=*
> /profile=*/subsystem=elytron/key-store=*
> /profile=*/subsystem=elytron/ldap-key-store=*
> /profile=*/subsystem=elytron/filtering-key-store=*
> /profile=*/subsystem=security/elytron-key-store=*
> /profile=*/subsystem=security/elytron-trust-store=*"}},
> "rolled-back" => true
> }
> {code}
> The returned addresses in the error message should contains only valid addresses.
> side note: CLI code completion works correctly in not showing resources from /profile addresses.
> /host=master/subsystem=elytron/key-manager=my_km:add(key-store=<tab>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months