[jbossts-issues] [JBoss JIRA] (JBTM-2891) Default dependency on org.jboss.xts could be added to WFLY deployements using XTS interfaces

[Ondra Chaloupka (JIRA)]

    [ https://issues.jboss.org/browse/JBTM-2891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13398273#comment-13398273 ] 

Ondra Chaloupka commented on JBTM-2891:
---------------------------------------

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.




> Default dependency on org.jboss.xts could be added to WFLY deployements using XTS interfaces
> --------------------------------------------------------------------------------------------
>
>                 Key: JBTM-2891
>                 URL: https://issues.jboss.org/browse/JBTM-2891
>             Project: JBoss Transaction Manager
>          Issue Type: Enhancement
>          Components: XTS
>    Affects Versions: 5.5.24.Final
>            Reporter: Ondra Chaloupka
>            Assignee: Ondra Chaloupka
>
> WildFly currently adds default dependency for {{org.jboss.xts}} module when deployment defines some of the compensations annotation. Provided by {{XTSDependenciesDeploymentProcessor}} see https://github.com/wildfly/wildfly/blob/master/xts/src/main/java/org/jboss/as/xts/XTSDependenciesDeploymentProcessor.java#L58 (in fact XTS dependency is needed only when compensating framework works in distributed manner but it's absolutely ok by my point of view to add the dependency as it's currently done).
> But if deployment uses just XTS interfaces and defines WS handlers in descriptor then user is forced to apply the dependency on its own.
> E.g. eap quickstarts does so
> https://github.com/wildfly/quickstart/blob/11.x/wsat-simple/src/main/java/org/jboss/as/quickstarts/wsat/simple/RestaurantParticipant.java#L33
> It implements Durable2PCParticipant and the XTS transaction context processing is done by specifying the xts handler in descriptor (https://github.com/wildfly/quickstart/blob/11.x/wsat-simple/src/main/webapp/WEB-INF/classes/context-handlers.xml#L24).
> It would be good to add implicit dependency in such cases for user does not need to provide it on his own.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)