On 07/24/2015 01:59 PM, Brian Stansberry wrote:
I would like to propose a requirement that if a particular type of
resource CAN provide a capability, then it MUST provide that capability
if it is created. There will be no such thing as a resource providing or
not providing a capability based on the value of one of its attributes.
My question to subsystem developers is whether they have a situation in
their configuration model where this will be a problem?
The EE client could have problems if subsystems are required to provide
a capability that it could provide. Some times, a subsystem is included
in the appclient.xml so that certain (subsystem related) classes are
added to the application deployment classpath.
Is the type of problem that your looking to hear about?
For any case where there is such an attribute, the requirement would
mean that a child resource would need to be created instead, and that
child resource would provide the capability. There are tricks we can use
to preserve the existing attribute to provide management API compatibility.
The only case I'm aware of where this is a factor is the 'jts' attribute
in the subsystem=transactions resource.
The reason for this requirement is we want tooling to be able to inspect
the types of resources that are available for use, see what capabilities
they provide and what requirements they have, and work out what
resources need to be present in a configuration in order to have a
consistent set of capabilities. That task is significantly more complex
if the presence of a capability is determined by some arbitrary
attribute value. David Lloyd described allowing attributes to control
this as being "like creating an RDBMS where you have foreign keys that
only exist if some function evaluates in a certain way."