[JBoss JIRA] (WFLY-7912) It's not possible to change election-policy of singleton-policy
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-7912?page=com.atlassian.jira.plugin.... ]
Paul Ferraro closed WFLY-7912.
------------------------------
Resolution: Rejected
[~thofman] You cannot just add the simple policy without removing the existing random policy. Remember, the only operations that are implicit are the election-policy=simple:add or remove. Therefore, to revert from the random policy back to the default (i.e. simple) policy, you would use the following command:
{noformat}
/subsystem=singleton/singleton-policy=default/election-policy=random:remove(){allow-resource-service-restart=true}
{noformat}
This is effectively a short cut, since the election-policy=simple:add() is implied (i.e. optional).
> It's not possible to change election-policy of singleton-policy
> ---------------------------------------------------------------
>
> Key: WFLY-7912
> URL: https://issues.jboss.org/browse/WFLY-7912
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Reporter: Tomas Hofman
> Assignee: Paul Ferraro
>
> Attempt to change election policy:
> {code}
> [standalone@localhost:9990 /] batch
> [standalone@localhost:9990 / #] /subsystem=singleton/singleton-policy=default/election-policy=simple:remove
> [standalone@localhost:9990 / #] /subsystem=singleton/singleton-policy=default/election-policy=random:add
> [standalone@localhost:9990 / #] run-batch
> {code}
> results in
> {code}
> The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error):
> WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:
> Step: step-2
> Operation: /subsystem=singleton/singleton-policy=default/election-policy=random:add
> Failure: WFLYCTL0158: Operation handler failed: org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.clustering.singleton.policy.default.election-policy is already registered
> {code}
> The bug seems to be introduced by https://github.com/wildfly/wildfly/commit/605b22c30ae122492e7c019e330fea2...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-7912) It's not possible to change election-policy of singleton-policy
by Tomas Hofman (JIRA)
[ https://issues.jboss.org/browse/WFLY-7912?page=com.atlassian.jira.plugin.... ]
Tomas Hofman reopened WFLY-7912:
--------------------------------
> It's not possible to change election-policy of singleton-policy
> ---------------------------------------------------------------
>
> Key: WFLY-7912
> URL: https://issues.jboss.org/browse/WFLY-7912
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Reporter: Tomas Hofman
> Assignee: Paul Ferraro
>
> Attempt to change election policy:
> {code}
> [standalone@localhost:9990 /] batch
> [standalone@localhost:9990 / #] /subsystem=singleton/singleton-policy=default/election-policy=simple:remove
> [standalone@localhost:9990 / #] /subsystem=singleton/singleton-policy=default/election-policy=random:add
> [standalone@localhost:9990 / #] run-batch
> {code}
> results in
> {code}
> The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error):
> WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:
> Step: step-2
> Operation: /subsystem=singleton/singleton-policy=default/election-policy=random:add
> Failure: WFLYCTL0158: Operation handler failed: org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.clustering.singleton.policy.default.election-policy is already registered
> {code}
> The bug seems to be introduced by https://github.com/wildfly/wildfly/commit/605b22c30ae122492e7c019e330fea2...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-7912) It's not possible to change election-policy of singleton-policy
by Tomas Hofman (JIRA)
[ https://issues.jboss.org/browse/WFLY-7912?page=com.atlassian.jira.plugin.... ]
Tomas Hofman commented on WFLY-7912:
------------------------------------
[~pferraro] I think this should be reopened. Changing from simple election policy to random is working as you described, but changing from random back to simple is not:
{code}
[standalone@localhost:9990 /] /subsystem=singleton/singleton-policy=default/election-policy=simple:add {allow-resource-service-restart=true}
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0158: Operation handler failed: org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.clustering.singleton.policy.default.election-policy is already registered",
"rolled-back" => true
}
{code}
The random-election-policy is not recognized as a required singleton sibling in AddStepHandler and isn't removed.
Also, this approach doesn't go along with Web Console.
> It's not possible to change election-policy of singleton-policy
> ---------------------------------------------------------------
>
> Key: WFLY-7912
> URL: https://issues.jboss.org/browse/WFLY-7912
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Reporter: Tomas Hofman
> Assignee: Paul Ferraro
>
> Attempt to change election policy:
> {code}
> [standalone@localhost:9990 /] batch
> [standalone@localhost:9990 / #] /subsystem=singleton/singleton-policy=default/election-policy=simple:remove
> [standalone@localhost:9990 / #] /subsystem=singleton/singleton-policy=default/election-policy=random:add
> [standalone@localhost:9990 / #] run-batch
> {code}
> results in
> {code}
> The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error):
> WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:
> Step: step-2
> Operation: /subsystem=singleton/singleton-policy=default/election-policy=random:add
> Failure: WFLYCTL0158: Operation handler failed: org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.clustering.singleton.policy.default.election-policy is already registered
> {code}
> The bug seems to be introduced by https://github.com/wildfly/wildfly/commit/605b22c30ae122492e7c019e330fea2...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-2260) Validate presence of required attributes in PersistentResourceXmlParser/Description
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2260?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2260:
-------------------------------------
Description:
One disadvantage of moving away from hand coded parsers to PersistentResourceXmlParser/Description is the hand coded ones often had a bit of logic to confirm that all expected attributes were set and fail with XmlStreamException if not. The benefit of that vs failing in boot operation execution is the indication of where in the xml the problem is and the integration with VDX.
See JBEAP-8437 for an example of where that no longer happens.
Adding this kind of thing to PersistentResourceXmlParser/Description is a bit tricky since it's generic while the hand coded stuff could just be applied where it was easy for the author to understand. (Of course being generic is a great advantage once it's done right since it gets applied consistently.)
Things that generic support would need to understand:
1) Attributes with alternatives are not required if the alternative is set.
2) Whether persistence is all via xml attributes or whether elements are involved. IOW when should the check that all required things are set be performed? If all persistence is to xml attributes then it should be done once the start element is parsed, before child elements. But if child elements are involved, then this needs to be deferred. Or I guess repeated, with logic that recognizes it's possible a required attribute that is persisted as an xml attribute may have an alternative that is persisted as an element.
Speaking more generally, Jeff Mesnil had the brainstorming thought that beyond specific logic for this it may be possible for PersistentResourceXmlParser/Description to do validation against schema. Plenty of issues to consider there, including how to deal with expressions. (It would be great if it were easy to ask an xml validator to just validate structure, but ignore whether attribute values match the schema rules. That would avoid the problem with expressions. We already validate all the attribute values.)
This is NOT meant for WildFly Core 3.0.
was:
One disadvantage of moving away from hand coded parsers to PersistentResourceXmlParser/Description is the hand coded ones often had a bit of logic to confirm that all expected attributes were set and fail with XmlStreamException if not. The benefit of that vs failing in boot operation execution is the indication of where in the xml the problem is and the integration with VDX.
See JBEAP-8437 for an example of where that no longer happens.
Adding this kind of thing to PersistentResourceXmlParser/Description is a bit tricky since it's generic while the hand coded stuff could just be applied where it was easy for the author to understand.
Things that generic support would need to understand:
1) Attributes with alternatives are not required if the alternative is set.
2) Whether persistence is all via xml attributes or whether elements are involved. IOW when should the check that all required things are set be performed? If all persistence is to xml attributes then it should be done once the start element is parsed, before child elements. But if child elements are involved, then this needs to be deferred. Or I guess repeated, with logic that recognizes it's possible a required attribute that is persisted as an xml attribute may have an alternative that is persisted as an element.
Speaking more generally, Jeff Mesnil had the brainstorming thought that beyond specific logic for this it may be possible for PersistentResourceXmlParser/Description to do validation against schema. Plenty of issues to consider there, including how to deal with expressions. (It would be great if it were easy to ask an xml validator to just validate structure, but ignore whether attribute values match the schema rules. That would avoid the problem with expressions. We already validate all the attribute values.)
This is NOT meant for WildFly Core 3.0.
> Validate presence of required attributes in PersistentResourceXmlParser/Description
> -----------------------------------------------------------------------------------
>
> Key: WFCORE-2260
> URL: https://issues.jboss.org/browse/WFCORE-2260
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Tomaz Cerar
>
> One disadvantage of moving away from hand coded parsers to PersistentResourceXmlParser/Description is the hand coded ones often had a bit of logic to confirm that all expected attributes were set and fail with XmlStreamException if not. The benefit of that vs failing in boot operation execution is the indication of where in the xml the problem is and the integration with VDX.
> See JBEAP-8437 for an example of where that no longer happens.
> Adding this kind of thing to PersistentResourceXmlParser/Description is a bit tricky since it's generic while the hand coded stuff could just be applied where it was easy for the author to understand. (Of course being generic is a great advantage once it's done right since it gets applied consistently.)
> Things that generic support would need to understand:
> 1) Attributes with alternatives are not required if the alternative is set.
> 2) Whether persistence is all via xml attributes or whether elements are involved. IOW when should the check that all required things are set be performed? If all persistence is to xml attributes then it should be done once the start element is parsed, before child elements. But if child elements are involved, then this needs to be deferred. Or I guess repeated, with logic that recognizes it's possible a required attribute that is persisted as an xml attribute may have an alternative that is persisted as an element.
> Speaking more generally, Jeff Mesnil had the brainstorming thought that beyond specific logic for this it may be possible for PersistentResourceXmlParser/Description to do validation against schema. Plenty of issues to consider there, including how to deal with expressions. (It would be great if it were easy to ask an xml validator to just validate structure, but ignore whether attribute values match the schema rules. That would avoid the problem with expressions. We already validate all the attribute values.)
> This is NOT meant for WildFly Core 3.0.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-2260) Validate presence of required attributes in PersistentResourceXmlParser/Description
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2260?page=com.atlassian.jira.plugi... ]
Brian Stansberry moved JBEAP-8634 to WFCORE-2260:
-------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-2260 (was: JBEAP-8634)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Domain Management
(was: Domain Management)
Target Release: (was: 7.1.0.GA)
> Validate presence of required attributes in PersistentResourceXmlParser/Description
> -----------------------------------------------------------------------------------
>
> Key: WFCORE-2260
> URL: https://issues.jboss.org/browse/WFCORE-2260
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Tomaz Cerar
>
> One disadvantage of moving away from hand coded parsers to PersistentResourceXmlParser/Description is the hand coded ones often had a bit of logic to confirm that all expected attributes were set and fail with XmlStreamException if not. The benefit of that vs failing in boot operation execution is the indication of where in the xml the problem is and the integration with VDX.
> See JBEAP-8437 for an example of where that no longer happens.
> Adding this kind of thing to PersistentResourceXmlParser/Description is a bit tricky since it's generic while the hand coded stuff could just be applied where it was easy for the author to understand.
> Things that generic support would need to understand:
> 1) Attributes with alternatives are not required if the alternative is set.
> 2) Whether persistence is all via xml attributes or whether elements are involved. IOW when should the check that all required things are set be performed? If all persistence is to xml attributes then it should be done once the start element is parsed, before child elements. But if child elements are involved, then this needs to be deferred. Or I guess repeated, with logic that recognizes it's possible a required attribute that is persisted as an xml attribute may have an alternative that is persisted as an element.
> Speaking more generally, Jeff Mesnil had the brainstorming thought that beyond specific logic for this it may be possible for PersistentResourceXmlParser/Description to do validation against schema. Plenty of issues to consider there, including how to deal with expressions. (It would be great if it were easy to ask an xml validator to just validate structure, but ignore whether attribute values match the schema rules. That would avoid the problem with expressions. We already validate all the attribute values.)
> This is NOT meant for WildFly Core 3.0.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ELY-909) Elytron ldap-realm does not handle loops in referrals
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-909?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina moved WFLY-7946 to ELY-909:
--------------------------------------
Project: WildFly Elytron (was: WildFly)
Key: ELY-909 (was: WFLY-7946)
Component/s: Realms
(was: Security)
Affects Version/s: 1.1.0.Beta21
(was: 11.0.0.Alpha1)
> Elytron ldap-realm does not handle loops in referrals
> -----------------------------------------------------
>
> Key: ELY-909
> URL: https://issues.jboss.org/browse/ELY-909
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Affects Versions: 1.1.0.Beta21
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Critical
> Attachments: print-roles.war
>
>
> According to LDAP specification [1]: "Clients that follow referrals MUST ensure that they do not loop between servers. They MUST NOT repeatedly contact the same server for the same request with the same parameters.".
> When application server is configured to use ldap-realm with dir-context which uses referral-mode=follow or throw and LDAP servers contain loop then it leads to infinite cycle. It can results to java.lang.OutOfMemoryError on EAP server.
> [1] http://tools.ietf.org/html/rfc4511#section-4.1.10
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-8012) Elytron kerberos-security-factory debug attribute type
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-8012?page=com.atlassian.jira.plugin.... ]
Martin Choma updated WFLY-8012:
-------------------------------
Labels: user_experience (was: UserExperience)
> Elytron kerberos-security-factory debug attribute type
> ------------------------------------------------------
>
> Key: WFLY-8012
> URL: https://issues.jboss.org/browse/WFLY-8012
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Labels: user_experience
>
> Currently kerberos-security-factory debug attribute is in management model defined as STRING type, but could be BOOLEAN.
> {code}
> "kerberos-security-factory" => {
> "description" => "A security factory for obtaining a GSSCredential for use during authentication.",
> "model-description" => {"*" => {
> "description" => "A security factory for obtaining a GSSCredential for use during authentication.",
> "capabilities" => [{
> "name" => "org.wildfly.security.security-factory.credential",
> "dynamic" => true
> }],
> "attributes" => {
> "debug" => {
> "type" => STRING,
> "description" => "Should the JAAS step of obtaining the credential have debug logging enabled.",
> "expressions-allowed" => true,
> "required" => false,
> "nillable" => true,
> "default" => false,
> "min-length" => 1L,
> "max-length" => 2147483647L,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "resource-services"
> },
> {code}
> In XSD it is properly configured as boolean
> {code:xml}
> <xs:attribute name="debug" type="xs:boolean" default="false">
> <xs:annotation>
> <xs:documentation>
> Should the JAAS step of obtaining the credential have debug logging enabled.
> </xs:documentation>
> </xs:annotation>
> </xs:attribute>
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-8012) Elytron kerberos-security-factory debug attribute type
by Martin Choma (JIRA)
Martin Choma created WFLY-8012:
----------------------------------
Summary: Elytron kerberos-security-factory debug attribute type
Key: WFLY-8012
URL: https://issues.jboss.org/browse/WFLY-8012
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Martin Choma
Assignee: Darran Lofthouse
Currently kerberos-security-factory debug attribute is in management model defined as STRING type, but could be BOOLEAN.
{code}
"kerberos-security-factory" => {
"description" => "A security factory for obtaining a GSSCredential for use during authentication.",
"model-description" => {"*" => {
"description" => "A security factory for obtaining a GSSCredential for use during authentication.",
"capabilities" => [{
"name" => "org.wildfly.security.security-factory.credential",
"dynamic" => true
}],
"attributes" => {
"debug" => {
"type" => STRING,
"description" => "Should the JAAS step of obtaining the credential have debug logging enabled.",
"expressions-allowed" => true,
"required" => false,
"nillable" => true,
"default" => false,
"min-length" => 1L,
"max-length" => 2147483647L,
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "resource-services"
},
{code}
In XSD it is properly configured as boolean
{code:xml}
<xs:attribute name="debug" type="xs:boolean" default="false">
<xs:annotation>
<xs:documentation>
Should the JAAS step of obtaining the credential have debug logging enabled.
</xs:documentation>
</xs:annotation>
</xs:attribute>
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months