[
https://issues.jboss.org/browse/WFLY-9587?page=com.atlassian.jira.plugin....
]
Brian Stansberry commented on WFLY-9587:
----------------------------------------
Re: jts, for expressions we had a pretty simple policy. All attributes must support
expressions except those whose value:
1) Is a model reference (e.g. socket-binding=http).
2) Is a class or module name.
We had a simple policy because otherwise we'd end up with a really inconsistent API
where different devs make different decisions about expression support, often coming down
to "I don't think it's really needed for this one." That's what we
had in AS 7.1 / EAP 6.0 which led to quite a number of bug reports where users disagreed
and wanted the expression. We added the current policy in AS 7.2.
Now I think we need a 3rd category:
3) Controls whether an optional capability is installed or an optional requirement is
added.
I believe there are only a few such attributes, maybe just this one. But I'm reluctant
to break compatibility and drop expressions support altogether, not when it can be made to
work for all but the real corner case of using a vault expression. Logging some sort of
"expression deprecation" thing would be good though; something to help state
that we advise against using an expression, helping to drive users away from it so that if
we need to in some future release we can drop support and clean things out. For
WFCORE-887 I have a similar need. I'll look into making the solution to that easily
adapted to other cases. For example, just call setExpressionDeprecated() on the
AttributeDefinition builder and then the kernel handles the logging.
Investigate and introduce capabilities for the transactional
subsytems transations/xts/rts
------------------------------------------------------------------------------------------
Key: WFLY-9587
URL:
https://issues.jboss.org/browse/WFLY-9587
Project: WildFly
Issue Type: Feature Request
Components: Transactions, XTS
Affects Versions: 11.0.0.Final
Reporter: Ondra Chaloupka
Assignee: Ondra Chaloupka
The notion of capability is not introduced to the transactional system. The WFLY
integration expecting subsystem providing it. The transaction subsystems should support
so.
https://docs.jboss.org/author/display/WFLY/Working+with+WildFly+Capabilities
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)