Brian,

CLI has 3 calls to /deployment=x:read-resource that don't have include-runtime=true. But from what I see, if suddenly subsystems are not returned, it wouldn't change anything.

JF


On 28/11/17 20:17, Harald Pehl wrote:
I've checked HAL.next and we only use "include-runtime=true" when reading deployment related resources This applies for both standalone and domain mode. 

I didn't check HAL.current yet, but I'm quite sure we use the same semantics here. So fixing the bug shouldn't affect neither HAL.next nor HAL.current.  

Cheers
Harald

On 28. Nov 2017, at 19:16, Brian Stansberry <brian.stansberry@redhat.com> wrote:

Hi Harald,

Does HAL always include the "include-runtime=true" param when doing a read of resources under a /deployment=x resource?

I'm asking because I noticed an annoying problem when trying to do some cleanup of whether runtime-only resources correctly report themselves as such.[1] It turns out we have a bug where must subsystem resources under /deployment=* don't report themselves as runtime-only, which means they show up in an op like this, even though they should not:

https://paste.fedoraproject.org/paste/4WGJ7~UpeJvR0tqtEDYfNg

The "subsystem=undertow" child should not appear because the op used "include-runtime=false". So that's a bug.

I probably won't fix that bug any time soon, because "include-runtime=false" is the default behavior. Which mean this is a bug that some users may be counting on. :( One example being Arquillian -- see [2]. But I'm wondering whether HAL is an example of that. If it is, it's something that should be corrected. At some point we may have to correct this.

Jean-Francois Denise, I have the same question for you re: CLI.

Emmanuel Hugonnet -- I'm hoping this isn't a significant problem for your provisioning feature-spec work. If it is maybe we can find a way to work around. These resource types are not relevant on an admin-only server and my guess any feature-spec generation would use an admin-only process.


Cheers,

--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat



_______________________________________________
wildfly-dev mailing list
wildfly-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev