[wildfly-dev] Capabilities enabled by attributes

Brian Stansberry brian.stansberry at redhat.com
Wed Aug 5 14:36:31 EDT 2015


On 8/5/15 1:08 PM, Scott Marlow wrote:
>
>
> 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?
>

Not specifically, but it's a good point to clarify. :)

The appclient issue is that the capability really CANNOT be provided in 
that process. It's not a setting of some attribute on a subsystem 
resource that toggles this; it's the fact that the process is not a 
server, it's an application client container, 
ProcessType.APPLICATION_CLIENT.

It's fine to not register a capability if the process type is 
ProcessType.APPLICATION_CLIENT.

I'm more looking for cases where, e.g. subsystem=jpa has attribute "foo" 
and if "foo" is set to 'true' a capability is registered, otherwise not.

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


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat


More information about the wildfly-dev mailing list