[jbossts-issues] [JBoss JIRA] Commented: (JBTM-777) Reorganise implementation to allow independent deploy/initialise of client, participant and coordinator services

[Andrew Dinn (JIRA)]

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

Andrew Dinn commented on JBTM-777:
----------------------------------

This is now essentially complete but has not been fully tested. So far it has been made to work with a client and web service only in one JBoss AS container and a coordinator only in another JBoss AS coordinator.

The latest XTS 1.1 now only deploys web apps for WS-C (1 coordinator app) and WS-T (3 apps, 1 for each component). All initialisation is done via configuration files so the web.xml files do not employ listeners. If you want to drop coordinator, client or participant side code then you need to drop the relevant war files from the XTS sar and modify the application.xml to remove the reference to the war.

The configuration switch for deploying inside JBoss are located in file xts11-jboss-beans.xml file located in the XTS sar META-INF directory.

If you want to deploy outside of JBossAS then the equivalent configuration switches are in file xts-properties11.xml located in the config directory. This file is not included in the XTS sar. You will need to locate it in your deployment so that it will be found when the XTS code tries to look it up as a resource under name "xts-properties.xml". i.e. it has to be found via

XTSPropertyManager.class.getClassLoader().getResourceAsStream("xts-properties.xml");

where XTSPropertyManager is a class located in ws-c.jar.

NOte also that there are equivalent bean/property config files for the combined 1.1/1.0 build but note that if you deploy 1.0 you have to include all the 3 components. So, when you edit the config for the combined files you can still only change the settings for the 1.1 components.

The most important config option in xts11-jboss-beans.xml is the xtsInitialisers list in the XTSEnvironment bean. It contains the names of 3 classes which implement interface XTSInitialisation. This is a lifecycole class definign a startup and shutdown operation. There are 3 entries in this list each of which performs startup and shutdown of one of the 3 components. If you don't want any coordinator service implementations to be loaded then delete the coordinator side initialisation class etc. be sure to delete the corresponding war files from your deployment and to modify the application.xml so it does not mention them.

The second most important secondary config option is the proeprties in the WSTEnvironmentBean which define the classes used to implement the AT and BA client or server side implementations. If you have dropped both client and participant initialisation then these values are ignored. If you have included either client or participant then you may want to delete these entries. These classes implement the client side (UserXXXIMple) or server side (XXXManager) API classes. If you delete these properties then no implementation will be loaded. You might want to omit the BA ones for example, in which case any call to the BA API will fail.

The next most important config option is the protocol implementation in the WSCFEnvironmentBean. This option is only relevant if your xtsInitialisation list includes the coordinator side initialisation class. It determines which coordinator services actually get loaded. If you don't want to support WSBA then you can avoid having the WSBA code run by deleting the service and context factory associated with BA (the service has sagas in the name, the context factory has ba in the name). If you don't want AT you can drop the other two. Note that if you want to flly configure this you should also drop the BA or AT endpoints from the web.xml files in ws-c.war and ws-t-coordinator.war. If you don't and something tries to talk to these endpoints it's no big deal. The call will just fail.

The next important settings are the ones in the RecoveryEnvironmentBean. These are the drivers for the recovery process on either the coordinator or the web service.Obviosuly, you can drop the BA ones if you are not using BA. If you are not deploying coordinator services then you can drop the coordinator ones. If you are not deploying web services then you can drop the participant ones. The subordinate ones are needed if your web service is using interposition (i.e. a local coordinator). Note that any web service host which uses interposition must also run a local coordinator service to allow bridging to work.

Finally, if your client does not have a local coordinator service or you want to use a remote service you need to configure the WSCEnvironmentBean proeprties used to define the coordinatorURL.

All the values in the jboss-beans file have counterparts in the xts properties file. bean proeprties specified using a list have corresponding sets of values defined using property entries with a common prefix. It should be obvious from the examples and comments how to configure things.

> Reorganise implementation to allow independent deploy/initialise of client, participant and coordinator services
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: JBTM-777
>                 URL: https://jira.jboss.org/browse/JBTM-777
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: XTS
>    Affects Versions: 4.12.0
>            Reporter: Andrew Dinn
>            Assignee: Andrew Dinn
>
> It would be helpful if it were easier to configure which XTS services get started when XTS is deployed. It should be possible to deploy some proper subset of the client, participant and coordinator services if that is all that will be required by the deployment. This is particularly important for enabling a client only version of XTS to be shipped (addressed in  a related issue).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira