[JBoss JIRA] (WFCORE-2089) Infinite wildfly boot on StartException in service start
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2089?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFCORE-2089:
------------------------------------------
I will have another look at the relationships in this area - but TBH if we get a failed service start up that is required for establishing the identity we probably should be aborting the server starting any further.
We could fall back to the anonymous identity which with RBAC would mean they are not authorized to do anything (unless anonymous has a mapped role), but all audit logging would also be inaccurate.
It it not guaranteed the same security domain will be used but in this specific example the same security domain is used for the management interfaces so they will not be available anyway.
So overall I think this is going to need clean failure handling rather than allowing the server to continue.
> Infinite wildfly boot on StartException in service start
> --------------------------------------------------------
>
> Key: WFCORE-2089
> URL: https://issues.jboss.org/browse/WFCORE-2089
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security
> Reporter: Jan Kalina
> Assignee: Darran Lofthouse
> Priority: Blocker
> Attachments: threads-2.txt, threads.txt
>
>
> Following exception (and probably similar too) will cause wildfly frozing during start. Visible especially during integration tests (which will never ends), but reproducible directly too (see steps).
> {code:java}
> 15:59:37,252 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service org.wildfly.security.security-realm.ManagementRealm: org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.ManagementRealm: WFLYELY00025: Referenced property file is invalid: ELY01006: No realm name found in password property file
> at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:185)
> at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:164)
> at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
> 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}
> *Update:* This problem with infinite boot will occure everytime the start() method of some service throws StartException(). Not an Elytron problem.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 7 months
[JBoss JIRA] (WFCORE-2092) ProxyControllerRegistration does not properly implement getOperationDescriptions
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2092?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2092:
-------------------------------------
Description:
A ProxyControllerRegistration is kind of a strange beast, as it represents a resource that has a dual nature, both as a leaf resource on the local process and as the root resource on the remote process. One place where this falls apart is with getOperationDescriptions, which does nothing locally, resulting in only ops on the remote side being described.
But a ProxyControllerRegistration can also have local ops; e.g. stop/kill/destroy ops on a /host=x/server=y resource. But because of this bug those ops can be invoked but they do not appear in things like read-operation-names output.
UPDATE: this is a poor description as the real goal is to get correct metadata via read-operation-names, read-operation-description, read-resource-description and doing that will require more than changing ProxyControllerRegistration. There would need to be OSHs for those ops at the proxy address that understand how to integrate the data from the two aspects of the resource.
UPDATE 2: Similar discussion may apply to attributes.
was:
A ProxyControllerRegistration is kind of a strange beast, as it represents a resource that has a dual nature, both as a leaf resource on the local process and as the root resource on the remote process. One place where this falls apart is with getOperationDescriptions, which does nothing locally, resulting in only ops on the remote side being described.
But a ProxyControllerRegistration can also have local ops; e.g. stop/kill/destroy ops on a /host=x/server=y resource. But because of this bug those ops can be invoked but they do not appear in things like read-operation-names output.
UPDATE: this is a poor description as the real goal is to get correct metadata via read-operation-names, read-operation-description, read-resource-description and doing that will require more than changing ProxyControllerRegistration. There would need to be OSHs for those ops at the proxy address that understand how to integrate the data from the two aspects of the resource.
> ProxyControllerRegistration does not properly implement getOperationDescriptions
> --------------------------------------------------------------------------------
>
> Key: WFCORE-2092
> URL: https://issues.jboss.org/browse/WFCORE-2092
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
>
> A ProxyControllerRegistration is kind of a strange beast, as it represents a resource that has a dual nature, both as a leaf resource on the local process and as the root resource on the remote process. One place where this falls apart is with getOperationDescriptions, which does nothing locally, resulting in only ops on the remote side being described.
> But a ProxyControllerRegistration can also have local ops; e.g. stop/kill/destroy ops on a /host=x/server=y resource. But because of this bug those ops can be invoked but they do not appear in things like read-operation-names output.
> UPDATE: this is a poor description as the real goal is to get correct metadata via read-operation-names, read-operation-description, read-resource-description and doing that will require more than changing ProxyControllerRegistration. There would need to be OSHs for those ops at the proxy address that understand how to integrate the data from the two aspects of the resource.
> UPDATE 2: Similar discussion may apply to attributes.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 7 months
[JBoss JIRA] (WFCORE-2092) ProxyControllerRegistration does not properly implement getOperationDescriptions
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2092?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-2092:
----------------------------------------
Assignee: (was: Brian Stansberry)
> ProxyControllerRegistration does not properly implement getOperationDescriptions
> --------------------------------------------------------------------------------
>
> Key: WFCORE-2092
> URL: https://issues.jboss.org/browse/WFCORE-2092
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
>
> A ProxyControllerRegistration is kind of a strange beast, as it represents a resource that has a dual nature, both as a leaf resource on the local process and as the root resource on the remote process. One place where this falls apart is with getOperationDescriptions, which does nothing locally, resulting in only ops on the remote side being described.
> But a ProxyControllerRegistration can also have local ops; e.g. stop/kill/destroy ops on a /host=x/server=y resource. But because of this bug those ops can be invoked but they do not appear in things like read-operation-names output.
> UPDATE: this is a poor description as the real goal is to get correct metadata via read-operation-names, read-operation-description, read-resource-description and doing that will require more than changing ProxyControllerRegistration. There would need to be OSHs for those ops at the proxy address that understand how to integrate the data from the two aspects of the resource.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 7 months
[JBoss JIRA] (WFCORE-2092) ProxyControllerRegistration does not properly implement getOperationDescriptions
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2092?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2092:
-------------------------------------
Description:
A ProxyControllerRegistration is kind of a strange beast, as it represents a resource that has a dual nature, both as a leaf resource on the local process and as the root resource on the remote process. One place where this falls apart is with getOperationDescriptions, which does nothing locally, resulting in only ops on the remote side being described.
But a ProxyControllerRegistration can also have local ops; e.g. stop/kill/destroy ops on a /host=x/server=y resource. But because of this bug those ops can be invoked but they do not appear in things like read-operation-names output.
UPDATE: this is a poor description as the real goal is to get correct metadata via read-operation-names, read-operation-description, read-resource-description and doing that will require more than changing ProxyControllerRegistration. There would need to be OSHs for those ops at the proxy address that understand how to integrate the data from the two aspects of the resource.
was:
A ProxyControllerRegistration is kind of a strange beast, as it represents a resource that has a dual nature, both as a leaf resource on the local process and as the root resource on the remote process. One place where this falls apart is with getOperationDescriptions, which does nothing locally, resulting in only ops on the remote side being described.
But a ProxyControllerRegistration can also have local ops; e.g. stop/kill/destroy ops on a /host=x/server=y resource. But because of this bug those ops can be invoked but they do not appear in things like read-operation-names output.
> ProxyControllerRegistration does not properly implement getOperationDescriptions
> --------------------------------------------------------------------------------
>
> Key: WFCORE-2092
> URL: https://issues.jboss.org/browse/WFCORE-2092
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> A ProxyControllerRegistration is kind of a strange beast, as it represents a resource that has a dual nature, both as a leaf resource on the local process and as the root resource on the remote process. One place where this falls apart is with getOperationDescriptions, which does nothing locally, resulting in only ops on the remote side being described.
> But a ProxyControllerRegistration can also have local ops; e.g. stop/kill/destroy ops on a /host=x/server=y resource. But because of this bug those ops can be invoked but they do not appear in things like read-operation-names output.
> UPDATE: this is a poor description as the real goal is to get correct metadata via read-operation-names, read-operation-description, read-resource-description and doing that will require more than changing ProxyControllerRegistration. There would need to be OSHs for those ops at the proxy address that understand how to integrate the data from the two aspects of the resource.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 7 months
[JBoss JIRA] (WFCORE-2093) A 'start' operation only is available for a domain server resource when it is started
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-2093:
----------------------------------------
Summary: A 'start' operation only is available for a domain server resource when it is started
Key: WFCORE-2093
URL: https://issues.jboss.org/browse/WFCORE-2093
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: Brian Stansberry
The server lifecycle ops are registered with the domain server resource by a call to ServerConfigResourceDefintion.registerServerLifecycleOperations. DomainModelControllerService registers that when the server registers with the HC.
This is odd in the case of 'start' as it means that op is only registered when the server is started.
Perhaps it should be registered with StoppedServerResource, although I haven't dug into what happens with that resource when the server is registered. If it is simply ignored that would be great.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 7 months
[JBoss JIRA] (WFCORE-2092) ProxyControllerRegistration does not properly implement getOperationDescriptions
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-2092:
----------------------------------------
Summary: ProxyControllerRegistration does not properly implement getOperationDescriptions
Key: WFCORE-2092
URL: https://issues.jboss.org/browse/WFCORE-2092
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
A ProxyControllerRegistration is kind of a strange beast, as it represents a resource that has a dual nature, both as a leaf resource on the local process and as the root resource on the remote process. One place where this falls apart is with getOperationDescriptions, which does nothing locally, resulting in only ops on the remote side being described.
But a ProxyControllerRegistration can also have local ops; e.g. stop/kill/destroy ops on a /host=x/server=y resource. But because of this bug those ops can be invoked but they do not appear in things like read-operation-names output.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 7 months
[JBoss JIRA] (WFCORE-2070) Domain server resource should have kill/destroy operations
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2070?page=com.atlassian.jira.plugi... ]
Brian Stansberry resolved WFCORE-2070.
--------------------------------------
Resolution: Out of Date
It turns out WFCORE-2070 is invalid. You actually can invoke the kill/destroy ops against the server resource. They are registered by a call to ServerConfigResourceDefintion.registerServerLifecycleOperations. DomainModelControllerService registers that when the server registers with the HC.
The op doesn’t show up in tab completion because the ‘server’ resource is kind of an odd thing, existing in two places simulaneously — as a resource in the HC and as the root of the resource tree on the server itself. My guess is operations like read-operation-names are not dealing with that dual nature correctly.
There are other strange things about those lifecycle ops on the server resource (like ‘start’ seems to only be available when the server is started already, which is pointless). But these things are not simple to fix and I don't want to use this JIRA for them.
> Domain server resource should have kill/destroy operations
> ----------------------------------------------------------
>
> Key: WFCORE-2070
> URL: https://issues.jboss.org/browse/WFCORE-2070
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
>
> The server-config resource has kill/destroy ops for the server. These should be present on the server resource as well.
> This is part of the overall user experience effort of not using server-config for lifecycle ops, since the resource is about the config the HC uses for the server not its runtime.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 7 months
[JBoss JIRA] (WFLY-7746) Upgrade to a version of Infinispan that depends on JBoss Marshalling 2.0.0.Beta3
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-7746?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-7746:
------------------------------------
[~fjuma] OK - the upgrade was pretty painless.
https://github.com/infinispan/infinispan/pull/4709
I'll check with [~NadirX] tomorrow to see if this is acceptable for Infinispan 8.2.x.
> Upgrade to a version of Infinispan that depends on JBoss Marshalling 2.0.0.Beta3
> --------------------------------------------------------------------------------
>
> Key: WFLY-7746
> URL: https://issues.jboss.org/browse/WFLY-7746
> Project: WildFly
> Issue Type: Component Upgrade
> Components: Clustering
> Reporter: Farah Juma
> Assignee: Paul Ferraro
> Attachments: org.jboss.as.test.clustering.cluster.sso.ClusteredSingleSignOnTestCase-SYNC-tcp-output.txt
>
>
> As part of the wildfly-naming-client integration work, we need to upgrade to JBoss Marshalling 2.0.0.Beta3 (see WFCORE-2044 and WFLY-7675). This upgrade currently results in testsuite failures in {{org.jboss.as.test.clustering.cluster.sso.ClusteredSingleSignOnTestCase}} since Infinispan is still on JBoss Marshalling 1.4.x.
> ISPN-3391 was created a while back to upgrade Infinispan to JBoss Marshalling 2.0.0 but it seems this issue was waiting on a JBoss Marshalling release that adds back some classes that had previously been removed. JBoss Marshalling 2.0.0.Beta3 contains these classes so it should be possible now to upgrade Infinispan to this new version.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 7 months