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

[Brian Stansberry]

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.

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.

3) The management layer could somehow makes this data available to
subsystems so they could utilize it. So, the requiror sees the required cap
is not available in the current run level so it in turn doesn't try and
install its own cap. Instead logs a WARN or something.

This is the most work, and I have huge doubts about its wisdom. The
software no longer is reasonably predictable, where something is on or off
in a given run level; now it's or off depending on whether something else
is on or off.

For any of these we'll need to formalize our existing concepts into a solid
run-level concept. I don't think that should be too hard.

[1] https://github.com/wildfly/wildfly-capabilities

-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171212/b7986efb/attachment.html