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(a)redhat.com <mailto: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 > <https://paste.fedoraproject.org/paste/4WGJ7%7EUpeJvR0tqtEDYfNg> > > 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. > > [1] https://issues.jboss.org/browse/WFCORE-3432. > [2] https://issues.jboss.org/browse/WFARQ-35 > > Cheers, > > -- > Brian Stansberry > Manager, Senior Principal Software Engineer > Red Hat _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev