You can include different wildcard reads as steps in a composite, if
that helps. The question is whether for each type of read, do you only
want specific resources (deployment=a.war,deployment=b.war), or do you
want all of that type?
Otherwise, yes, it would require a new feature to support ignoring
failures related to reading the configuration model.
Semi-OT: see
for some new
querying functionality available in WF 10.
On 6/11/15 3:50 PM, John Mazzitelli wrote:
> /deployment=*:read-attribute(name=status,include-runtime=true)
Problem there is that would assume I am asking for the same attribute on the same type of
resource.
I'm monitoring pretty much everything (ok, not EVERYTHING), but the point is I might
be collecting one attribute for the transaction manager, one on a datasource, and one on a
deployment - different attributes across different types - but I'm collecting them all
at the same time. So I would like to do a bulk collection and just issue one request -
but it sounds like I need to split it up and shotgun N requests each asking for a singular
attribute value.
----- Original Message -----
> Try this:
>
> /deployment=*:read-attribute(name=status,include-runtime=true)
>
> The composite op won't allow you to tell it ignore failures in reading
> the configuration model.
>
> On 6/11/15 2:30 PM, John Mazzitelli wrote:
>> FWIW: this is what the response would look like in my example if a.war was
>> undeployed:
>>
>> {
>> "outcome" => "failed",
>> "result" => {
>> "step-1" => {
>> "outcome" => "failed",
>> "failure-description" => "JBAS014807: Management
resource
>> '[(\"deployment\" => \"a.war\")]'
not found",
>> "rolled-back" => true
>> },
>> "step-2" => {"outcome" => undefined}
>> },
>> "failure-description" => {"JBAS014653: Composite
operation failed and
>> was rolled back. Steps that failed:" => {"Operation
step-1" =>
>> "JBAS014807: Management resource '[(\"deployment\" =>
\"a.war\")]'
>> not found"}},
>> "rolled-back" => true
>> }
>>
>> ----- Original Message -----
>>> Here's the use case: a monitoring app wants to monitor a WildFly
instance
>>> -
>>> it will ask WildFly for the values of N attributes across M resources in
>>> one
>>> bulk composite request. This would avoid having to send one request for
>>> each
>>> individual attribute being collected (rather than one request for all of
>>> them at once).
>>>
>>> Is there a way I can configure a composite request such that WildFly will
>>> not
>>> abort the entire composite request if a single step to read an attribute
>>> fails?
>>>
>>> For example, suppose I send this - I'm basically asking Wildfly
"tell me
>>> the
>>> status of my two deployed applications a.war and b.war" :
>>>
>>> {
>>> "operation" => "composite",
>>> "address" => [],
>>> "steps" => [
>>> {
>>> "operation" => "read-attribute",
>>> "address" => [("deployment" =>
"a.war")],
>>> "include-runtime" => false,
>>> "name" => "status"
>>> },
>>> {
>>> "operation" => "read-attribute",
>>> "address" => [("deployment" =>
"b.war")],
>>> "include-runtime" => false,
>>> "name" => "status"
>>> }
>>> ]
>>> }
>>>
>>> Well, if someone undeployed a.war, that first step results in an error,
>>> but
>>> it also completely aborts the composite operation so I can't find the
>>> status
>>> of b.war either, unless a.war exists.
>>>
>>> I would like composites like this to tell me the status of every
>>> read-attribute - whether a failure or not. If not possible, I'm forced
to
>>> split this up and make two individual requests for each attribute.
>>>
>>> Extrapolate that out - if I have N attributes I want to collect at the
>>> same
>>> time, I would be forced to make N individual requests rather than 1
>>> composite request just to avoid the case where if one of them failed, I
>>> would lose the data for all N.
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>