[JBoss JIRA] (WFCORE-2691) Elytron modifiable realms should show existing identities in subsystem
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2691?page=com.atlassian.jira.plugi... ]
Jan Kalina edited comment on WFCORE-2691 at 4/20/17 12:12 PM:
--------------------------------------------------------------
I see only placeholder: {{"core-address" => undefined}}
So it should be possible to eliminate it in controller.
Should be sufficient that *Identity* resource is runtime to not list it on {{include-runtime=false}} ?
Or the Realm resource would have to be runtime to archieve it? (which we dont want to)
was (Author: honza889):
I see only placeholder: {{"core-address" => undefined}}
So it should be possible to eliminate it in controller.
> Elytron modifiable realms should show existing identities in subsystem
> ----------------------------------------------------------------------
>
> Key: WFCORE-2691
> URL: https://issues.jboss.org/browse/WFCORE-2691
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Beta15
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
> Labels: filesystem-realm, security-realm
>
> Elytron {{filesystem-realm}} should load existing identities from file system. The steps to reproduce results in:
> {noformat}
> [standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=realm/identity=user:read-identity
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0216: Management resource '[
> (\"subsystem\" => \"elytron\"),
> (\"filesystem-realm\" => \"realm\"),
> (\"identity\" => \"user\")
> ]' not found",
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=realm/identity=user:add
> {
> "outcome" => "failed",
> "failure-description" => "WFLYELY01000: Identity with name [user] already exists.",
> "rolled-back" => true
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2691) Elytron modifiable realms should show existing identities in subsystem
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2691?page=com.atlassian.jira.plugi... ]
Jan Kalina commented on WFCORE-2691:
------------------------------------
I see only placeholder: {{"core-address" => undefined}}
So it should be possible to eliminate it in controller.
> Elytron modifiable realms should show existing identities in subsystem
> ----------------------------------------------------------------------
>
> Key: WFCORE-2691
> URL: https://issues.jboss.org/browse/WFCORE-2691
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Beta15
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
> Labels: filesystem-realm, security-realm
>
> Elytron {{filesystem-realm}} should load existing identities from file system. The steps to reproduce results in:
> {noformat}
> [standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=realm/identity=user:read-identity
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0216: Management resource '[
> (\"subsystem\" => \"elytron\"),
> (\"filesystem-realm\" => \"realm\"),
> (\"identity\" => \"user\")
> ]' not found",
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=realm/identity=user:add
> {
> "outcome" => "failed",
> "failure-description" => "WFLYELY01000: Identity with name [user] already exists.",
> "rolled-back" => true
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2691) Elytron modifiable realms should show existing identities in subsystem
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2691?page=com.atlassian.jira.plugi... ]
Jan Kalina updated WFCORE-2691:
-------------------------------
Labels: filesystem-realm security-realm (was: eap71_beta filesystem-realm security-realm)
> Elytron modifiable realms should show existing identities in subsystem
> ----------------------------------------------------------------------
>
> Key: WFCORE-2691
> URL: https://issues.jboss.org/browse/WFCORE-2691
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Beta15
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
> Labels: filesystem-realm, security-realm
>
> Elytron {{filesystem-realm}} should load existing identities from file system. The steps to reproduce results in:
> {noformat}
> [standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=realm/identity=user:read-identity
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0216: Management resource '[
> (\"subsystem\" => \"elytron\"),
> (\"filesystem-realm\" => \"realm\"),
> (\"identity\" => \"user\")
> ]' not found",
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=realm/identity=user:add
> {
> "outcome" => "failed",
> "failure-description" => "WFLYELY01000: Identity with name [user] already exists.",
> "rolled-back" => true
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ELY-1095) Elytron modifiable realms should show existing identities in subsystem
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1095?page=com.atlassian.jira.plugin.s... ]
Jan Kalina moved WFCORE-2703 to ELY-1095:
-----------------------------------------
Project: WildFly Elytron (was: WildFly Core)
Key: ELY-1095 (was: WFCORE-2703)
Component/s: Realms
(was: Security)
Affects Version/s: 1.1.0.Beta37
(was: 3.0.0.Beta15)
> Elytron modifiable realms should show existing identities in subsystem
> ----------------------------------------------------------------------
>
> Key: ELY-1095
> URL: https://issues.jboss.org/browse/ELY-1095
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Affects Versions: 1.1.0.Beta37
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
> Labels: eap71_beta, filesystem-realm, security-realm
>
> Elytron {{filesystem-realm}} should load existing identities from file system. The steps to reproduce results in:
> {noformat}
> [standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=realm/identity=user:read-identity
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0216: Management resource '[
> (\"subsystem\" => \"elytron\"),
> (\"filesystem-realm\" => \"realm\"),
> (\"identity\" => \"user\")
> ]' not found",
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=realm/identity=user:add
> {
> "outcome" => "failed",
> "failure-description" => "WFLYELY01000: Identity with name [user] already exists.",
> "rolled-back" => true
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ELY-1095) Elytron modifiable realms should show existing identities in subsystem
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1095?page=com.atlassian.jira.plugin.s... ]
Jan Kalina updated ELY-1095:
----------------------------
Labels: filesystem-realm security-realm (was: eap71_beta filesystem-realm security-realm)
> Elytron modifiable realms should show existing identities in subsystem
> ----------------------------------------------------------------------
>
> Key: ELY-1095
> URL: https://issues.jboss.org/browse/ELY-1095
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Affects Versions: 1.1.0.Beta37
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
> Labels: filesystem-realm, security-realm
>
> Elytron {{filesystem-realm}} should load existing identities from file system. The steps to reproduce results in:
> {noformat}
> [standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=realm/identity=user:read-identity
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0216: Management resource '[
> (\"subsystem\" => \"elytron\"),
> (\"filesystem-realm\" => \"realm\"),
> (\"identity\" => \"user\")
> ]' not found",
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=realm/identity=user:add
> {
> "outcome" => "failed",
> "failure-description" => "WFLYELY01000: Identity with name [user] already exists.",
> "rolled-back" => true
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2703) Elytron modifiable realms should show existing identities in subsystem
by Jan Kalina (JIRA)
Jan Kalina created WFCORE-2703:
----------------------------------
Summary: Elytron modifiable realms should show existing identities in subsystem
Key: WFCORE-2703
URL: https://issues.jboss.org/browse/WFCORE-2703
Project: WildFly Core
Issue Type: Bug
Components: Security
Affects Versions: 3.0.0.Beta15
Reporter: Jan Kalina
Assignee: Jan Kalina
Priority: Blocker
Elytron {{filesystem-realm}} should load existing identities from file system. The steps to reproduce results in:
{noformat}
[standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=realm/identity=user:read-identity
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0216: Management resource '[
(\"subsystem\" => \"elytron\"),
(\"filesystem-realm\" => \"realm\"),
(\"identity\" => \"user\")
]' not found",
"rolled-back" => true
}
[standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=realm/identity=user:add
{
"outcome" => "failed",
"failure-description" => "WFLYELY01000: Identity with name [user] already exists.",
"rolled-back" => true
}
{noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2478) Credential store, during creation of CS backed keystore is not created on filesystem.
by Yeray Borges (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2478?page=com.atlassian.jira.plugi... ]
Yeray Borges reassigned WFCORE-2478:
------------------------------------
Assignee: Yeray Borges (was: Darran Lofthouse)
> Credential store, during creation of CS backed keystore is not created on filesystem.
> -------------------------------------------------------------------------------------
>
> Key: WFCORE-2478
> URL: https://issues.jboss.org/browse/WFCORE-2478
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Martin Choma
> Assignee: Yeray Borges
> Priority: Critical
>
> Keystore is created after writing secret key into it. So instead of "write alias" operation it is more "write alias and create backed keystore if not exists yet" operation.
> How to reproduce:
> - create credential store from scratch
> {code}
> [standalone@localhost:9990 /] /subsystem=elytron/credential-store=myCredStore:add(uri="cr-store://test/myCredStore.jceks?create=true", credential-reference={clear-text=pass123}, relative-to=jboss.server.config.dir)
> {"outcome" => "success"}
> {code}
> - myCredStore.jceks does not exists on FS (I would expect it will be created)
> {code}
> [standalone@localhost:9990 /] /subsystem=elytron/credential-store=myCredStore/alias=myAlias:add(secret-value=secret)
> {"outcome" => "success"}
> {code}
> - myCredStore.jceks exists on FS
> Setting high priority as lack of this behaviour can lead to more complex problems in multiprocess scenarios (e.g domain mode)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8618) BootstrapContext wasn't found when reloading server with distributed workmanager
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/WFLY-8618?page=com.atlassian.jira.plugin.... ]
Stefano Maestri moved JBEAP-10472 to WFLY-8618:
-----------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8618 (was: JBEAP-10472)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: JCA
(was: JCA)
Affects Version/s: (was: 7.1.0.DR13)
> BootstrapContext wasn't found when reloading server with distributed workmanager
> --------------------------------------------------------------------------------
>
> Key: WFLY-8618
> URL: https://issues.jboss.org/browse/WFLY-8618
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Reporter: Stefano Maestri
> Assignee: Stefano Maestri
> Labels: KK-DR17
>
> On single node, set up distributed workmanager:
> {code}
> /subsystem=jca/distributed-workmanager=newdwm:add(name=newdwm)
> /subsystem=jca/distributed-workmanager=newdwm/short-running-threads=newdwm:add(queue-length=10,max-threads=10)
> /subsystem=jca/bootstrap-context=customContext1:add(name=customContext1,workmanager=newdwm)
> run-batch
> reload
> {code}
> We should now have our distributed workmanager correctly linked with the {{customContext1}}. When we now deploy the {{dwmtest.ear}} (attached, same as in JBEAP-9422), everything is OK and we can access the admin objects, schedule work, etc.
> However, when the server is reloaded or restarted, the deployment fails and the following exception is thrown:
> {code}
> 15:03:59,758 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 67) MSC000001: Failed to start service jboss.ra.deployer."dwmtest.ear#dwm.rar": org.jboss.msc.service.StartException in service jboss.ra.deployer."dwmtest.ear#dwm.rar": WFLYJCA0046: Failed to start RA deployment [dwmtest.ear#dwm.rar]
> at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterDeploymentService$1.run(ResourceAdapterDeploymentService.java:174)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: org.jboss.jca.deployers.common.DeployException: IJ020051: Unable to start org.jboss.as.test.integration.jca.rar.DistributedResourceAdapter1
> at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.startContext(AbstractResourceAdapterDeployer.java:343)
> at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.createObjectsAndInjectValue(AbstractResourceAdapterDeployer.java:2009)
> at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterDeploymentService$WildFLyRaDeployer.doDeploy(ResourceAdapterDeploymentService.java:226)
> at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterDeploymentService.start(ResourceAdapterDeploymentService.java:124)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> 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)
> Caused by: java.lang.IllegalStateException: The BootstrapContext couldn't be created: customContext1
> at org.jboss.jca.core.bootstrapcontext.BootstrapContextCoordinator.createBootstrapContext(BootstrapContextCoordinator.java:215)
> at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.startContext(AbstractResourceAdapterDeployer.java:331)
> ... 8 more
> Caused by: java.lang.IllegalArgumentException: The BootstrapContext wasn't found: customContext1
> at org.jboss.jca.core.bootstrapcontext.BootstrapContextCoordinator.createBootstrapContext(BootstrapContextCoordinator.java:196)
> ... 9 more
> {code}
> If {{dwmtest.ear}} is deployed without first setting up {{customContext1}}, the exact same exception is thrown (though it is expected and valid in that case).
> Note that the attached deployment requires the context to be {{customContext1}} as defined in its {{ironjacamar.xml}}.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8617) Distributed workmanager fails to obtain view
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/WFLY-8617?page=com.atlassian.jira.plugin.... ]
Stefano Maestri moved JBEAP-10471 to WFLY-8617:
-----------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8617 (was: JBEAP-10471)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: JCA
(was: JCA)
Affects Version/s: (was: 7.1.0.DR13)
> Distributed workmanager fails to obtain view
> --------------------------------------------
>
> Key: WFLY-8617
> URL: https://issues.jboss.org/browse/WFLY-8617
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Reporter: Stefano Maestri
> Assignee: Stefano Maestri
> Priority: Critical
> Labels: KK-DR17
>
> When starting two EAP instances with a distributed workmanager configured, the following exception is logged on the first instance ~6 seconds after the second instance starts:
> {code}
> 16:11:24,204 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Beta6-redhat-1) started in 5905ms - Started 467 of 700 services (472 services are lazy, passive or on-demand)
> 16:11:42,066 ERROR [org.jboss.jca.core.workmanager.transport.remote.jgroups.JGroupsTransport] (thread-2) ViewAccepted: org.jgroups.TimeoutException: timeout waiting for response from node2, request: UnicastRequest, mode=GET_ALL, target=node2: javax.resource.spi.work.WorkException: org.jgroups.TimeoutException: timeout waiting for response from node2, request: UnicastRequest, mode=GET_ALL, target=node2
> at org.jboss.jca.core.workmanager.transport.remote.jgroups.JGroupsTransport.sendMessage(JGroupsTransport.java:589)
> at org.jboss.jca.core.workmanager.transport.remote.jgroups.JGroupsTransport.viewAccepted(JGroupsTransport.java:943)
> at org.jgroups.blocks.MessageDispatcher.handleUpEvent(MessageDispatcher.java:618)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:666)
> at org.jgroups.JChannel.up(JChannel.java:738)
> at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:124)
> at org.jgroups.stack.Protocol.up(Protocol.java:380)
> at org.jgroups.protocols.FORK.up(FORK.java:118)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:727)
> at org.jgroups.protocols.pbcast.CoordGmsImpl.handleViewChange(CoordGmsImpl.java:225)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:917)
> at org.jgroups.stack.Protocol.up(Protocol.java:418)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:294)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:487)
> at org.jgroups.protocols.pbcast.NAKACK2.deliverBatch(NAKACK2.java:989)
> at org.jgroups.protocols.pbcast.NAKACK2.removeAndPassUp(NAKACK2.java:919)
> at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:851)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:611)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155)
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:200)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:325)
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:292)
> at org.jgroups.protocols.Discovery.up(Discovery.java:296)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1657)
> at org.jgroups.protocols.TP$3.run(TP.java:1591)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.jgroups.TimeoutException: timeout waiting for response from node2, request: UnicastRequest, mode=GET_ALL, target=node2
> at org.jgroups.blocks.MessageDispatcher.sendMessage(MessageDispatcher.java:442)
> at org.jgroups.blocks.RpcDispatcher.callRemoteMethod(RpcDispatcher.java:241)
> at org.jboss.jca.core.workmanager.transport.remote.jgroups.JGroupsTransport.sendMessage(JGroupsTransport.java:579)
> ... 31 more
> {code}
> Judging by the stacktrace, it looks like a view of both of the wms is never created and the two workmanagers never manage to communicate with each other. That would also explain why it looks like work is never done on a different node than where it's scheduled (even though there are proper selector and policy settings). I'll file another issue for that where I'll add a reproducing test.
> Since it's a timeout exception, I've been trying to find out if the error is on my end (network issues), but it doesn't look like that - common clustering sessions, which use the JGroups stack too, are replicated properly.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8616) Distributed workmanager does not execute work on other nodes than where the work was scheduled
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/WFLY-8616?page=com.atlassian.jira.plugin.... ]
Stefano Maestri moved JBEAP-10470 to WFLY-8616:
-----------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8616 (was: JBEAP-10470)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: JCA
(was: JCA)
Affects Version/s: (was: 7.1.0.DR13)
> Distributed workmanager does not execute work on other nodes than where the work was scheduled
> ----------------------------------------------------------------------------------------------
>
> Key: WFLY-8616
> URL: https://issues.jboss.org/browse/WFLY-8616
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Reporter: Stefano Maestri
> Assignee: Stefano Maestri
> Priority: Blocker
> Labels: KK-DR17, eap7.1-rfe-blocker, eap71_beta
>
> Scenario: we have two EAP servers, both of them have a distributed workmanager set up. We try to schedule some work on one of the servers (via {{scheduleWork()}} and since we have a policy of ALWAYS, the work should be executed on a node different from the one where it was scheduled. However, it is always executed on the same node.
> This might be related to or even caused by JBEAP-9418.
> I think this is severe enough to warrant a beta blocker label - the DWM can be configured and you can pass work instances to it, but they will never be executed on remote nodes. In effect, policy options other than NEVER do not work. I'm raising the priority to blocker accordingly.
> This also blocks EAP7-495.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years