[wildfly-dev] Run level as a factor for capabilities and requirements?

[Darran Lofthouse]

Before a change to capabilities and requirements I think this idea of a
running mode is something to consider in general.

As we talk about which modes a runtime handler is going to execute within
we generally seem to be able to talk in terms of named modes - but when it
comes to code within the application server we have some utility methods
e.g. isNormalServer but then in other cases we have more complex boolean
expressions to test the 'mode'.  Sometimes it feels like we could use a
better way for this test.

Regards,
Darran Lofthouse.


On Tue, 12 Dec 2017 at 22:26 David Lloyd <david.lloyd at redhat.com> wrote:

> On Tue, Dec 12, 2017 at 11:15 AM, Brian Stansberry
> <brian.stansberry at redhat.com> wrote:
> > Something the current capabilities/requirements stuff doesn't handle is
> the
> > fact that some capabilities can be configured but won't be turned on in
> some
> > situations (i.e. admin-only). Which means other capabilities that might
> > require them and that are present in admin-only will pass configuration
> > consistency checks but will fail at runtime.
> >
> > I'm not sure what to do about this. Some off the top of my head thoughts:
> >
> > 1) The capability description data on wildly-capabilities includes
> something
> > about this, so people who want to require the capability understand
> whether
> > it can be required.
> >
> > This is easy, and helps avoids future bugs. It's just documentation so it
> > does nothing about the actual server behavior.
> >
> > 2) The registration for capabilities could include "minimal running-mode"
> > data, and then the capability resolution could check that and fail if it
> > finds a mismatch in the current running mode.
>
> I'm inclined towards this option.  But...
>
> > This is more work obviously. It may help surface problems earlier, i.e.
> make
> > it more likely that a testsuite catches a mismatch in time to correct it
> > before a .Final release. It would also have the minor benefit of perhaps
> > providing a better error message for a user who configures a mismatch.
>
> It'd be best if we can detect this more up front if possible.  If this
> kind of mismatch occurs, I think it would never be the user's fault.
>
> --
> - DML
> _______________________________________________
> 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/20171213/02e5d670/attachment-0001.html