[JBoss JIRA] (WFCORE-3327) Confusion about the recording of the org.wildfly.remoting.endpoint capability and the resource that configures it
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3327?page=com.atlassian.jira.plugi... ]
Alexey Loubyansky commented on WFCORE-3327:
-------------------------------------------
2) is even more work in case we want to re-work other subsystems this way. That includes at least undertow and ejb3. While 2) looks the most reasonable approach to modeling these kind of cases, 1) may still be ok if the dependency from the parent to its child is expressed in the model, i.e. remoting -> endpoint (by means of caps or attribute refs).
It may look confusing to the user performing manual configuration. On the the other hand, the provisioning mechanism has already figured out how to handle these cases by properly ordering the features and automatically starting batches where necessary.
> Confusion about the recording of the org.wildfly.remoting.endpoint capability and the resource that configures it
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3327
> URL: https://issues.jboss.org/browse/WFCORE-3327
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Remoting
> Affects Versions: 3.0.3.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 4.0.0.Beta1
>
>
> The org.wildfly.remoting.endpoint capability is reported by the /subsystem=remoting resource, but it is the /subsystem=remoting/configuration=endpoint that actually configures it. This is confusing for humans and difficult for tooling like the new provisioning tools.
> The configuration=endpoint child is essentially a singleton and internally it just provides configuration to its parent. Further, if the user does not configure this resource, a default one is added automatically. This child resources is really just a configuration chunk for its parent.
> In the end it is the parent resource that actually provides the capability, by installing a service. It reads its child resource to configure the capability.
> There are a couple possibilities here:
> 1) Simply move the declaration of the capability to the child resource. Per discussion with [~aloubyansky] is seems that solves the tool problem. It leaves the actual situation obscure though, because now a seemingly non-required child resource is the thing that provides a capability that actually will always be present.
> 2) Deprecate that child resource and add a complex attribute to the parent. The child resource continues to exist in the API for compatibility reasons, but simply modifies the attribute on the parent. The cap remains on the parent.
> Note that 2) may require some manipulation of how we handle undefined complex attributes; i.e. that when we resolve them, even if the root attribute is undefined, we need to resolve the fields, in case those have default values, with the resolved parent then including the default field values. That can be tricky though, e.g. in cases of things like the defaulted attribute having requires, or other fields in the complex attribute being required.
> This latter point is relevant because it would be a 'worker' field in a complex attribute that would actually declare the name of the needed io worker capability. That field would have a default value 'default'.
> Perhaps the declaration of the complex attribute itself (i.e. ObjectTypeAttributeDefinition) would need to indicate how things should be handled. That could just be the complex attribute itself has a default value, {"worker"=>"default"}. Or it could be a flag that enables looking at the fields for defaults if the top level attribute is undefined. Or maybe investigation will show this isn't a problem at all.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 7 months
[JBoss JIRA] (WFLY-9410) Can't run mvn install against testsuite-shared module twice without an intervening clean
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-9410:
--------------------------------------
Summary: Can't run mvn install against testsuite-shared module twice without an intervening clean
Key: WFLY-9410
URL: https://issues.jboss.org/browse/WFLY-9410
Project: WildFly
Issue Type: Bug
Components: Test Suite
Reporter: Brian Stansberry
Trying to build testsuite/shared twice without a clean results in failure. Really annoying as a standard build of WildFly builds this module.
Failure is:
{code}
[ERROR] Failed to execute goal org.codehaus.mojo:keytool-maven-plugin:1.5:generateKeyPair (gen-server-keystore) on project wildfly-testsuite-shared: Failed executing '/bin/sh -c cd /Users/bstansberry/dev/wildfly/wildfly/testsuite/shared && /Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/../bin/keytool -genkeypair -v -keystore /Users/bstansberry/dev/wildfly/wildfly/testsuite/shared/target/shared-keystores/application.keystore -storepass '*****' -storetype JKS -alias server -dname 'cn=server, ou=organizationUnit, o=organizationName, c=countryCode' -keypass '*****' -validity 365 -keyalg RSA -keysize 2048' - exitcode 1 -> [Help 1]
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 7 months
[JBoss JIRA] (WFCORE-3327) Confusion about the recording of the org.wildfly.remoting.endpoint capability and the resource that configures it
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3327?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3327:
-------------------------------------
Summary: Confusion about the recording of the org.wildfly.remoting.endpoint capability and the resource that configures it (was: Confusing between recording of the org.wildfly.remoting.endpoint and the resource that configures it)
> Confusion about the recording of the org.wildfly.remoting.endpoint capability and the resource that configures it
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3327
> URL: https://issues.jboss.org/browse/WFCORE-3327
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Remoting
> Affects Versions: 3.0.3.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 4.0.0.Beta1
>
>
> The org.wildfly.remoting.endpoint capability is reported by the /subsystem=remoting resource, but it is the /subsystem=remoting/configuration=endpoint that actually configures it. This is confusing for humans and difficult for tooling like the new provisioning tools.
> The configuration=endpoint child is essentially a singleton and internally it just provides configuration to its parent. Further, if the user does not configure this resource, a default one is added automatically. This child resources is really just a configuration chunk for its parent.
> In the end it is the parent resource that actually provides the capability, by installing a service. It reads its child resource to configure the capability.
> There are a couple possibilities here:
> 1) Simply move the declaration of the capability to the child resource. Per discussion with [~aloubyansky] is seems that solves the tool problem. It leaves the actual situation obscure though, because now a seemingly non-required child resource is the thing that provides a capability that actually will always be present.
> 2) Deprecate that child resource and add a complex attribute to the parent. The child resource continues to exist in the API for compatibility reasons, but simply modifies the attribute on the parent. The cap remains on the parent.
> Note that 2) may require some manipulation of how we handle undefined complex attributes; i.e. that when we resolve them, even if the root attribute is undefined, we need to resolve the fields, in case those have default values, with the resolved parent then including the default field values. That can be tricky though, e.g. in cases of things like the defaulted attribute having requires, or other fields in the complex attribute being required.
> This latter point is relevant because it would be a 'worker' field in a complex attribute that would actually declare the name of the needed io worker capability. That field would have a default value 'default'.
> Perhaps the declaration of the complex attribute itself (i.e. ObjectTypeAttributeDefinition) would need to indicate how things should be handled. That could just be the complex attribute itself has a default value, {"worker"=>"default"}. Or it could be a flag that enables looking at the fields for defaults if the top level attribute is undefined. Or maybe investigation will show this isn't a problem at all.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 7 months
[JBoss JIRA] (WFLY-9409) mapping runtime attribute of undertow returns different type than described in r-r-d
by Claudio Miranda (JIRA)
Claudio Miranda created WFLY-9409:
-------------------------------------
Summary: mapping runtime attribute of undertow returns different type than described in r-r-d
Key: WFLY-9409
URL: https://issues.jboss.org/browse/WFLY-9409
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Reporter: Claudio Miranda
Assignee: Stuart Douglas
Priority: Minor
there is a "mappings" runtime attribute on undertow subsystem at
/host=master/server=server-one/deployment=batch-processing.war/subsystem=undertow/servlet=*:read-resource-description
It reports as a LIST of STRING
{code}
"mappings" => {
"type" => LIST,
"description" => "Servlet mappings",
"expressions-allowed" => false,
"required" => false,
"nillable" => true,
"min-length" => 0L,
"max-length" => 2147483647L,
"value-type" => STRING,
"access-type" => "metric",
"storage" => "runtime"
},
{code}
But the read-resource returns a INT
{code}
/host=master/server=server-one/deployment=helloworld.war/subsystem=undertow/servlet=*:read-resource(include-runtime)
{
"outcome" => "success",
"result" => [{
"address" => [
("host" => "master"),
("server" => "server-one"),
("deployment" => "helloworld.war"),
("subsystem" => "undertow"),
("servlet" => "org.jboss.as.quickstarts.helloworld.HelloWorldServlet")
],
"outcome" => "success",
"result" => {
"mappings" => 0,
"max-request-time" => 0,
"min-request-time" => 0,
"request-count" => 0,
"servlet-class" => "org.jboss.as.quickstarts.helloworld.HelloWorldServlet",
"servlet-name" => "org.jboss.as.quickstarts.helloworld.HelloWorldServlet",
"total-request-time" => 0
}
}]
}
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 7 months
[JBoss JIRA] (WFCORE-3327) Confusing between recording of the org.wildfly.remoting.endpoint and the resource that configures it
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3327?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-3327:
------------------------------------------
Despite being a ton more work, I think 2) is likely the way to go here. The 1) solution is somewhat papering over the problem, making something already overly obscure and difficult even more so.
> Confusing between recording of the org.wildfly.remoting.endpoint and the resource that configures it
> ----------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3327
> URL: https://issues.jboss.org/browse/WFCORE-3327
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Remoting
> Affects Versions: 3.0.3.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 4.0.0.Beta1
>
>
> The org.wildfly.remoting.endpoint capability is reported by the /subsystem=remoting resource, but it is the /subsystem=remoting/configuration=endpoint that actually configures it. This is confusing for humans and difficult for tooling like the new provisioning tools.
> The configuration=endpoint child is essentially a singleton and internally it just provides configuration to its parent. Further, if the user does not configure this resource, a default one is added automatically. This child resources is really just a configuration chunk for its parent.
> In the end it is the parent resource that actually provides the capability, by installing a service. It reads its child resource to configure the capability.
> There are a couple possibilities here:
> 1) Simply move the declaration of the capability to the child resource. Per discussion with [~aloubyansky] is seems that solves the tool problem. It leaves the actual situation obscure though, because now a seemingly non-required child resource is the thing that provides a capability that actually will always be present.
> 2) Deprecate that child resource and add a complex attribute to the parent. The child resource continues to exist in the API for compatibility reasons, but simply modifies the attribute on the parent. The cap remains on the parent.
> Note that 2) may require some manipulation of how we handle undefined complex attributes; i.e. that when we resolve them, even if the root attribute is undefined, we need to resolve the fields, in case those have default values, with the resolved parent then including the default field values. That can be tricky though, e.g. in cases of things like the defaulted attribute having requires, or other fields in the complex attribute being required.
> This latter point is relevant because it would be a 'worker' field in a complex attribute that would actually declare the name of the needed io worker capability. That field would have a default value 'default'.
> Perhaps the declaration of the complex attribute itself (i.e. ObjectTypeAttributeDefinition) would need to indicate how things should be handled. That could just be the complex attribute itself has a default value, {"worker"=>"default"}. Or it could be a flag that enables looking at the fields for defaults if the top level attribute is undefined. Or maybe investigation will show this isn't a problem at all.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 7 months
[JBoss JIRA] (WFCORE-3327) Confusing between recording of the org.wildfly.remoting.endpoint and the resource that configures it
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-3327:
----------------------------------------
Summary: Confusing between recording of the org.wildfly.remoting.endpoint and the resource that configures it
Key: WFCORE-3327
URL: https://issues.jboss.org/browse/WFCORE-3327
Project: WildFly Core
Issue Type: Bug
Components: Domain Management, Remoting
Affects Versions: 3.0.3.Final
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 4.0.0.Beta1
The org.wildfly.remoting.endpoint capability is reported by the /subsystem=remoting resource, but it is the /subsystem=remoting/configuration=endpoint that actually configures it. This is confusing for humans and difficult for tooling like the new provisioning tools.
The configuration=endpoint child is essentially a singleton and internally it just provides configuration to its parent. Further, if the user does not configure this resource, a default one is added automatically. This child resources is really just a configuration chunk for its parent.
In the end it is the parent resource that actually provides the capability, by installing a service. It reads its child resource to configure the capability.
There are a couple possibilities here:
1) Simply move the declaration of the capability to the child resource. Per discussion with [~aloubyansky] is seems that solves the tool problem. It leaves the actual situation obscure though, because now a seemingly non-required child resource is the thing that provides a capability that actually will always be present.
2) Deprecate that child resource and add a complex attribute to the parent. The child resource continues to exist in the API for compatibility reasons, but simply modifies the attribute on the parent. The cap remains on the parent.
Note that 2) may require some manipulation of how we handle undefined complex attributes; i.e. that when we resolve them, even if the root attribute is undefined, we need to resolve the fields, in case those have default values, with the resolved parent then including the default field values. That can be tricky though, e.g. in cases of things like the defaulted attribute having requires, or other fields in the complex attribute being required.
This latter point is relevant because it would be a 'worker' field in a complex attribute that would actually declare the name of the needed io worker capability. That field would have a default value 'default'.
Perhaps the declaration of the complex attribute itself (i.e. ObjectTypeAttributeDefinition) would need to indicate how things should be handled. That could just be the complex attribute itself has a default value, {"worker"=>"default"}. Or it could be a flag that enables looking at the fields for defaults if the top level attribute is undefined. Or maybe investigation will show this isn't a problem at all.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 7 months