[wildfly-dev] Reads of subsystem resources under a /deployment=x resource

[Jean-Francois Denise]

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 at redhat.com <mailto:brian.stansberry at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171128/041d07ad/attachment.html