[ https://issues.jboss.org/browse/JBTM-2891?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka edited comment on JBTM-2891 at 4/26/17 6:41 AM: ---------------------------------------------------------------- I was already experimenting with this a little bit based on my fix for the quickstart (WFLY-8592) but I found that method {{getAllKnownImplementors}} does not consider interface inheritance. Thus for the hierarchy structure is like {code} (deployment class) -> com.arjuna.wst.Durable2PCParticipant/Volatile2PCParticipant -> com.arjuna.wst.Participant. {code} call {code} compositeIndex.getAllKnownImplementors(DotName.createSimple(com.arjuna.wst.Participant.class.getName())) {code} returns nothing. I discussed this with Jason and it's expected behavior and he suggested two ways (quoting him) {quote} There are two solutions I can think of to this A) Human hard coding of the Naryana inheritance hierarchy of that interface into the XTS deployer - assumes that it changes infrequently, or is it least done via a component update of Naryana B) A small custom maven plugin in the wildfly build for the transaction subsystem that generates Java source or a data file that achieves whats described in A) that can be called by the subsystem code. In the case of Java code, the subsystem code would just refer to a base type or an interface, and then dynamically load the generated implementation class. The maven plugin could use Jandex, some other bytecode analysis framework, or even Java reflection to discover the relevant types. {quote} I think that the option {{A}} is easier and expected one. The interfaces is not expected to be changed. was (Author: ochaloup): I was already experimenting with this a little bit based on my fix for the quickstart (WFLY-8592) but I found that method {{getAllKnownImplementors}} does not consider interface inheritance. Thus for the hierarchy structure is like {code} (deployment class) -> com.arjuna.wst.Durable2PCParticipant/Volatile2PCParticipant -> com.arjuna.wst.Participant. {code} call {code} compositeIndex.getAllKnownImplementors(DotName.createSimple(com.arjuna.wst.Participant.class.getName())) {code} returns nothing. I discussed this with Jason and it's expected behavior and he suggested two ways (quoting him) {quote} There are two solutions I can think of to this A) Human hard coding of the Naryana inheritance hierarchy of that interface into the XTS deployer - Assumes that it changes infrequently, or is it least done via a component update of Naryana B) A small custom maven plugin in the wildfly build for the transaction subsystem that generates Java source or a data file that achieves whats described in A) that can be called by the subsystem code. In the case of Java code, the subsystem code would just refer to a base type or an interface, and then dynamically load the generated implementation class. The maven plugin could use Jandex, some other bytecode analysis framework, or even Java reflection to discover the relevant types. {quote} I think that the option {{A}} is easier and expected one. The interfaces is not expected to be changed. -- This message was sent by Atlassian JIRA (v7.2.3#72005)