[
https://jira.jboss.org/browse/JBTM-777?page=com.atlassian.jira.plugin.sys...
]
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