[wildfly-dev] Capabilities enabled by attributes

[Scott Marlow]

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."
>