<div dir="ltr">Something to consider with regards to migration, or possibly even the notifications depending on the configuration, is having it as a subsystem/extension gives the user the option to remove the subsystem and/or extension. In some cases that might be okay, but others the resource might be required. For example I believe the console and possibly CLI are using the /core-management=capability-registry resource to query information about capabilities.<div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 20, 2016 at 5:39 AM, Jeff Mesnil <span dir="ltr"><<a href="mailto:jmesnil@redhat.com" target="_blank">jmesnil@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
TL;DR let's add a new subsystem to wildly-core to add new management-related resources instead of putting them in /core-service=management. Let's do that for WFLY 11.<br>
<br>
# Use case<br>
<br>
For WildFly 11, I have planned a new feature[1] to be able to notify user code when the state of the server changes (running, reload-required, etc.).<br>
Until now this kind of resources related to the server management were put under /core-service=management.<br>
However, this resource does not have well-defined semantic (e.g. what's the meaning of /core-service=management for a DC?).<br>
Brian proposed to stop putting resources under this resource and add a new subsystem instead. This will clarify the semantic of the resources and uniformize the configuration and management of WildFly.<br>
<br>
I propose to create a new extension in wildfly-core project to provide new management resources.<br>
It will be the *successor* of /core-service=management (i.e. we stop adding *new* resources to /core-service=management).<br>
This will not be a replacement for /core-service=management. Current resources under /core-service=management will remain there for WildFly 11.<br>
<br>
I have no strong opinion about what doing after that: we can move/migrate them under the new subsystem, redirect them using alias or do nothing.<br>
Some resource related to security will be deprecated by Elytron so doing nothing sounds correct for them.<br>
Moving everything else to the new subsystem sounds a worthy goal but I have no idea of the actual effort to do so (and ensure that we remain compatible). The time and energy spent on this may not be worthwhile...<br>
<br>
# What is the scope of this subsystem?<br>
<br>
The scope would be identical to the /core-service=management resource.<br>
Using a subsystem just make sure we have well-defined semantics for the resources underneath it. It also moves us towards the goal of extending WildFly in an uniform way instead of adding special resources outside of our extension API.<br>
<br>
It is *not* a subsystem to manage WildFly or deployed applications à la JMX or JSR 77.<br>
<br>
# What is the name of this subsystem?<br>
<br>
The intuitive name would be /subsystem=management but I don't think it is a good name. It is too generic (does it expose a management API à la JMX? does it provide management features based on other project such as Hawkular?) and I don't think we should own such general term (even though we do have such general subsystem names such as io, security, logging).<br>
<br>
If we follow the current convention, the name could be /subsystem=management-wildfly (feature + name of project providing the feature) but it does not sound good. The subsystem provides a way to manage WildFly, it does not provide a management feature *using* WildFly (this could also clash with name of the extension if/when we implement Java EE Management API 2.0[2]).<br>
I prefer */subsystem=core-management* (or /subsystem=wildfly-management as a 2nd choice).<br>
<br>
We have identified a few resources that are good candidates for this new resource:<br>
<br>
* the feature to notify user code of server stat changes[1]<br>
* Elytron needs a new access=identity resource[3]<br>
<br>
# Roadmap<br>
<br>
I propose to create asap an empty subsystem as a first step so that Elytron feature is not blocked by the development of my own feature (It should be a single commit on wildfly-core and can be fit in Elytron PRs if needed).<br>
Then, we can have different PRs for new management resources that fits in this new subsystem.<br>
<br>
We've also identified a simple management resource to evaluate the cost of moving/migrating/redirecting resources with the service=configuration-changes[<wbr>4] and their implications for compatibility.<br>
<br>
Would you guys agree with that proposal?<br>
<br>
[1] <a href="https://issues.jboss.org/browse/WFCORE-1405" rel="noreferrer" target="_blank">https://issues.jboss.org/<wbr>browse/WFCORE-1405</a><br>
[2] <a href="https://www.jcp.org/en/jsr/detail?id=373" rel="noreferrer" target="_blank">https://www.jcp.org/en/jsr/<wbr>detail?id=373</a><br>
[3] <a href="https://developer.jboss.org/wiki/EnablingWildFlyElytronForManagementSecurity" rel="noreferrer" target="_blank">https://developer.jboss.org/<wbr>wiki/<wbr>EnablingWildFlyElytronForManag<wbr>ementSecurity</a><br>
[4] <a href="https://issues.jboss.org/browse/WFCORE-1642" rel="noreferrer" target="_blank">https://issues.jboss.org/<wbr>browse/WFCORE-1642</a><br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
--<br>
Jeff Mesnil<br>
JBoss, a division of Red Hat<br>
<a href="http://jmesnil.net/" rel="noreferrer" target="_blank">http://jmesnil.net/</a><br>
<br>
<br>
______________________________<wbr>_________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/wildfly-dev</a></font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>James R. Perkins</div><div>JBoss by Red Hat</div></div></div></div></div>
</div></div>