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.
On 28/11/17 20:17, Harald Pehl wrote:
I've checked HAL.next and we only use
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
> On 28. Nov 2017, at 19:16, Brian Stansberry
> <brian.stansberry(a)redhat.com <mailto:email@example.com>>
> 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. 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:
> 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 . 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.
>  https://issues.jboss.org/browse/WFCORE-3432
>  https://issues.jboss.org/browse/WFARQ-35
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat
wildfly-dev mailing list