Can the add handler just fail in this situation?
If the elements are going to be in the XSD but not work, it seems more
consistent to have them be in the management API and not work. Otherwise
you get odd disconnects, like CLI scripts failing with unhelpful generic
explanations about resource types not existing. Then if people look at the
xsd they see the documentation, or they look in wildscribe and see it.
Confusing, whereas a failure with a clear explanation is clear.
For sure we don't want the parser ignoring these elements with just a warn.
On Tue, Apr 20, 2021 at 7:39 AM Darran Lofthouse <darran.lofthouse(a)jboss.com>
In preparation for the eventual removal of the legacy security realms
would like to first reach an intermediate state where their use can be
Disabling the use of a subsystem is fairly easy, if we omit the jars
containing the extension and don't register the extension then the
subsystem is unavailable. The legacy security realms are a little
different as they are a part of core.
I think there are two situations I would like to disable them:
- Provisioned configurations where they are disabled.
- Certain environments e.g. Java 17
For the former I can easily do something like ServiceLoader discovery or
Class.forName to detect if required classes have been provisioned or not,
for the latter I can check the Java version at runtime,
I would propose that in the disabled cases the resources are just not
registered in the management model at all. These are not a
transformed resource so nothing special to consider there. For the XML
parsing if the legacy security realms are found in the configuration I
would then log an error to indicate they have been disabled and abort the
Technically it feels achievable, the only piece really that is not
accurate is the XML schema for management would still show these as valid
elements. Alternatively I could log a warning and ignore these elements
but that feels like it may cause more issues as users would be expecting
them to be handled and any future writes to the configuration would drop
wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org
Principal Architect, Red Hat JBoss EAP
If I am writing outside of normal office hours, it is my choice; you do not
need to do the same