[JBoss JIRA] (WFCORE-826) List-* operations should accept also objects as value
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-826?page=com.atlassian.jira.plugin... ]
James Perkins updated WFCORE-826:
---------------------------------
Fix Version/s: 2.0.0.CR1
(was: 2.0.0.Beta5)
> List-* operations should accept also objects as value
> -----------------------------------------------------
>
> Key: WFCORE-826
> URL: https://issues.jboss.org/browse/WFCORE-826
> Project: WildFly Core
> Issue Type: Sub-task
> Components: Domain Management
> Reporter: Tomaz Cerar
> Assignee: Tomaz Cerar
> Fix For: 2.0.0.CR1
>
>
> in case where list contains objects and not just simple types
> list operations complain:
> example:
> {noformat}
> [standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default:list-add(name=incoming-interceptors, value={name=foo,module=bar})
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0097: Wrong type for value. Expected [STRING] but was OBJECT",
> "rolled-back" => true
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (WFCORE-785) Improve capability related error messages
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-785?page=com.atlassian.jira.plugin... ]
James Perkins updated WFCORE-785:
---------------------------------
Fix Version/s: 2.0.0.CR1
(was: 2.0.0.Beta5)
> Improve capability related error messages
> -----------------------------------------
>
> Key: WFCORE-785
> URL: https://issues.jboss.org/browse/WFCORE-785
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 2.0.0.CR1
>
>
> When operation handlers request non-existent capabilities, the error messages aren't particularly helpful. For example:
> /"WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0364: Capability 'org.wildfly.data-source.invalid' is unknown."
> This is largely because it's the CapabilityRegistry that throws the exceptions, and it doesn't have much context about why the capability is needed to use in a better error message.
> Likely solutions are:
> 1) If CapabilityRegistryImpl has more context than is being used, look into using it.
> 2) Provide more context to CapabilityRegistry (I don't much like this one; providing parameters to a call only for use in a failure message is smelly to me.)
> 3) Use a custom exception type when the capability is missing, instead of ISE, and have OperationContextImpl catch that and add contextual information.
> I expect 3) is the likely solution.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (WFCORE-628) Support for 'query' operation on legacy slaves
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-628?page=com.atlassian.jira.plugin... ]
James Perkins updated WFCORE-628:
---------------------------------
Fix Version/s: 2.0.0.CR1
(was: 2.0.0.Beta5)
> Support for 'query' operation on legacy slaves
> ----------------------------------------------
>
> Key: WFCORE-628
> URL: https://issues.jboss.org/browse/WFCORE-628
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Priority: Critical
> Fix For: 2.0.0.CR1
>
>
> WFCORE-287 will introduce a new 'query' operation. But in a mixed domain, slaves running legacy versions will not understand that operation. So the console, when managing such a domain will either need to analyze the management API version of each host and not target 'query' ops to legacy hosts, or we need to figure out a way to emulate support on the DC.
> One thought I had was to use a transformer. My understanding of how query works is it's essentially a read-resource and then some post-processing is applied to filter the result. So my thought is an operation transformer can convert the query op to a read-resource op, which the slave will understand, and then a result transformer on the DC does the filtering work.
> There may of course be gotchas there.
> One issue I see is I think this query op is going to be a global op. I don't believe we currently have hooks for registering transformers for global ops. That is, there's nothing like the 'inherited' handling we use for registering the handler for the global op and then discovering it when resolving the operation name against child resource registrations.
> Another issue to remember is 'query' op will support wildcard addresses, so the result transformer will need to understand how to detect and deal with the different result format from a wildcard read-resource (result is a LIST of OBJECT) versus a simple read-resource (just an OBJECT).
> It's better if the filtering is done as soon as possible (to save the cost of transmitting data from servers to slaves to the DC just so the DC can filter) but for this mixed domain case I think it's ok to send the full read-resource result back to the DC.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (WFCORE-621) Support legacy slaves when invoking wildcard reads in a domain
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-621?page=com.atlassian.jira.plugin... ]
James Perkins updated WFCORE-621:
---------------------------------
Fix Version/s: 2.0.0.CR1
(was: 2.0.0.Beta5)
> Support legacy slaves when invoking wildcard reads in a domain
> --------------------------------------------------------------
>
> Key: WFCORE-621
> URL: https://issues.jboss.org/browse/WFCORE-621
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Priority: Critical
> Fix For: 2.0.0.CR1
>
>
> This is a follow-on to WFCORE-282.
> The WFCORE-282 will not work for requests with address patterns /host=*/server=* or /host=somename/server=* if the host named 'somename' is running a WFCORE version prior to 1.0.0.CR1 (or whatever release first has WFCORE-282 introduced.)
> In particular, it won't work with slaves running EAP 6.x.
> The problem is with either of those address patterns the DC will send a request addressed to /host=somename/server=* to the slave, and the slave will not be able to handle it, as it won't have the WFCORE-282 logic that lets it identify the relevant servers and send requests on to them.
> Potentially this could be fixed by having the DC detect these patterns and not call /host=somename/server=*, instead adding a step to read the server child names from /host=somename and then call /host=somename/server=a, /host=somename/server=b, etc.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (WFCORE-910) Reading metrics with dots in their names blows up
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-910?page=com.atlassian.jira.plugin... ]
James Perkins updated WFCORE-910:
---------------------------------
Fix Version/s: 2.0.0.CR1
(was: 2.0.0.Beta5)
> Reading metrics with dots in their names blows up
> -------------------------------------------------
>
> Key: WFCORE-910
> URL: https://issues.jboss.org/browse/WFCORE-910
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Affects Versions: 2.0.0.Beta4
> Reporter: Kabir Khan
> Assignee: Tomaz Cerar
> Priority: Blocker
> Fix For: 2.0.0.CR1
>
>
> When doing a :read-resource(include-runtime=true,recursive=true) this blows up. Debugging shows that to be because e.g. the resource /subsystem=jgroups/channel=ee/protocol=UDP contains metrics called things like
> {code}
> "timer.keep_alive_time" => {
> "type" => LONG,
> "description" => "Timeout in ms to remove idle threads from the timer pool",
> "expressions-allowed" => false,
> "nillable" => false,
> "access-type" => "metric",
> "storage" => "runtime"
> },
> "timer.max_threads" => {
> "type" => INT,
> "description" => "Max thread pool size for the timer thread pool",
> "expressions-allowed" => false,
> "nillable" => false,
> "access-type" => "metric",
> "storage" => "runtime"
> },
> "timer.min_threads" => {
> "type" => INT,
> "description" => "Minimum thread pool size for the timer thread pool",
> "expressions-allowed" => false,
> "nillable" => false,
> "access-type" => "metric",
> "storage" => "runtime"
> },
> {code}
> i.e. they have a dot in their name. So when the r-r handler wants to read the attributes it in effect tries to do the following demonstrated by CLI commands:
> {code}
> [standalone@localhost:9990 /] /subsystem=jgroups/channel=ee/protocol=UDP:read-attribute(name=timer
> timer.keep_alive_time timer.min_threads timer.rejection_policy timer.wheel_size timer_queue_size timer_threads
> timer.max_threads timer.queue_max_size timer.tick_time timer_class timer_tasks timer_type
> [standalone@localhost:9990 /] /subsystem=jgroups/channel=ee/protocol=UDP:read-attribute(name=timer.max_threads)
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0201: Unknown attribute 'timer'",
> "rolled-back" => true
> }
> {code}
> I see ReadResourceHandler has some stuff to extract the attribute name if 'extended syntax' is used. So we have two options:
> 1) Ban dots in metric/attribute names
> 2) Add a workaround to fall back. In other words if ReadAttributeHandler thinks extended syntax is being used, and cannot find the extracted 'timer' attribute, then try the full non-extracted name, e.g. timer.max_threads, and only then error.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (WFCORE-933) Embedded server start commands are lacking argument validation
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-933?page=com.atlassian.jira.plugin... ]
Ken Wills commented on WFCORE-933:
----------------------------------
I'll get a fix in for this in both embedded server types.
> Embedded server start commands are lacking argument validation
> --------------------------------------------------------------
>
> Key: WFCORE-933
> URL: https://issues.jboss.org/browse/WFCORE-933
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Domain Management
> Affects Versions: 2.0.0.Beta4
> Reporter: Petr Kremensky
> Assignee: Ken Wills
> Priority: Minor
>
> Commands for starting embedded instances are lacking argument validation.
> {noformat}[disconnected /] embed-server foo
> [standalone@embedded /]
> [disconnected /] embed-server foo -foo
> [standalone@embedded /]
> [disconnected /] embed-server foo --foo
> [standalone@embedded /]
> [standalone@embedded /] stop-embedded-server foo
> The command accepts 0 unnamed argument(s) but received: [foo]
> [standalone@embedded /] stop-embedded-server -foo
> Unrecognized arguments: [-foo]
> [standalone@embedded /] stop-embedded-server --foo
> Unrecognized arguments: [--foo]{noformat}
> Same case for embedded host controller.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months