<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">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. <div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">Cheers</div><div class="">Harald</div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 28. Nov 2017, at 19:16, Brian Stansberry <<a href="mailto:brian.stansberry@redhat.com" class="">brian.stansberry@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi Harald,<div class=""><br class=""></div><div class="">Does HAL always include the "include-runtime=true" param when doing a read of resources under a /deployment=x resource?</div><div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class=""><p class="gmail-p1"><a href="https://paste.fedoraproject.org/paste/4WGJ7~UpeJvR0tqtEDYfNg" class="">https://paste.fedoraproject.org/paste/4WGJ7~UpeJvR0tqtEDYfNg</a><br class=""></p><p class="gmail-p1">The "subsystem=undertow" child should not appear because the op used "include-runtime=false". So that's a bug.<br class=""></p><p class="gmail-p1">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.</p><p class="gmail-p1">Jean-Francois Denise, I have the same question for you re: CLI.<br class=""></p><p class="gmail-p1">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.</p></div><div class="">[1] <a href="https://issues.jboss.org/browse/WFCORE-3432" class="">https://issues.jboss.org/browse/WFCORE-3432</a>. </div><div class="">[2] <a href="https://issues.jboss.org/browse/WFARQ-35" class="">https://issues.jboss.org/browse/WFARQ-35</a></div><div class=""><br class=""></div><div class="">Cheers,</div><div class=""><br class="">-- <br class=""><div class="gmail_signature"><div dir="ltr" class="">Brian Stansberry<div class="">Manager, Senior Principal Software Engineer</div><div class="">Red Hat</div></div></div>
</div></div>
</div></blockquote></div><br class=""></div></body></html>