[jboss-jira] [JBoss JIRA] (WFLY-9587) Investigate and introduce capabilities for the transactional subsytems transations/xts/rts

[ https://issues.jboss.org/browse/WFLY-9587?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFLY-9587: ---------------------------------------- [~ochaloup] Hi! Just an FYI, long ago I did some experiments related to capabilities and the tx subsystem, mostly trying to work with real use cases in order to work out how the WFCORE stuff should work. I didn't carry on with doing stuff for the tx subsystem because working out what API the capabilities should expose was more than I could take on at the time. And working out that API is really the most important thing. In the tx case it could be a bit complicated. But anyway, FWIW https://github.com/bstansberry/wildfly/commits/use-cap-req has a couple tx-related commits that might have some useful bits and pieces or at least illustrate some things to think about. There are a couple interesting things about tx that I played with. (Note that that code is way way out of date so it should not serve as a reference for how to use capabilities.) The interesting bits were: 1) IIOP can consume a cap from tx in order to set up some corba interceptors. 99% of requirers of capabilities end up consuming an MSC service provided by the capability, but *maybe* this IIOP thing is a use case for the "Custom integration APIs provided by a capability" thing discussed on the "Working with WildFly Capabilities" document. TBH though, AFAIK no other code is using that stuff, while MSC services are really widely used. So if the corba interceptor thing can use a service without too much pain that might be better in the long run. Being the only use case for a bit of tech has it's downsides. ;) 2) IIOP and JTS have a circular relationship, which the capability stuff can support. It's unusual though. 3) Whether JTS is available depends on the setting of an attribute in a resource, rather than the existence of the resource. This is also a bit unusual (but allowed.) A bit of a twist though is unfortunately the 'jts' attribute allows expressions. When a management operation runs, all capabilities and requirements must be recorded in Stage.MODEL. But, if a vault expression is used, the expression cannot be reliably resolved until Stage.RUNTIME. For this reason, we now know to disallow expressions on attributes that control capabilities and requirements. In most cases that's not a problem as we guessed long ago that we shouldn't allow expressions on what we used to call "model reference attributes", e.g. things like "socket-binding=http". But this "jts" one is a different kind of case. We can't break compatibility by no longer allowing expressions for this attribute, but the presence of an expression *might* be a problem. The 3rd commit in that branch has some logic meant to deal with this. It might not be the best approach, but I regarded it as ok at the time. The problem really only exists if someone uses a vault expression for the 'jts' attribute. I regard that as an extreme corner case. So extreme that it's a tiny bit tempting to break compatibility and just fail if we hit it. -- This message was sent by Atlassian JIRA (v7.5.0#75005)