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&gt; wrote: > In preparation for the eventual removal of the legacy security realms I > would like to first reach an intermediate state where their use can be > disabled. > > 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 > boot process. > > 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 > them anyway. > > Regards, > Darran Lofthouse. > > _______________________________________________ > wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org > To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s -- Brian Stansberry Principal Architect, Red Hat JBoss EAP He/Him/His If I am writing outside of normal office hours, it is my choice; you do not need to do the same

Also thinking about this, the vault configuration has the same issue in that it is a part of the core management model. I think it's "test condition" should be different but that sounds like it should also follow the same solution for now - i.e. allow the model representation to remain but disable the runtime implementation with appropriate warnings.

On Wed, Apr 21, 2021 at 9:22 AM Darran Lofthouse < darran.lofthouse(a)jboss.com&gt; wrote: > On Tue, Apr 20, 2021 at 11:47 PM Brian Stansberry < > brian.stansberry(a)redhat.com&gt; wrote: > >> 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. >> > > That may be better for WildFly 24 as a smaller step but I don't know if > it will lead to false assumption that these resources are still supported, > also although the CLI scripts and configuration may "work" the moment > something in the model references these realms it would fail as the > required service would not be available. > > It will probably still need a generous set of warnings if we see this. > > >> 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. >> > > I think documentation, wildscribe, and xsd would need some verbose > updates to identify that these resources are not usable in the situations > we describe. > > >> >> For sure we don't want the parser ignoring these elements with just a >> warn. >> > > Overall the end stage we are working towards is that these resources as > well as any attributes that reference these resources will be completely > removed from the next versions of the management models (domain management, > remoting, undertow, ...) > > So for now we will preserve the model and just disable the implementation > where it is not supported / available. > > >> >> On Tue, Apr 20, 2021 at 7:39 AM Darran Lofthouse < >> darran.lofthouse(a)jboss.com&gt; wrote: >> >>> In preparation for the eventual removal of the legacy security realms I >>> would like to first reach an intermediate state where their use can be >>> disabled. >>> >>> 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 >>> boot process. >>> >>> 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 >>> them anyway. >>> >>> Regards, >>> Darran Lofthouse. >>> >>> _______________________________________________ >>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s >> >> >> >> -- >> Brian Stansberry >> Principal Architect, Red Hat JBoss EAP >> He/Him/His >> If I am writing outside of normal office hours, it is my choice; you do >> not need to do the same >> >