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,
It's fine to not register a capability if the process type is
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
> 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
> 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."
Senior Principal Software Engineer
JBoss by Red Hat