[JBoss JIRA] (WFLY-9892) Upgrade org.apache.santuario.xmlsec to 2.1.1. caused regression in PicketLinkSTS
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-9892?page=com.atlassian.jira.plugin.... ]
Jason Greene commented on WFLY-9892:
------------------------------------
Wrapped output coming from xmlsec is well-formed and valid XML. On the other hand SASL base64 values do not allow wrapping. So this to me just seems is like a quickstart/test/doc issue.
> Upgrade org.apache.santuario.xmlsec to 2.1.1. caused regression in PicketLinkSTS
> --------------------------------------------------------------------------------
>
> Key: WFLY-9892
> URL: https://issues.jboss.org/browse/WFLY-9892
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 12.0.0.Beta1
> Reporter: Ondrej Lukas
> Assignee: Pedro Igor
> Priority: Blocker
> Attachments: ejb-security-picketlink.zip, ejb-test.jar, picketlink-sts.war, sts-config.properties
>
>
> When token from PicketLink STS is issued and signed then it is not able to be used for authentication through Remoting in WildFly 12 (i.e. it cannot be set as {{remote.connection.main.password}} property which can be used in PicketLink {{org.picketlink.identity.federation.bindings.jboss.auth.SAML2STSLoginModule}}). It seems it is caused by upgrade of org.apache.santuario.xmlsec to version 2.1.1. [1]. When WILDFLY11_HOME/modules/system/layers/base/org/apache/santuario/xmlsec/main/xmlsec-2.0.8.jar is placed to WildFly 12 modules then it works correctly.
> We report it as a blocker since it is regression - application which works correctly on WildFly 11 stops to work on WildFly 12 - users are not able to authenticate through Remoting with signed tokens from PicketLink STS correctly.
> Remoting fails due to following exception:
> {code}
> java.lang.IllegalArgumentException: ELY05131: Invalid ASCII control "0xA"
> at org.wildfly.security.sasl.util.StringPrep.forbidAsciiControl(StringPrep.java:117)
> at org.wildfly.security.sasl.util.StringPrep.encode(StringPrep.java:295)
> at org.wildfly.security.sasl.util.StringPrep.encode(StringPrep.java:196)
> at org.wildfly.security.sasl.plain.PlainSaslClient.evaluateChallenge(PlainSaslClient.java:95)
> at org.wildfly.security.sasl.util.AbstractDelegatingSaslClient.evaluateChallenge(AbstractDelegatingSaslClient.java:54)
> at org.wildfly.security.sasl.util.PrivilegedSaslClient.lambda$evaluateChallenge$0(PrivilegedSaslClient.java:55)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.wildfly.security.sasl.util.PrivilegedSaslClient.evaluateChallenge(PrivilegedSaslClient.java:55)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.lambda$handleEvent$1(ClientConnectionOpenListener.java:460)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:926)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1979)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1481)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1374)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> It is caused by different formating value of SignatureValue in assertion. In WildFly 11 SignatureValue looks like:
> {code}
> <dsig:SignatureValue xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">nFVkKrXTyYEQ9cwc9OOgySYebEtwzw4alVYP0viXzvqZAUAKtAXEBAfDB8xIOms78twlDdq79MiSvk8OrOdf126Kw/IR8JRn1fYyZ5tsIRcNoTXMgGaTqhrn/HKlLqqqHhVHrJURunqkSzTTxylA2AEPhEDD5Y7hS0W2ZZCeSvuri+PRDSTrRnuedz0yQuHQu1mZ0gjoEFbHh4Wkkn5Ac1R4gmewmmzPud+ZE6Ux4YpeHzQ8rAvZ4bDk6j+eQIRsSxFTLo5RSA3FWN8+lUNV/CSRqBPXsK7QxOaTdBgF+4NXWeExrNJ9SeVFcf9yelvReAtR2JNZ6DUY8u45KtXmLw==</dsig:SignatureValue>
> {code}
> In WildFly 12 it looks like (there are end of lines):
> {code}
> <dsig:SignatureValue xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">cUNpFJIZlLYrBDZtQSTDrq2K6PbnAHyg2qbx/D5FuB4XMjdQ5oxQjkMejLyelnA7s4GFusoLhahl
> qlTOT8UrOyxrR4yYAmJ/e5s+f4gys926+tbiraT/3/wG8wM/Lvcjvk5Ap69zODuRYpypsWfA4jrI
> 7TTBXVPGy8g4KUdnFviUiTuFTc2Ghgxp53AmUuLis/THyP28jE7+28//q8bi/bQrFwHC6tWX67+N
> K1duFCOcQ6IPIKeVrePZz55Ivgl+WWdkF6uYCz5IdMzurhzmeQ3K8DAMIxz/MG67VWJIOnuGNWF7
> nmdye5zd9AFcRsr1XadvZJCbGNfuc89AL5inCg==</dsig:SignatureValue>
> {code}
> [1] https://github.com/wildfly/wildfly/commit/536de514829f2187abf1126c8916a04...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (WFLY-9892) Upgrade org.apache.santuario.xmlsec to 2.1.1. caused regression in PicketLinkSTS
by Pedro Igor (JIRA)
[ https://issues.jboss.org/browse/WFLY-9892?page=com.atlassian.jira.plugin.... ]
Pedro Igor edited comment on WFLY-9892 at 2/26/18 7:40 PM:
-----------------------------------------------------------
[~olukas], the signature value is changing whenever the element is read. PL is generating the signature element and value correctly but because of indentation, carriage return is included as {{#13;}}.
The tests pointed out by Honza are not related with this issue in particular. {{SAMLAssertionWrappingAttackTestCase}} is failing because the attack asserted by the test is not possible anymore with xmlsec:2.1.1 because you can not have a {{samlp:Respnse}} inside a {{xmldsig:Signature}} element. The library is more restrict ....
The {{DomElementToStaxWritingTestCase}} is failing just because we are not closing the "writer".
Will investigate now the infamous {{#13;}} and give you more details.
was (Author: pcraveiro):
[~olukas], the signature value is changing whenever the element is read. PL is generating the signature element and value correctly but because of indentation, carriage return is included as {{ }}.
The tests pointed out by Honza are not related with this issue in particular. {{SAMLAssertionWrappingAttackTestCase}} is failing because the attack asserted by the test is not possible anymore with xmlsec:2.1.1 because you can not have a {{samlp:Respnse}} inside a {{xmldsig:Signature}} element. The library is more restrict ....
The {{DomElementToStaxWritingTestCase}} is failing just because we are not closing the "writer".
Will investigate now the infamous {{ }} and give you more details.
> Upgrade org.apache.santuario.xmlsec to 2.1.1. caused regression in PicketLinkSTS
> --------------------------------------------------------------------------------
>
> Key: WFLY-9892
> URL: https://issues.jboss.org/browse/WFLY-9892
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 12.0.0.Beta1
> Reporter: Ondrej Lukas
> Assignee: Pedro Igor
> Priority: Blocker
> Attachments: ejb-security-picketlink.zip, ejb-test.jar, picketlink-sts.war, sts-config.properties
>
>
> When token from PicketLink STS is issued and signed then it is not able to be used for authentication through Remoting in WildFly 12 (i.e. it cannot be set as {{remote.connection.main.password}} property which can be used in PicketLink {{org.picketlink.identity.federation.bindings.jboss.auth.SAML2STSLoginModule}}). It seems it is caused by upgrade of org.apache.santuario.xmlsec to version 2.1.1. [1]. When WILDFLY11_HOME/modules/system/layers/base/org/apache/santuario/xmlsec/main/xmlsec-2.0.8.jar is placed to WildFly 12 modules then it works correctly.
> We report it as a blocker since it is regression - application which works correctly on WildFly 11 stops to work on WildFly 12 - users are not able to authenticate through Remoting with signed tokens from PicketLink STS correctly.
> Remoting fails due to following exception:
> {code}
> java.lang.IllegalArgumentException: ELY05131: Invalid ASCII control "0xA"
> at org.wildfly.security.sasl.util.StringPrep.forbidAsciiControl(StringPrep.java:117)
> at org.wildfly.security.sasl.util.StringPrep.encode(StringPrep.java:295)
> at org.wildfly.security.sasl.util.StringPrep.encode(StringPrep.java:196)
> at org.wildfly.security.sasl.plain.PlainSaslClient.evaluateChallenge(PlainSaslClient.java:95)
> at org.wildfly.security.sasl.util.AbstractDelegatingSaslClient.evaluateChallenge(AbstractDelegatingSaslClient.java:54)
> at org.wildfly.security.sasl.util.PrivilegedSaslClient.lambda$evaluateChallenge$0(PrivilegedSaslClient.java:55)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.wildfly.security.sasl.util.PrivilegedSaslClient.evaluateChallenge(PrivilegedSaslClient.java:55)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.lambda$handleEvent$1(ClientConnectionOpenListener.java:460)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:926)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1979)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1481)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1374)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> It is caused by different formating value of SignatureValue in assertion. In WildFly 11 SignatureValue looks like:
> {code}
> <dsig:SignatureValue xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">nFVkKrXTyYEQ9cwc9OOgySYebEtwzw4alVYP0viXzvqZAUAKtAXEBAfDB8xIOms78twlDdq79MiSvk8OrOdf126Kw/IR8JRn1fYyZ5tsIRcNoTXMgGaTqhrn/HKlLqqqHhVHrJURunqkSzTTxylA2AEPhEDD5Y7hS0W2ZZCeSvuri+PRDSTrRnuedz0yQuHQu1mZ0gjoEFbHh4Wkkn5Ac1R4gmewmmzPud+ZE6Ux4YpeHzQ8rAvZ4bDk6j+eQIRsSxFTLo5RSA3FWN8+lUNV/CSRqBPXsK7QxOaTdBgF+4NXWeExrNJ9SeVFcf9yelvReAtR2JNZ6DUY8u45KtXmLw==</dsig:SignatureValue>
> {code}
> In WildFly 12 it looks like (there are end of lines):
> {code}
> <dsig:SignatureValue xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">cUNpFJIZlLYrBDZtQSTDrq2K6PbnAHyg2qbx/D5FuB4XMjdQ5oxQjkMejLyelnA7s4GFusoLhahl
> qlTOT8UrOyxrR4yYAmJ/e5s+f4gys926+tbiraT/3/wG8wM/Lvcjvk5Ap69zODuRYpypsWfA4jrI
> 7TTBXVPGy8g4KUdnFviUiTuFTc2Ghgxp53AmUuLis/THyP28jE7+28//q8bi/bQrFwHC6tWX67+N
> K1duFCOcQ6IPIKeVrePZz55Ivgl+WWdkF6uYCz5IdMzurhzmeQ3K8DAMIxz/MG67VWJIOnuGNWF7
> nmdye5zd9AFcRsr1XadvZJCbGNfuc89AL5inCg==</dsig:SignatureValue>
> {code}
> [1] https://github.com/wildfly/wildfly/commit/536de514829f2187abf1126c8916a04...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (WFLY-9892) Upgrade org.apache.santuario.xmlsec to 2.1.1. caused regression in PicketLinkSTS
by Pedro Igor (JIRA)
[ https://issues.jboss.org/browse/WFLY-9892?page=com.atlassian.jira.plugin.... ]
Pedro Igor commented on WFLY-9892:
----------------------------------
[~olukas], the signature value is changing whenever the element is read. PL is generating the signature element and value correctly but because of indentation, carriage return is included as {{ }}.
The tests pointed out by Honza are not related with this issue in particular. {{SAMLAssertionWrappingAttackTestCase}} is failing because the attack asserted by the test is not possible anymore with xmlsec:2.1.1 because you can not have a {{samlp:Respnse}} inside a {{xmldsig:Signature}} element. The library is more restrict ....
The {{DomElementToStaxWritingTestCase}} is failing just because we are not closing the "writer".
Will investigate now the infamous {{ }} and give you more details.
> Upgrade org.apache.santuario.xmlsec to 2.1.1. caused regression in PicketLinkSTS
> --------------------------------------------------------------------------------
>
> Key: WFLY-9892
> URL: https://issues.jboss.org/browse/WFLY-9892
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 12.0.0.Beta1
> Reporter: Ondrej Lukas
> Assignee: Pedro Igor
> Priority: Blocker
> Attachments: ejb-security-picketlink.zip, ejb-test.jar, picketlink-sts.war, sts-config.properties
>
>
> When token from PicketLink STS is issued and signed then it is not able to be used for authentication through Remoting in WildFly 12 (i.e. it cannot be set as {{remote.connection.main.password}} property which can be used in PicketLink {{org.picketlink.identity.federation.bindings.jboss.auth.SAML2STSLoginModule}}). It seems it is caused by upgrade of org.apache.santuario.xmlsec to version 2.1.1. [1]. When WILDFLY11_HOME/modules/system/layers/base/org/apache/santuario/xmlsec/main/xmlsec-2.0.8.jar is placed to WildFly 12 modules then it works correctly.
> We report it as a blocker since it is regression - application which works correctly on WildFly 11 stops to work on WildFly 12 - users are not able to authenticate through Remoting with signed tokens from PicketLink STS correctly.
> Remoting fails due to following exception:
> {code}
> java.lang.IllegalArgumentException: ELY05131: Invalid ASCII control "0xA"
> at org.wildfly.security.sasl.util.StringPrep.forbidAsciiControl(StringPrep.java:117)
> at org.wildfly.security.sasl.util.StringPrep.encode(StringPrep.java:295)
> at org.wildfly.security.sasl.util.StringPrep.encode(StringPrep.java:196)
> at org.wildfly.security.sasl.plain.PlainSaslClient.evaluateChallenge(PlainSaslClient.java:95)
> at org.wildfly.security.sasl.util.AbstractDelegatingSaslClient.evaluateChallenge(AbstractDelegatingSaslClient.java:54)
> at org.wildfly.security.sasl.util.PrivilegedSaslClient.lambda$evaluateChallenge$0(PrivilegedSaslClient.java:55)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.wildfly.security.sasl.util.PrivilegedSaslClient.evaluateChallenge(PrivilegedSaslClient.java:55)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.lambda$handleEvent$1(ClientConnectionOpenListener.java:460)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:926)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1979)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1481)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1374)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> It is caused by different formating value of SignatureValue in assertion. In WildFly 11 SignatureValue looks like:
> {code}
> <dsig:SignatureValue xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">nFVkKrXTyYEQ9cwc9OOgySYebEtwzw4alVYP0viXzvqZAUAKtAXEBAfDB8xIOms78twlDdq79MiSvk8OrOdf126Kw/IR8JRn1fYyZ5tsIRcNoTXMgGaTqhrn/HKlLqqqHhVHrJURunqkSzTTxylA2AEPhEDD5Y7hS0W2ZZCeSvuri+PRDSTrRnuedz0yQuHQu1mZ0gjoEFbHh4Wkkn5Ac1R4gmewmmzPud+ZE6Ux4YpeHzQ8rAvZ4bDk6j+eQIRsSxFTLo5RSA3FWN8+lUNV/CSRqBPXsK7QxOaTdBgF+4NXWeExrNJ9SeVFcf9yelvReAtR2JNZ6DUY8u45KtXmLw==</dsig:SignatureValue>
> {code}
> In WildFly 12 it looks like (there are end of lines):
> {code}
> <dsig:SignatureValue xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">cUNpFJIZlLYrBDZtQSTDrq2K6PbnAHyg2qbx/D5FuB4XMjdQ5oxQjkMejLyelnA7s4GFusoLhahl
> qlTOT8UrOyxrR4yYAmJ/e5s+f4gys926+tbiraT/3/wG8wM/Lvcjvk5Ap69zODuRYpypsWfA4jrI
> 7TTBXVPGy8g4KUdnFviUiTuFTc2Ghgxp53AmUuLis/THyP28jE7+28//q8bi/bQrFwHC6tWX67+N
> K1duFCOcQ6IPIKeVrePZz55Ivgl+WWdkF6uYCz5IdMzurhzmeQ3K8DAMIxz/MG67VWJIOnuGNWF7
> nmdye5zd9AFcRsr1XadvZJCbGNfuc89AL5inCg==</dsig:SignatureValue>
> {code}
> [1] https://github.com/wildfly/wildfly/commit/536de514829f2187abf1126c8916a04...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (WFCORE-3655) Improve embedded HC started with empty config state reporting?
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3655?page=com.atlassian.jira.plugi... ]
Ken Wills commented on WFCORE-3655:
-----------------------------------
[~aloubyansky] (a) I think, is just me misunderstanding how it actually works. As Brian points out we poll in a loop to pretend it's sync but its really async.
> Improve embedded HC started with empty config state reporting?
> --------------------------------------------------------------
>
> Key: WFCORE-3655
> URL: https://issues.jboss.org/browse/WFCORE-3655
> Project: WildFly Core
> Issue Type: Enhancement
> Reporter: Ken Wills
> Assignee: Ken Wills
> Priority: Minor
>
> This is a discussion ticket, and I'm really only making it to track the discussion at the moment.
> Alexey and I had a discussion regarding this, and I thought it would be useful to open this and get other feedback.
> Currently, when an embedded host controller is started with an empty config, a partial domain controller start is performed and then paused until the /host=foo:add command is issued.
> In the case that the HC is being started programatically it seems desirable to be able to check this step has been completed.
> Using the command from the CLI / inside a cli script doesn't have this problem as the CLI waits for the response before continuuing.
> Some clients poll on the /host=foo:host-status attribute, this isn't present until a host has been actually added though.
> the existing options are:
> (a) Like the CLI, just wait until the operation completes. I think this should currently always work.
> (b) Poll on the existence of the /host resource. If this is registered, then you can safely try to add your host (after all there may already be one.)
> Since the host hasn't been added, it doesn't make a lot of sense to provided a default status, as theres no /host=foo to hold the attribute.
> Other thoughts? Personally I'm a fan of (a). And I think that should always be sufficient. I'm not really sure what the programmatic expectations are for using ops like this are in general. Is behavior always assumed to be synchronous, so the end client doesn't need to poll or wait etc?
> [~aloubyansky] Feel free to comment and correct me if I was inaccurate about something.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (WFCORE-3655) Improve embedded HC started with empty config state reporting?
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3655?page=com.atlassian.jira.plugi... ]
Ken Wills commented on WFCORE-3655:
-----------------------------------
[~brian.stansberry] Thanks Brian. This is basically the reason why I thought creating this issue for the discussion would probably be a good idea.
The API definetly sounds like the way to go. Although, short term, if we're concerned, it may be sufficient to poll on the host resource being visible in the model to avoid this specific race?
> Improve embedded HC started with empty config state reporting?
> --------------------------------------------------------------
>
> Key: WFCORE-3655
> URL: https://issues.jboss.org/browse/WFCORE-3655
> Project: WildFly Core
> Issue Type: Enhancement
> Reporter: Ken Wills
> Assignee: Ken Wills
> Priority: Minor
>
> This is a discussion ticket, and I'm really only making it to track the discussion at the moment.
> Alexey and I had a discussion regarding this, and I thought it would be useful to open this and get other feedback.
> Currently, when an embedded host controller is started with an empty config, a partial domain controller start is performed and then paused until the /host=foo:add command is issued.
> In the case that the HC is being started programatically it seems desirable to be able to check this step has been completed.
> Using the command from the CLI / inside a cli script doesn't have this problem as the CLI waits for the response before continuuing.
> Some clients poll on the /host=foo:host-status attribute, this isn't present until a host has been actually added though.
> the existing options are:
> (a) Like the CLI, just wait until the operation completes. I think this should currently always work.
> (b) Poll on the existence of the /host resource. If this is registered, then you can safely try to add your host (after all there may already be one.)
> Since the host hasn't been added, it doesn't make a lot of sense to provided a default status, as theres no /host=foo to hold the attribute.
> Other thoughts? Personally I'm a fan of (a). And I think that should always be sufficient. I'm not really sure what the programmatic expectations are for using ops like this are in general. Is behavior always assumed to be synchronous, so the end client doesn't need to poll or wait etc?
> [~aloubyansky] Feel free to comment and correct me if I was inaccurate about something.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (WFCORE-3655) Improve embedded HC started with empty config state reporting?
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3655?page=com.atlassian.jira.plugi... ]
Alexey Loubyansky commented on WFCORE-3655:
-------------------------------------------
I think Brian's idea is how I'd personally like it to be implemented. There could also be a method that would block until the embedded process has reached the usable state.
> Improve embedded HC started with empty config state reporting?
> --------------------------------------------------------------
>
> Key: WFCORE-3655
> URL: https://issues.jboss.org/browse/WFCORE-3655
> Project: WildFly Core
> Issue Type: Enhancement
> Reporter: Ken Wills
> Assignee: Ken Wills
> Priority: Minor
>
> This is a discussion ticket, and I'm really only making it to track the discussion at the moment.
> Alexey and I had a discussion regarding this, and I thought it would be useful to open this and get other feedback.
> Currently, when an embedded host controller is started with an empty config, a partial domain controller start is performed and then paused until the /host=foo:add command is issued.
> In the case that the HC is being started programatically it seems desirable to be able to check this step has been completed.
> Using the command from the CLI / inside a cli script doesn't have this problem as the CLI waits for the response before continuuing.
> Some clients poll on the /host=foo:host-status attribute, this isn't present until a host has been actually added though.
> the existing options are:
> (a) Like the CLI, just wait until the operation completes. I think this should currently always work.
> (b) Poll on the existence of the /host resource. If this is registered, then you can safely try to add your host (after all there may already be one.)
> Since the host hasn't been added, it doesn't make a lot of sense to provided a default status, as theres no /host=foo to hold the attribute.
> Other thoughts? Personally I'm a fan of (a). And I think that should always be sufficient. I'm not really sure what the programmatic expectations are for using ops like this are in general. Is behavior always assumed to be synchronous, so the end client doesn't need to poll or wait etc?
> [~aloubyansky] Feel free to comment and correct me if I was inaccurate about something.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (WFCORE-3655) Improve embedded HC started with empty config state reporting?
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3655?page=com.atlassian.jira.plugi... ]
Alexey Loubyansky commented on WFCORE-3655:
-------------------------------------------
Thanks Ken for creating an issue for this.
Which operation did you imply in (a)? Was that /host=name:add?
> Improve embedded HC started with empty config state reporting?
> --------------------------------------------------------------
>
> Key: WFCORE-3655
> URL: https://issues.jboss.org/browse/WFCORE-3655
> Project: WildFly Core
> Issue Type: Enhancement
> Reporter: Ken Wills
> Assignee: Ken Wills
> Priority: Minor
>
> This is a discussion ticket, and I'm really only making it to track the discussion at the moment.
> Alexey and I had a discussion regarding this, and I thought it would be useful to open this and get other feedback.
> Currently, when an embedded host controller is started with an empty config, a partial domain controller start is performed and then paused until the /host=foo:add command is issued.
> In the case that the HC is being started programatically it seems desirable to be able to check this step has been completed.
> Using the command from the CLI / inside a cli script doesn't have this problem as the CLI waits for the response before continuuing.
> Some clients poll on the /host=foo:host-status attribute, this isn't present until a host has been actually added though.
> the existing options are:
> (a) Like the CLI, just wait until the operation completes. I think this should currently always work.
> (b) Poll on the existence of the /host resource. If this is registered, then you can safely try to add your host (after all there may already be one.)
> Since the host hasn't been added, it doesn't make a lot of sense to provided a default status, as theres no /host=foo to hold the attribute.
> Other thoughts? Personally I'm a fan of (a). And I think that should always be sufficient. I'm not really sure what the programmatic expectations are for using ops like this are in general. Is behavior always assumed to be synchronous, so the end client doesn't need to poll or wait etc?
> [~aloubyansky] Feel free to comment and correct me if I was inaccurate about something.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months