[
https://issues.redhat.com/browse/WFCORE-5036?page=com.atlassian.jira.plug...
]
Richard Achmatowicz updated WFCORE-5036:
----------------------------------------
Description:
Not sure if this is a (useability) bug or a feature request, so I have marked it as a
feature request.
Implementing capabilities which represent a resource associated with an attribute which
may or may not need to be defined is problematic, as once the capability is defined in the
resource, we need to do custom registration and custom de-registration based on whether
the condition holds or not. Custom registration needs to happen in the add handler for the
resource as well as write handler for the attribute. Custom de-registration needs to
happen in the remove handler and is complicated by the fact that de-registration of
resources happens before de-registration of capabilities (should be the other way
around?). Once this capability is conditionally registered, we can use
OperationContext.hasOptionalCapability() to check if it is actually registered. So
consuming is easy but setting up is hard.
Here is an example. EJB3SubsystemRootResourceDefinition has an attribute called
default-slsb-instance-pool which gives the name of a defined strict-max-pool instance to
be used as a default value for SLSBs. This attribute has no default and may be defined or
not. When it is defined, it is used to generate a service name and that service name is
added as a dependency for SLSBs which have no custom pool specified in their
configuration.
Defining and registering the capability based on whether the attribute is defined or not
leads to the problems described above, AFAIK.
This is not an uncommon use case; it would be nice if defining capabilities for such
optional attributes were easier.
FYI: The clustering subsystem runs into this issue quite often and has worked around the
problem by associating predicates with capabilities which can be used at registration time
to see if a capability should be defined by evaluating the predicate.
was:
Not sure if this is a (useability) bug or a feature request, so I have marked it as a
feature request.
Implementing capabilities which represent a resource associated with an attribute which
may or may not need to be defined is problematic, as once the capability is defined in the
resource, we need to do custom registration and custom de-registration based on whether
the condition holds or not. Custom registration needs to happen in the add handler for the
resource as well as write handler for the attribute. Custom de-registration needs to
happen in the remove handler and is complicated by the fact that de-registration of
resources happens before de-registration of capabilities (should be the other way
around?). Once this capability is conditionally defined, we can use
OperationContext.hasOptionalCapability() to check if it is defined. So consuming is easy
but setting up is hard.
Here is an example. EJB3SubsystemRootResourceDefinition has an attribute called
default-slsb-instance-pool which gives the name of a defined strict-max-pool instance to
be used as a default value for SLSBs. This attribute has no default and may be defined or
not. When it is defined, it is used to generate a service name and that service name is
added as a dependency for SLSBs which have no custom pool specified in their
configuration.
Defining and registering the capability based on whether the attribute is defined or not
leads to the problems described above, AFAIK.
This is not an uncommon use case; it would be nice if defining capabilities for such
optional attributes were easier.
FYI: The clustering subsystem runs into this issue quite often and has worked around the
problem by associating predicates with capabilities which can be used at registration time
to see if a capability should be defined by evaluating the predicate.
Improve support for conditionally-defined capabilities
------------------------------------------------------
Key: WFCORE-5036
URL:
https://issues.redhat.com/browse/WFCORE-5036
Project: WildFly Core
Issue Type: Feature Request
Components: Management
Reporter: Richard Achmatowicz
Assignee: Jeff Mesnil
Priority: Major
Not sure if this is a (useability) bug or a feature request, so I have marked it as a
feature request.
Implementing capabilities which represent a resource associated with an attribute which
may or may not need to be defined is problematic, as once the capability is defined in the
resource, we need to do custom registration and custom de-registration based on whether
the condition holds or not. Custom registration needs to happen in the add handler for the
resource as well as write handler for the attribute. Custom de-registration needs to
happen in the remove handler and is complicated by the fact that de-registration of
resources happens before de-registration of capabilities (should be the other way
around?). Once this capability is conditionally registered, we can use
OperationContext.hasOptionalCapability() to check if it is actually registered. So
consuming is easy but setting up is hard.
Here is an example. EJB3SubsystemRootResourceDefinition has an attribute called
default-slsb-instance-pool which gives the name of a defined strict-max-pool instance to
be used as a default value for SLSBs. This attribute has no default and may be defined or
not. When it is defined, it is used to generate a service name and that service name is
added as a dependency for SLSBs which have no custom pool specified in their
configuration.
Defining and registering the capability based on whether the attribute is defined or not
leads to the problems described above, AFAIK.
This is not an uncommon use case; it would be nice if defining capabilities for such
optional attributes were easier.
FYI: The clustering subsystem runs into this issue quite often and has worked around the
problem by associating predicates with capabilities which can be used at registration time
to see if a capability should be defined by evaluating the predicate.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)