[jboss-svn-commits] JBL Code SVN: r25061 - in labs/jbosstm/workspace/resttx: docs and 3 other directories.
jboss-svn-commits at lists.jboss.org
jboss-svn-commits at lists.jboss.org
Mon Feb 2 13:59:59 EST 2009
Author: mmusgrov
Date: 2009-02-02 13:59:59 -0500 (Mon, 02 Feb 2009)
New Revision: 25061
Added:
labs/jbosstm/workspace/resttx/src/test/resources/jbossjta-properties.xml
Removed:
labs/jbosstm/workspace/resttx/jbossjta-properties.xml
Modified:
labs/jbosstm/workspace/resttx/docs/wiki.html
labs/jbosstm/workspace/resttx/pom.xml
labs/jbosstm/workspace/resttx/src/main/java/org/jboss/jbossts/rts/util/TxUtil.java
labs/jbosstm/workspace/resttx/src/test/java/org/jboss/jbossts/rts/test/AppTest.java
labs/jbosstm/workspace/resttx/src/test/resources/log4j.xml
Log:
Clean up warnings and shift JBossTS config file to resources
Modified: labs/jbosstm/workspace/resttx/docs/wiki.html
===================================================================
--- labs/jbosstm/workspace/resttx/docs/wiki.html 2009-02-02 17:28:58 UTC (rev 25060)
+++ labs/jbosstm/workspace/resttx/docs/wiki.html 2009-02-02 18:59:59 UTC (rev 25061)
@@ -1,4 +1,3 @@
+<h2>Overview</h2><p>Specification of how to model transactions as RESTful resources</p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>This wiki article will discuss two approaches to providing transactional guarantees for updating resources modeled using the <a class="jive-link-external-small" href="http://en.wikipedia.org/wiki/Representational_State_Transfer">REST</a> paradigm.</p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>An implementation of the protocol is available in the download section below (or via svn from the private <a class="jive-link-external-small" href="https://svn.jboss.org/repos/labs/labs/jbosstm/workspace/resttx">JBossTS workspace repository</a>). It uses the <a class="jive-link-external-small" href="http://www.jboss.org/resteasy/">RESTEasy</a> implementation of the <a class="jive-link-external-small" href="https://jsr311.dev.java.net/">JAX RS</a> specification. The <a class="jive-link-external-small" href="ht!
tp://www.jboss.org/jbosstm/">JBossTS transaction manager</a> is employed as the protocol coordinator.</p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>We do not discuss whether or not transactions and REST are a good architectural fit suffice to say that there are proponents for both sides of the argument. Certainly it is worth pointing out that if a system cannot be made reliable then it can be of only limited utility. That said it is a worthwhile exercise to show how a REST based system can be made reliable.</p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>The two proposals are:</p><ol><li>classic transactions obeying ACID properties;</li><li>compensation based transactions avoiding the need to lock resources for extended periods of time.</li></ol><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>Approach 1 is discussed in depth whilst the second will be covered in a subsequent wiki.</p><p style="min-height: 8p!
t; height: 8pt; padding: 0px;"> </p><p>Disclaimer: Although the f
ollowing protocol is viable it was in fact written over 8 years ago by another community member, namely <a href="/community/people/mark.little%40jboss.com"><span>Mark Little</span></a>. Things have moved on since then and we do plan to re-evaluate the specification.</p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>The protocol makes use of three resource types:</p><ul><li>A participant is an entity responsible for ensuring that changes to a resource can be driven through a 2PC protocol. It must ensure that changes to resources are recoverable in the presence of failures and that changes are durable and isolated from other changes. Participants are analogous to Resource Managers in the <a class="jive-link-external-small" href="http://www.opengroup.org/bookstore/catalog/c193.htm">X/Open XA specification.</a></li><li>The transaction coordinator is responsible for enlisting participants in the transaction and for driving participants through a 2PC protocol.!
</li><li>A recovery coordinator provides the mechanism to support recovery after failure of participants. Participants are allowed to change their URLs provided they notify the coordinator.</li></ul><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>A client is the entity that wishes to manipulate resources within the context of a transaction. It may or may not be modeled as a resource.</p><h2>Protocol Description</h2><p>All actors are modeled as URLs, the idea being that doing PUT, DELETE, GET and POST to the various URLs will control how a transaction makes progress and how changes to resources are processed reliably (ie obey ACID properties).</p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><ul><li>The transaction coordinator address is <scheme>://<authority>/transaction-coordinator. In the following this address is referred to as TC;</li><li>The recovery coordinator address is <scheme>://<authority>/recovery-co!
ordinator. In the following this address is referred to as RC;</li><li
>A participant address is unspecified but the semantics of PUT, DELETE, GET and POST to the address are specified. In the following this address is referred to as P-URL.</li></ul><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>POST is used to create resources, PUT will modify a resource and GET retrieves a resource:</p><ul><li>a successful PUT returns status code 200 (OK) and any XML data in the body; </li><li>a successful POST returns status code 201 (created) and a Location header containing the URI of the newly created resource; </li><li>a successful GET returns status code 200 (OK) and any XML data in the body; </li><li>DELETE is not used and therefore returns 401 (Unauthorized) </li></ul><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><table border="1" cellpadding="3" cellspacing="0" style="; width: 100%; border: 1px solid #000000"><tbody><tr><th align="center" style="background-color:#6690BC;" valign="middle"><span style="color: #ff!
ffff;"><strong>URL</strong></span></th><th align="center" style="background-color:#6690BC;" valign="middle"><span style="color: #ffffff;"><strong>GET</strong></span></th><th align="center" style="background-color:#6690BC;" valign="middle"><span style="color: #ffffff;"><strong>PUT</strong></span></th><th align="center" style="background-color:#6690BC;" valign="middle"><span style="color: #ffffff;"><strong>POST</strong></span></th></tr><tr><td>TC</td><td>Return all transactions (<a class="jive-link-anchor-small" href="#ref1">1</a>)</td><td><br/></td><td><br/></td></tr><tr><td>TC/recovery</td><td>Return all recovering transactions (<a class="jive-link-anchor-small" href="#ref2">2</a>)</td><td><br/></td><td><br/></td></tr><tr><td>TC/active</td><td>Return all active transactions (<a class="jive-link-anchor-small" href="#ref3">3</a>)</td><td><br/></td><td><br/></td></tr><tr><td>TC/begin?clientId={id}</td><td><br/></td><td><br/></td><td>Start a transaction (with default timeout) r!
eturns url TC/{txid} which is deleted after the timeout or after compl
etion (any HTTP method relating to {txid} thereafter returns 404)</td></tr><tr><td>TC/begin?clientId={id}&timeout={timeout}</td><td><br/></td><td><br/></td><td>Start a transaction (with specified timeout) returns url TC/{txid} which is deleted after the timeout or after completion (any HTTP method relating to {txid} thereafter returns 404)</td></tr><tr><td>TC/{txid}/commit</td><td><br/></td><td>Trigger commit (<a class="jive-link-anchor-small" href="#ref4">4</a>)</td><td><br/></td></tr><tr><td>TC/{txid}</td><td>Return the transaction status (<a class="jive-link-anchor-small" href="#ref5">5</a>)</td><td><br/></td><td><br/></td></tr><tr><td>TC/{txid}?P-URL={url}</td><td><br/></td><td>Enlist url in the transaction returning a unique resource for that participant of the form RC/{RecCoordId}</td><td>401</td></tr><tr><td>RC/{RecCoordId}</td><td>Return the participant URL</td><td>Replace the participant URL (<a class="jive-link-anchor-small" href="#ref7">7</a>)</td><td>401</td>!
</tr><tr><td>P-URL</td><td>Return the status of this participant. A status is any of the statuses returned by prepare and commit</td><td><br/></td><td><br/></td></tr><tr><td>P-URL/prepare</td><td>400</td><td>401</td><td>The participant prepares any work done in the context of the transaction (see note <a class="jive-link-anchor-small" href="#ref6">6</a>). Returns a status URL indicating the outcome: <ul><li>P-URL/prepare-ok</li><li>P-URL/prepare-readonly</li><li>P-URL/prepare-notok</li></ul>A 404 response indicates that the participant has rolled back.</td></tr><tr><td>P-URL/commit</td><td>400</td><td>401</td><td>The participant commits any work done in the context of the transaction (see note <a class="jive-link-anchor-small" href="#ref6">6</a>). Returns a status URL indicating the outcome: <ul><!
li>P-URL/committed</li><li>P-URL/rolledback</li><li>P-URL/heuristic (<
a class="jive-link-anchor-small" href="#ref8">8</a>)</li></ul>A 404 response indicates that the participant has already terminated.</td></tr><tr><td>P-URL/rollback</td><td>400</td><td>401</td><td>The participant rolls back any work done in the context of the transaction (see note <a class="jive-link-anchor-small" href="#ref6">6</a>). Returns a status URL indicating the outcome: <ul><li>P-URL/rolledback</li><li>P-URL/heuristic (<a class="jive-link-anchor-small" href="#ref8">8</a>)</li></ul>A 404 response indicates that the transaction has already terminated.</td></tr><tr><td>P-URL/forget</td><td>Returns the status if a heuristic exists and 404 otherwise</td><td>401</td><td>The participant forgets any heuristic decision</td></tr><tr></tr></tbody></table><h4>Notes</h4><ol><li><a class="jive-link-anchor-small" name="ref1"></a>The body of the response contains an XML document exposing a list of tr!
ansactions.</li><li><a class="jive-link-anchor-smallactive_link" name="ref2"></a>A recovering transaction is one that is completing but one or more participants have failed to respond either because of network failure or a server has failed.</li><li><a class="jive-link-anchor-small" name="ref3"></a>An active transaction is one which has not completed and is not recovering.</li><li><a class="jive-link-anchor-small" name="ref4"></a>Upon successful termination, the URL is implicitly deleted. An HTTP OK response means the transaction either committed or rolled back. If the client wishes to discriminate between the two outcomes he must register a participant with the transaction. If some participants committed whilst others aborted then the coordinator remembers this heuristic outcome. </li><li><a class="jive-link-anchor-small" name="ref5"></a>The status is only returned if the transaction is still active or is recovering. The body of the response contains an XML document exposi!
ng the status of the transaction. </li><li><a class="jive-link-anchor-
small" name="ref6"></a> Participant URLs must be unique with respect to the transaction but is otherwise unconstrained. This URL can be asked to prepare and, if it were not for this restriction, the participant would have no means of knowing which transaction was being prepared. </li><li><a class="jive-link-anchor-small" name="ref7"></a>This operation means that participants can tell the recovery coordinator that they have moved in the event of a failure. Implementation Note: After failure the recovery system will periodically attempt to contact in doubt participants. If the participant has moved it will get HTTP status 404 (Not Found). In this case the recovery subsystem issues a GET on RC/{RecCoordId} if the participant has moved. If it gets a different URL back it will switch over to using the new one. </li><li><a class="jive-link-anchor-small" name="ref8"></a>If the participant has already committed when asked to rollback or vice-versa the participant must remember the d!
ecision until told to forget it.</li></ol><h2>Running the Implementation Prototype<br/></h2><p>The prototype is available via svn (for restricted users) or from the download section below.</p><p>Unpack the distribution (or check out from svn), make sure you have <a class="jive-link-external-small" href="http://maven.apache.org">maven</a> installed, and run the tests:</p><p><code> mvn clean install</code></p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>The tests start up an embedded servlet container for testing the protocol. To run using a stand-alone container (the distribution uses jetty6, but any container would do) type:</p><p><code> mvn jetty6:run-exploded</code></p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>To skip the tests pass -Dmaven.test.skip=true mvn (via MAVEN_OPTS).</p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>There is also an ant build scr!
ipt which performs a simple test against the jetty container.</p><p st
yle="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>You can change logging levels via the log4j script in the file src/test/resources/log4j.xml</p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>If you want to test recovery, edit the test org.jboss.jbossts.rts.testAppTest.test6 and change the crashVM variable to true and run the tests. The VM running the test will halt. Change crashVM variable back to false and start the server. You will see the recovery sub-system replaying the failed transaction. The way I've got things set up at the moment is for the example participant to refuse the the request since it does not persist its work. I might change this in the next update of the prototype.</p>
-<body><h2>[Draft version only - will be published on 2nd or 3rd of Feb]<br/></h2><h2>Overview</h2><p>Specification of how to model transactions as RESTful resources</p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>This wiki article will discuss two approaches to providing transactional guarantees for updating resources modeled using the <a class="jive-link-external-small" href="http://en.wikipedia.org/wiki/Representational_State_Transfer">REST</a> paradigm.</p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>An implementation of the protocol is available in the download section below (or via svn from the private <a class="jive-link-external-small" href="https://svn.jboss.org/repos/labs/labs/jbosstm/workspace/resttx">JBossTS workspace repository</a>). It uses the <a class="jive-link-external-small" href="http://www.jboss.org/resteasy/">RESTEasy</a> implementation of the <a class="jive-link-external-small" href="https://jsr311.dev.java!
.net/">JAX RS</a> specification. The <a class="jive-link-external-small" href="http://www.jboss.org/jbosstm/">JBossTS transaction manager</a> is employed as the protocol coordinator.</p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>We do not discuss whether or not transactions and REST are a good architectural fit suffice to say that there are proponents for both sides of the argument. Certainly it is worth pointing out that if a system cannot be made reliable then it can be of only limited utility. That said it is a worthwhile exercise to show how a REST based system can be made reliable.</p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>The two proposals are:</p><ol><li>classic transactions obeying ACID properties;</li><li>compensation based transactions avoiding the need to lock resources for extended periods of time.</li></ol><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>Approach 1 is discussed in depth wh!
ilst the second will be covered in a subsequent wiki.</p><p style="min
-height: 8pt; height: 8pt; padding: 0px;"> </p><p>Disclaimer: Although the following protocol is viable it is in fact 8 years old. Things have moved on since then and we do plan to re-evaluate the specification.</p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>The protocol makes use of three resource types:</p><ul><li>A participant is an entity responsible for ensuring that changes to a resource can be driven through a 2PC protocol. It must ensure that changes to resources are recoverable in the presence of failures and that changes are durable and isolated from other changes. Participants are analogous to Resource Managers in the <a class="jive-link-external-small" href="http://www.opengroup.org/bookstore/catalog/c193.htm">X/Open XA specification.</a></li><li>The transaction coordinator is responsible for enlisting participants in the transaction and for driving participants through a 2PC protocol.</li><li>A recovery coordinator provides the mecha!
nism to support recovery after failure of participants. Participants are allowed to change their URLs provided they notify the coordinator.</li></ul><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>A client is the entity that wishes to manipulate resources within the context of a transaction. It may or may not be modeled as a resource.</p><h2>Protocol Description</h2><p>All actors are modeled as URLs, the idea being that doing PUT, DELETE, GET and POST to the various URLs will control how a transaction makes progress and how changes to resources are processed reliably (ie obey ACID properties).</p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><ul><li>The transaction coordinator address is <scheme>://<authority>/transaction-coordinator. In the following this address is referred to as TC;</li><li>The recovery coordinator address is <scheme>://<authority>/recovery-coordinator. In the following this address is referr!
ed to as RC;</li><li>A participant address is unspecified but the sema
ntics of PUT, DELETE, GET and POST to the address are specified. In the following this address is referred to as P-URL.</li></ul><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>POST is used to create resources, PUT will modify a resource and GET retrieves a resource:</p><ul><li>a successful PUT returns status code 200 (OK) and any XML data in the body; </li><li>a successful POST returns status code 201 (created) and a Location header containing the URI of the newly created resource; </li><li>a successful GET returns status code 200 (OK) and any XML data in the body; </li><li>DELETE is not used and therefore returns 401 (Unauthorized) </li></ul><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><table border="1" cellpadding="3" cellspacing="0" style="; width: 100%; border: 1px solid #000000"><tbody><tr><th align="center" style="background-color:#6690BC;" valign="middle"><span style="color: #ffffff;"><strong>URL</strong></span></th><th align="!
center" style="background-color:#6690BC;" valign="middle"><span style="color: #ffffff;"><strong>GET</strong></span></th><th align="center" style="background-color:#6690BC;" valign="middle"><span style="color: #ffffff;"><strong>PUT</strong></span></th><th align="center" style="background-color:#6690BC;" valign="middle"><span style="color: #ffffff;"><strong>POST</strong></span></th></tr><tr><td>TC</td><td>Return all transactions (<a class="jive-link-anchor-small" href="#ref1">1</a>)</td><td></td><td></td></tr><tr><td>TC/recovery</td><td>Return all recovering transactions (<a class="jive-link-anchor-small" href="#ref2">2</a>)</td><td></td><td></td></tr><tr><td>TC/active</td><td>Return all active transactions (<a class="jive-link-anchor-small" href="#ref3">3</a>)</td><td></td><td></td></tr><tr><td>TC/begin?clientId={id}</td><td></td><td></td><td>Start a transaction (with default timeout) returns url TC/{txid} which is deleted after the timeout or after completion (any HTTP meth!
od relating to {txid} thereafter returns 404)</td></tr><tr><td>TC/begi
n?clientId={id}&timeout={timeout}</td><td></td><td></td><td>Start a transaction (with specified timeout) returns url TC/{txid} which is deleted after the timeout or after completion (any HTTP method relating to {txid} thereafter returns 404)</td></tr><tr><td>TC/{txid}/commit</td><td></td><td>Trigger commit (<a class="jive-link-anchor-small" href="#ref4">4</a>)</td><td></td></tr><tr><td>TC/{txid}</td><td>Return the transaction status (<a class="jive-link-anchor-small" href="#ref5">5</a>)</td><td></td><td></td></tr><tr><td>TC/{txid}?P-URL={url}</td><td><br/></td><td>Enlist url in the transaction returning a unique resource for that participant of the form RC/{RecCoordId}</td><td>401</td></tr><tr><td>RC/{RecCoordId}</td><td>Return the participant URL</td><td>Replace the participant URL (<a class="jive-link-anchor-small" href="#ref7">7</a>)</td><td>401</td></tr><tr><td>P-URL</td><td>Return the status of this participant. A status is any of the statuses returned by prepare an!
d commit</td><td></td><td></td></tr><tr><td>P-URL/prepare</td><td>400</td><td>401</td><td>The participant prepares any work done in the context of the transaction (see note <a class="jive-link-anchor-small" href="#ref6">6</a>). Returns a status URL indicating the outcome: <ul><li>P-URL/prepare-ok</li><li>P-URL/prepare-readonly</li><li>P-URL/prepare-notok</li></ul>A 404 response indicates that the participant has rolled back.</td></tr><tr><td>P-URL/commit</td><td>400</td><td>401</td><td>The participant commits any work done in the context of the transaction (see note <a class="jive-link-anchor-small" href="#ref6">6</a>). Returns a status URL indicating the outcome: <ul><li>P-URL/committed</li><li>P-URL/rolledback</li><li>P-URL/heuristic (<a class="jive-link-anchor-small" href="#ref8">8</a>)</li></u!
l>A 404 response indicates that the participant has already terminated
.</td></tr><tr><td>P-URL/rollback</td><td>400</td><td>401</td><td>The participant rolls back any work done in the context of the transaction (see note <a class="jive-link-anchor-small" href="#ref6">6</a>). Returns a status URL indicating the outcome: <ul><li>P-URL/rolledback</li><li>P-URL/heuristic (<a class="jive-link-anchor-small" href="#ref8">8</a>)</li></ul>A 404 response indicates that the transaction has already terminated.</td></tr><tr><td>P-URL/forget</td><td>Returns the status if a heuristic exists and 404 otherwise</td><td>401</td><td>The participant forgets any heuristic decision</td></tr><tr></tr></tbody></table><h4>Notes</h4><ol><li><a class="jive-link-anchor-small" name="ref1"></a>The body of the response contains an XML document exposing a list of transactions.</li><li><a class="jive-link-anchor-small" name="ref2"></a>A recovering transaction is one that is completing but one o!
r more participants have failed to respond either because of network failure or a server has failed.</li><li><a class="jive-link-anchor-small" name="ref3"></a>An active transaction is one which has not completed and is not recovering.</li><li><a class="jive-link-anchor-small" name="ref4"></a>Upon successful termination, the URL is implicitly deleted. An HTTP OK response means the transaction either committed or rolled back. If the client wishes to discriminate between the two outcomes he must register a participant with the transaction. If some participants committed whilst others aborted then the coordinator remembers this heuristic outcome. </li><li><a class="jive-link-anchor-small" name="ref5"></a>The status is only returned if the transaction is still active or is recovering. The body of the response contains an XML document exposing the status of the transaction. </li><li><a class="jive-link-anchor-small" name="ref6"></a> Participant URLs must be unique with respect to!
the transaction but is otherwise unconstrained. This URL can be asked
to prepare and, if it were not for this restriction, the participant would have no means of knowing which transaction was being prepared. </li><li><a class="jive-link-anchor-small" name="ref7"></a>This operation means that participants can tell the recovery coordinator that they have moved in the event of a failure. Implementation Note: After failure the recovery system will periodically attempt to contact in doubt participants. If the participant has moved it will get HTTP status 404 (Not Found). In this case the recovery subsystem issues a GET on RC/{RecCoordId} if the participant has moved. If it gets a different URL back it will switch over to using the new one. </li><li><a class="jive-link-anchor-small" name="ref8"></a>If the participant has already committed when asked to rollback or vice-versa the participant must remember the decision until told to forget it.</li></ol><h2>Running the Implementation Prototype<br/></h2><p>The prototype is available via svn (for restri!
cted users) or from the download section below.</p><p>Unpack the distribution (or check out from svn), make sure you have <a class="jive-link-external-small" href="http://maven.apache.org">maven</a> installed, and run the tests:</p><p><code> mvn clean install</code></p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>The tests start up an embedded servlet container for testing the protocol. To run using a stand-alone container (the distribution uses jetty6, but any container would do) type:</p><p><code> mvn jetty6:run-exploded</code></p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>To skip the tests pass -Dmaven.test.skip=true mvn (via MAVEN_OPTS).</p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>There is also an ant build script which performs a simple test against the jetty container.</p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>You can !
change logging levels via the log4j script in the file src/test/resour
ces/log4j.xml</p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>If you want to test recovery, edit the test org.jboss.jbossts.rts.testAppTest.test6 and change the crashVM variable to true and run the tests. The VM running the test will halt. Change crashVM variable back to false and start the server. You will see the recovery sub-system replaying the failed transaction. The way I've got things set up at the moment is for the example participant to refuse the the request since it does not persist its work. I might change this in the next update of the prototype.</p></div><!-- [DocumentBodyEnd:02eaa68b-f9da-4211-a43c-344f1163d0aa] -->
-</body>
Deleted: labs/jbosstm/workspace/resttx/jbossjta-properties.xml
===================================================================
--- labs/jbosstm/workspace/resttx/jbossjta-properties.xml 2009-02-02 17:28:58 UTC (rev 25060)
+++ labs/jbosstm/workspace/resttx/jbossjta-properties.xml 2009-02-02 18:59:59 UTC (rev 25061)
@@ -1,295 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<transaction-service>
- <properties depends="common" name="arjuna">
- <property
- name="com.arjuna.ats.internal.arjuna.inventory.staticInventoryImple.RESTRecord" value="org.jboss.jbossts.rts.resource.RESTRecordSetup" />
- <!--
- Transaction Reaper Timeout (default is 120000 ms).
- -->
- <property
- name="com.arjuna.ats.arjuna.coordinator.txReaperTimeout" value="120000"/>
- <!--
- Transaction Reaper Mode, can be: PERIODIC or DYNAMIC. Default is DYNAMIC.
- -->
- <property name="com.arjuna.ats.arjuna.coordinator.txReaperMode" value="DYNAMIC"/>
- <!--
- Transaction Reaper Cancel Wait Period (default is 500 ms, min is 10 msecs).
- -->
- <property
- name="com.arjuna.ats.arjuna.coordinator.txReaperCancelWaitPeriod" value="500"/>
- <!--
- Transaction Reaper Cancel Fail Wait Period (default is 500 ms, min is 10 msecs).
- -->
- <property
- name="com.arjuna.ats.arjuna.coordinator.txReaperCancelFailWaitPeriod" value="500"/>
- <!--
- Transaction Reaper Zombie Max (default is 8).
- -->
- <property
- name="com.arjuna.ats.arjuna.coordinator.txReaperZombieMax" value="8"/>
- <!--
- (default is NO)
- -->
- <property name="com.arjuna.ats.arjuna.coordinator.asyncCommit" value="NO"/>
- <!--
- (default is NO)
- -->
- <property name="com.arjuna.ats.arjuna.coordinator.asyncPrepare" value="NO"/>
- <!--
- (default is YES)
- -->
- <property
- name="com.arjuna.ats.arjuna.coordinator.commitOnePhase" value="YES"/>
- <!--
- (default is defaultStore)
- -->
- <property name="com.arjuna.ats.arjuna.objectstore.localOSRoot" value="defaultStore"/>
- <!--
- default is under user.home - must be writeable!)
- -->
- <property
- name="com.arjuna.ats.arjuna.objectstore.objectStoreDir" value="ObjectStore" />
- <property name="com.arjuna.ats.arjuna.coordinator.transactionLog" value="OFF"/>
- <!--
- (default is ON)
- -->
- <property
- name="com.arjuna.ats.arjuna.objectstore.objectStoreSync" value="ON"/>
- <!--
- (default is ShadowNoFileLockStore)
- -->
- <property name="com.arjuna.ats.arjuna.objectstore.objectStoreType" value="ShadowNoFileLockStore"/>
- <!--
- (default is 255)
- -->
- <property
- name="com.arjuna.ats.arjuna.objectstore.hashedDirectories" value="255"/>
- <!--
- (default is ON)
- -->
- <property
- name="com.arjuna.ats.arjuna.objectstore.transactionSync" value="ON"/>
- <!--
- (Must be unique across all Arjuna instances.)
- -->
- <property name="com.arjuna.ats.arjuna.xa.nodeIdentifier" value="1"/>
- <!--
- Base port number for determining a unique number to associate with an instance of the transaction service
- (which is needed in order to support multiple instances on the same machine).
- Use the value 0 to allow the system to select the first available port number.
- If the port number is non-zero and the port is in use then the value will be incremented until either a successful binding
- to the loopback address is created or until the the maximum number of ports (specified by the
- com.arjuna.ats.internal.arjuna.utils.SocketProcessIdMaxPorts property) have been tried or until the port number
- reaches the maximum possible port number.
- -->
- <property
- name="com.arjuna.ats.internal.arjuna.utils.SocketProcessIdPort" value="0"/>
- <!--
- The maximum number of ports to try starting from the value specified by the property
- com.arjuna.ats.internal.arjuna.utils.SocketProcessIdPort. Any non-numeric or value less than 1 will
- defautl to 1.
- -->
- <property
- name="com.arjuna.ats.internal.arjuna.utils.SocketProcessIdMaxPorts" value="1"/>
- <!--
- Run the TransactionStatusManager to allow out-of-process recovery managers to query
- the status of transactions owned by this coordinator. Default is YES.
- This can be set to NO in cases where an ObjectStore is used only by one transaction manager
- and the recovery manager for that store is in the same JVM. In any other cases disabling the
- TransactionStatusManager may cause crash recovery to misbehave.
- -->
- <property
- name="com.arjuna.ats.arjuna.coordinator.transactionStatusManagerEnable" value="NO"/>
- <!-- property
- name="com.arjuna.ats.arjuna.coordinator.actionStore"
- value="HashedActionStore"
- value="JDBCActionStore"
- -->
- <!-- property
- name="com.arjuna.ats.arjuna.objectstore.jdbcTxDbAccess"
- value="JDBCAccess"
- -->
- <!-- property
- name="com.arjuna.ats.arjuna.objectstore.objectStoreType"
- value="ShadowNoFileLockStore"
- value="JDBCStore"
- -->
- <!-- property
- name="com.arjuna.ats.arjuna.objectstore.jdbcUserDbAccess"
- value="JDBCAccess"
- -->
- <!-- property
- name="com.arjuna.ats.arjuna.objectstore.jdbcPoolSizeInitial"
- value="1"
- -->
- <!-- property
- name="com.arjuna.ats.arjuna.objectstore.jdbcPoolSizeMaximum"
- value="1"
- -->
- <!-- property
- name="com.arjuna.ats.arjuna.objectstore.jdbcPoolPutConnections"
- value="false"
- -->
- <!-- property
- name="com.arjuna.ats.arjuna.internal.arjuna.objectstore.cacheStore.size"
- value=""
- -->
- <!-- property
- name="com.arjuna.ats.arjuna.internal.arjuna.objectstore.cacheStore.period"
- value=""
- -->
- <!--
- The location for creating temporary files, e.g., Uids.
- Default is under user.home.
- IMPORTANT: make sure the directory is lockable, e.g., /tmp on Unix
- may not be!
- -->
- <!--
- <property
- name="com.arjuna.ats.arjuna.common.varDir"
- value="var"/>
- -->
- </properties>
- <properties name="common">
- <!-- CLF 2.0 properties -->
- <property name="com.arjuna.common.util.logging.DebugLevel"
- type="System" value="0x00000000"/>
- <property name="com.arjuna.common.util.logging.FacilityLevel"
- type="System" value="0xffffffff"/>
- <property name="com.arjuna.common.util.logging.VisibilityLevel"
- type="System" value="0xffffffff"/>
- <property name="com.arjuna.common.util.logger" type="System" value="log4j"/>
- </properties>
- <properties depends="arjuna" name="txoj">
- <!--
- (default is LockStore of installation - must be writeable!)
- -->
- <!--
- <property
- name="com.arjuna.ats.txoj.lockstore.lockStoreDir"
- value="LockStore"/>
- -->
- <!--
- (default is BasicLockStore)
- -->
- <property name="com.arjuna.ats.txoj.lockstore.lockStoreType" value="BasicLockStore"/>
- <!--
- (default is NO)
- -->
- <property name="com.arjuna.ats.txoj.lockstore.multipleLockStore" value="NO"/>
- <!--
- (default is YES)
- -->
- <property name="com.arjuna.ats.txoj.lockstore.singleLockStore" value="YES"/>
- <!--
- (default is YES)
- -->
- <property
- name="com.arjuna.ats.txoj.lockstore.allowNestedLocking" value="YES"/>
- </properties>
- <properties depends="arjuna" name="jta">
- <!--
- Support subtransactions in the JTA layer?
- Default is NO.
- -->
- <property name="com.arjuna.ats.jta.supportSubtransactions" value="NO"/>
- <property name="com.arjuna.ats.jta.jtaTMImplementation" value="com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionManagerImple"/>
- <!--
- com.arjuna.ats.internal.jta.transaction.jts.TransactionManagerImple
- -->
- <property name="com.arjuna.ats.jta.jtaUTImplementation" value="com.arjuna.ats.internal.jta.transaction.arjunacore.UserTransactionImple"/>
- <!--
- com.arjuna.ats.internal.jta.transaction.jts.UserTransactionImple
- -->
- </properties>
- <properties depends="arjuna,txoj,jta" name="recoverymanager">
- <!--
- Properties used only by the RecoveryManager.
- -->
- <!--
- Periodic recovery settings.
- Time values in this section are in seconds.
- -->
- <!--
- Interval in seconds between initiating the periodic recovery modules.
- Default is 120 seconds.
- -->
- <property
- name="com.arjuna.ats.arjuna.recovery.periodicRecoveryPeriod" value="120"/>
- <!--
- Interval in seconds between first and second pass of periodic recovery.
- Default is 10 seconds.
- -->
- <property
- name="com.arjuna.ats.arjuna.recovery.recoveryBackoffPeriod" value="10"/>
- <!--
- The port number on which the recovery manager listens.
- -->
- <property name="com.arjuna.ats.arjuna.recovery.recoveryPort" value="4712"/>
- <!--
- The address on which the recovery manager listens.
- If running within an AS then the address the AS is bound to (jboss.bind.address) takes precedence
- -->
- <property name="com.arjuna.ats.arjuna.recovery.recoveryAddress" value=""/>
- <!--
- Periodic recovery modules to use. Invoked in sort-order of names.
- -->
- <property
- name="com.arjuna.ats.arjuna.recovery.recoveryExtension1" value="com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule"/>
- <property
- name="com.arjuna.ats.arjuna.recovery.recoveryExtension2" value="com.arjuna.ats.internal.txoj.recovery.TORecoveryModule"/>
- <property
- name="com.arjuna.ats.arjuna.recovery.recoveryExtension3" value="com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule"/>
- <!--
- Expired entry removal
- -->
- <!--
- Expiry scanners to use (order of invocation is random).
- Names must begin with "com.arjuna.ats.arjuna.recovery.expiryScanner"
- -->
- <property
- name="com.arjuna.ats.arjuna.recovery.expiryScannerTransactionStatusManager" value="com.arjuna.ats.internal.arjuna.recovery.ExpiredTransactionStatusManagerScanner"/>
- <!--
- Interval, in hours, between running the expiry scanners.
- This can be quite long. The absolute value determines the interval -
- if the value is negative, the scan will NOT be run until after one
- interval has elapsed. If positive the first scan will be immediately
- after startup. Zero will prevent any scanning.
- Default = 12 = run immediately, then every 12 hours.
- -->
- <property
- name="com.arjuna.ats.arjuna.recovery.expiryScanInterval" value="12"/>
- <!--
- This is the interval, in hours, after which a process that cannot be contacted will be considered dead.
- It should be long enough to avoid accidentally removing valid entries due to short lived
- transient errors such as network downtime. Zero = Never removed. Default is 12.
- -->
- <property
- name="com.arjuna.ats.arjuna.recovery.transactionStatusManagerExpiryTime" value="12"/>
- <!--
- Use this to fix the port on which the TransactionStatusManager listens,
- The default behaviour is to use any free port.
- -->
- <property
- name="com.arjuna.ats.arjuna.recovery.transactionStatusManagerPort" value="0"/>
- <!--
- Use this to fix the address on which the TransactionStatusManager binds,
- The default behaviour is to use the loopback address (ie localhost).
- If running within an AS then the address the AS is bound to (jboss.bind.address) takes precedence
- -->
- <property
- name="com.arjuna.ats.arjuna.recovery.transactionStatusManagerAddress" value=""/>
- <!--
- For cases where the recovery manager is in process with the transaction manager and nothing else uses
- the ObjectStore, it is possible to disable the socket based recovery listener by setting this to NO.
- Caution: use of this property can allow multiple recovery processes to run on the same ObjectStore
- if you are not careful. That in turn can lead to incorrect transaction processing. Use with care.
- -->
- <property name="com.arjuna.ats.arjuna.recovery.recoveryListener" value="NO"/>
- </properties>
- <properties depends="jta" name="jdbc">
- <!--
- property name="com.arjuna.ats.jdbc.isolationLevel" value="TRANSACTION_SERIALIZABLE"/>
- -->
- </properties>
-</transaction-service>
Modified: labs/jbosstm/workspace/resttx/pom.xml
===================================================================
--- labs/jbosstm/workspace/resttx/pom.xml 2009-02-02 17:28:58 UTC (rev 25060)
+++ labs/jbosstm/workspace/resttx/pom.xml 2009-02-02 18:59:59 UTC (rev 25061)
@@ -21,7 +21,6 @@
<name>maven repo</name>
<url>http://repo1.maven.org/maven2/</url>
</repository>
- <!-- For resteasy -->
<repository>
<id>jboss</id>
<name>jboss repo</name>
@@ -54,15 +53,7 @@
<artifactId>commons-httpclient</artifactId>
<version>3.1</version>
</dependency>
-<!--
<dependency>
- <groupId>apache-log4j</groupId>
- <artifactId>log4j</artifactId>
- <version>1.2.14</version>
- </dependency>
--->
-
- <dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.5</version>
@@ -71,9 +62,6 @@
<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-jaxrs</artifactId>
- <!--
- <version>1.0-beta-8</version>
- -->
<version>1.0-RC1</version>
<!-- filter out unwanted jars -->
@@ -94,11 +82,11 @@
</exclusion>
</exclusions>
</dependency>
- <dependency>
- <groupId>org.jboss.resteasy</groupId>
- <artifactId>resteasy-jaxb-provider</artifactId>
- <version>1.0-RC1</version>
- </dependency>
+ <dependency>
+ <groupId>org.jboss.resteasy</groupId>
+ <artifactId>resteasy-jaxb-provider</artifactId>
+ <version>1.0-RC1</version>
+ </dependency>
</dependencies>
<build>
@@ -131,7 +119,7 @@
</systemProperty>
<systemProperty>
<name>com.arjuna.ats.arjuna.common.propertiesFile</name>
- <value>jbossjta-properties.xml</value>
+ <value>file:./src/test/resources/jbossjta-properties.xml</value>
</systemProperty>
</systemProperties>
</configuration>
Modified: labs/jbosstm/workspace/resttx/src/main/java/org/jboss/jbossts/rts/util/TxUtil.java
===================================================================
--- labs/jbosstm/workspace/resttx/src/main/java/org/jboss/jbossts/rts/util/TxUtil.java 2009-02-02 17:28:58 UTC (rev 25060)
+++ labs/jbosstm/workspace/resttx/src/main/java/org/jboss/jbossts/rts/util/TxUtil.java 2009-02-02 18:59:59 UTC (rev 25061)
@@ -31,6 +31,7 @@
import org.jboss.resteasy.util.HttpResponseCodes;
import java.io.IOException;
+import java.io.InputStream;
import java.io.StringWriter;
import java.net.URI;
import java.net.URISyntaxException;
@@ -61,7 +62,7 @@
public static int getIntProperty(String name, String def)
{
- String port = System.getProperty("PORT", def);
+ String port = System.getProperty(name, def);
try {
return Integer.valueOf(port);
@@ -141,10 +142,10 @@
for (int i : expect)
if (i == status) {
- return getResponseBody(method);
+ return getResponseBodyFromSteam(method);
}
- throw new HttpResponseException(null, getResponseBody(method), ex, status);
+ throw new HttpResponseException(null, getResponseBodyFromSteam(method), ex, status);
}
catch (IOException e)
@@ -172,6 +173,28 @@
}
}
+ private static String getResponseBodyFromSteam(HttpMethod method)
+ {
+ try
+ {
+ InputStream is = method.getResponseBodyAsStream();
+ StringBuilder sb = new StringBuilder();
+ byte[] buf = new byte[1024];
+ int len;
+
+ while ((len = is.read(buf)) != -1)
+ sb.append(new String(buf, 0, len)); //, "US-ASCII");
+
+ is.close();
+
+ return sb.toString();
+ }
+ catch (IOException e)
+ {
+ return e.getMessage();
+ }
+ }
+
public static String doGet(int[] expect, String url, String... nvParams) throws HttpResponseException
{
return doMethod(expect, new GetMethod(url), nvParams);
@@ -182,7 +205,7 @@
HttpMethod method = new PostMethod(url);
String res = doMethod(expect, method, nvParams);
Header header = method.getResponseHeader("location");
- System.out.println("post response location header: " + (header != null ? header.getValue() : "null"));
+ log.debug("post response location header: " + (header != null ? header.getValue() : "null"));
return header != null ? header.getValue() : res;
}
Modified: labs/jbosstm/workspace/resttx/src/test/java/org/jboss/jbossts/rts/test/AppTest.java
===================================================================
--- labs/jbosstm/workspace/resttx/src/test/java/org/jboss/jbossts/rts/test/AppTest.java 2009-02-02 17:28:58 UTC (rev 25060)
+++ labs/jbosstm/workspace/resttx/src/test/java/org/jboss/jbossts/rts/test/AppTest.java 2009-02-02 18:59:59 UTC (rev 25061)
@@ -128,14 +128,14 @@
}
// 1PC commit
- public void xtest1() throws IOException
+ public void test1() throws IOException
{
String tx = startTx(0L, false);
modifyResource(tx, "pid1", "p1", "v1");
commitTx(tx, false);
}
// 2PC commit
- public void xtest2() throws IOException
+ public void test2() throws IOException
{
String tx = startTx(0L, false);
modifyResource(tx, "pid1", "p1", "v1");
@@ -144,7 +144,7 @@
commitTx(tx, true); // should not be able to commit a completed transaction
}
// commit an invalid transaction
- public void xtest3() throws IOException
+ public void test3() throws IOException
{
String tx = "http://localhost:9096/transaction-coordinator/dead_7f000001_b9cc_4981ded5_5";
commitTx(tx, true);
@@ -154,7 +154,7 @@
* Modify a resource within a transaction and rollback.
* Ensure that the resource has not changed.
*/
- public void xtest4() throws IOException
+ public void test4() throws IOException
{
String v1 = modifyResource(null, "pid1", "p1", "v1");
String v2 = modifyResource(null, "pid2", "p1", "v1");
@@ -178,7 +178,7 @@
/**
* Test the Recovery URL
*/
- public void xtest5() throws IOException
+ public void test5() throws IOException
{
String tx = startTx(0L, false); // start a transaction
@@ -203,6 +203,8 @@
// and finally check that POST and DELETE on the recovery URL fail
TxUtil.doPost(new int[] {HttpResponseCodes.SC_UNAUTHORIZED}, recCoordId);
TxUtil.doDelete(new int[] {HttpResponseCodes.SC_UNAUTHORIZED}, recCoordId);
+
+ rollbackTx(tx, false);
}
/*
Copied: labs/jbosstm/workspace/resttx/src/test/resources/jbossjta-properties.xml (from rev 25035, labs/jbosstm/workspace/resttx/jbossjta-properties.xml)
===================================================================
--- labs/jbosstm/workspace/resttx/src/test/resources/jbossjta-properties.xml (rev 0)
+++ labs/jbosstm/workspace/resttx/src/test/resources/jbossjta-properties.xml 2009-02-02 18:59:59 UTC (rev 25061)
@@ -0,0 +1,295 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<transaction-service>
+ <properties depends="common" name="arjuna">
+ <property
+ name="com.arjuna.ats.internal.arjuna.inventory.staticInventoryImple.RESTRecord" value="org.jboss.jbossts.rts.resource.RESTRecordSetup" />
+ <!--
+ Transaction Reaper Timeout (default is 120000 ms).
+ -->
+ <property
+ name="com.arjuna.ats.arjuna.coordinator.txReaperTimeout" value="120000"/>
+ <!--
+ Transaction Reaper Mode, can be: PERIODIC or DYNAMIC. Default is DYNAMIC.
+ -->
+ <property name="com.arjuna.ats.arjuna.coordinator.txReaperMode" value="DYNAMIC"/>
+ <!--
+ Transaction Reaper Cancel Wait Period (default is 500 ms, min is 10 msecs).
+ -->
+ <property
+ name="com.arjuna.ats.arjuna.coordinator.txReaperCancelWaitPeriod" value="500"/>
+ <!--
+ Transaction Reaper Cancel Fail Wait Period (default is 500 ms, min is 10 msecs).
+ -->
+ <property
+ name="com.arjuna.ats.arjuna.coordinator.txReaperCancelFailWaitPeriod" value="500"/>
+ <!--
+ Transaction Reaper Zombie Max (default is 8).
+ -->
+ <property
+ name="com.arjuna.ats.arjuna.coordinator.txReaperZombieMax" value="8"/>
+ <!--
+ (default is NO)
+ -->
+ <property name="com.arjuna.ats.arjuna.coordinator.asyncCommit" value="NO"/>
+ <!--
+ (default is NO)
+ -->
+ <property name="com.arjuna.ats.arjuna.coordinator.asyncPrepare" value="NO"/>
+ <!--
+ (default is YES)
+ -->
+ <property
+ name="com.arjuna.ats.arjuna.coordinator.commitOnePhase" value="YES"/>
+ <!--
+ (default is defaultStore)
+ -->
+ <property name="com.arjuna.ats.arjuna.objectstore.localOSRoot" value="defaultStore"/>
+ <!--
+ default is under user.home - must be writeable!)
+ -->
+ <property
+ name="com.arjuna.ats.arjuna.objectstore.objectStoreDir" value="ObjectStore" />
+ <property name="com.arjuna.ats.arjuna.coordinator.transactionLog" value="OFF"/>
+ <!--
+ (default is ON)
+ -->
+ <property
+ name="com.arjuna.ats.arjuna.objectstore.objectStoreSync" value="ON"/>
+ <!--
+ (default is ShadowNoFileLockStore)
+ -->
+ <property name="com.arjuna.ats.arjuna.objectstore.objectStoreType" value="ShadowNoFileLockStore"/>
+ <!--
+ (default is 255)
+ -->
+ <property
+ name="com.arjuna.ats.arjuna.objectstore.hashedDirectories" value="255"/>
+ <!--
+ (default is ON)
+ -->
+ <property
+ name="com.arjuna.ats.arjuna.objectstore.transactionSync" value="ON"/>
+ <!--
+ (Must be unique across all Arjuna instances.)
+ -->
+ <property name="com.arjuna.ats.arjuna.xa.nodeIdentifier" value="1"/>
+ <!--
+ Base port number for determining a unique number to associate with an instance of the transaction service
+ (which is needed in order to support multiple instances on the same machine).
+ Use the value 0 to allow the system to select the first available port number.
+ If the port number is non-zero and the port is in use then the value will be incremented until either a successful binding
+ to the loopback address is created or until the the maximum number of ports (specified by the
+ com.arjuna.ats.internal.arjuna.utils.SocketProcessIdMaxPorts property) have been tried or until the port number
+ reaches the maximum possible port number.
+ -->
+ <property
+ name="com.arjuna.ats.internal.arjuna.utils.SocketProcessIdPort" value="0"/>
+ <!--
+ The maximum number of ports to try starting from the value specified by the property
+ com.arjuna.ats.internal.arjuna.utils.SocketProcessIdPort. Any non-numeric or value less than 1 will
+ defautl to 1.
+ -->
+ <property
+ name="com.arjuna.ats.internal.arjuna.utils.SocketProcessIdMaxPorts" value="1"/>
+ <!--
+ Run the TransactionStatusManager to allow out-of-process recovery managers to query
+ the status of transactions owned by this coordinator. Default is YES.
+ This can be set to NO in cases where an ObjectStore is used only by one transaction manager
+ and the recovery manager for that store is in the same JVM. In any other cases disabling the
+ TransactionStatusManager may cause crash recovery to misbehave.
+ -->
+ <property
+ name="com.arjuna.ats.arjuna.coordinator.transactionStatusManagerEnable" value="NO"/>
+ <!-- property
+ name="com.arjuna.ats.arjuna.coordinator.actionStore"
+ value="HashedActionStore"
+ value="JDBCActionStore"
+ -->
+ <!-- property
+ name="com.arjuna.ats.arjuna.objectstore.jdbcTxDbAccess"
+ value="JDBCAccess"
+ -->
+ <!-- property
+ name="com.arjuna.ats.arjuna.objectstore.objectStoreType"
+ value="ShadowNoFileLockStore"
+ value="JDBCStore"
+ -->
+ <!-- property
+ name="com.arjuna.ats.arjuna.objectstore.jdbcUserDbAccess"
+ value="JDBCAccess"
+ -->
+ <!-- property
+ name="com.arjuna.ats.arjuna.objectstore.jdbcPoolSizeInitial"
+ value="1"
+ -->
+ <!-- property
+ name="com.arjuna.ats.arjuna.objectstore.jdbcPoolSizeMaximum"
+ value="1"
+ -->
+ <!-- property
+ name="com.arjuna.ats.arjuna.objectstore.jdbcPoolPutConnections"
+ value="false"
+ -->
+ <!-- property
+ name="com.arjuna.ats.arjuna.internal.arjuna.objectstore.cacheStore.size"
+ value=""
+ -->
+ <!-- property
+ name="com.arjuna.ats.arjuna.internal.arjuna.objectstore.cacheStore.period"
+ value=""
+ -->
+ <!--
+ The location for creating temporary files, e.g., Uids.
+ Default is under user.home.
+ IMPORTANT: make sure the directory is lockable, e.g., /tmp on Unix
+ may not be!
+ -->
+ <!--
+ <property
+ name="com.arjuna.ats.arjuna.common.varDir"
+ value="var"/>
+ -->
+ </properties>
+ <properties name="common">
+ <!-- CLF 2.0 properties -->
+ <property name="com.arjuna.common.util.logging.DebugLevel"
+ type="System" value="0x00000000"/>
+ <property name="com.arjuna.common.util.logging.FacilityLevel"
+ type="System" value="0xffffffff"/>
+ <property name="com.arjuna.common.util.logging.VisibilityLevel"
+ type="System" value="0xffffffff"/>
+ <property name="com.arjuna.common.util.logger" type="System" value="log4j"/>
+ </properties>
+ <properties depends="arjuna" name="txoj">
+ <!--
+ (default is LockStore of installation - must be writeable!)
+ -->
+ <!--
+ <property
+ name="com.arjuna.ats.txoj.lockstore.lockStoreDir"
+ value="LockStore"/>
+ -->
+ <!--
+ (default is BasicLockStore)
+ -->
+ <property name="com.arjuna.ats.txoj.lockstore.lockStoreType" value="BasicLockStore"/>
+ <!--
+ (default is NO)
+ -->
+ <property name="com.arjuna.ats.txoj.lockstore.multipleLockStore" value="NO"/>
+ <!--
+ (default is YES)
+ -->
+ <property name="com.arjuna.ats.txoj.lockstore.singleLockStore" value="YES"/>
+ <!--
+ (default is YES)
+ -->
+ <property
+ name="com.arjuna.ats.txoj.lockstore.allowNestedLocking" value="YES"/>
+ </properties>
+ <properties depends="arjuna" name="jta">
+ <!--
+ Support subtransactions in the JTA layer?
+ Default is NO.
+ -->
+ <property name="com.arjuna.ats.jta.supportSubtransactions" value="NO"/>
+ <property name="com.arjuna.ats.jta.jtaTMImplementation" value="com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionManagerImple"/>
+ <!--
+ com.arjuna.ats.internal.jta.transaction.jts.TransactionManagerImple
+ -->
+ <property name="com.arjuna.ats.jta.jtaUTImplementation" value="com.arjuna.ats.internal.jta.transaction.arjunacore.UserTransactionImple"/>
+ <!--
+ com.arjuna.ats.internal.jta.transaction.jts.UserTransactionImple
+ -->
+ </properties>
+ <properties depends="arjuna,txoj,jta" name="recoverymanager">
+ <!--
+ Properties used only by the RecoveryManager.
+ -->
+ <!--
+ Periodic recovery settings.
+ Time values in this section are in seconds.
+ -->
+ <!--
+ Interval in seconds between initiating the periodic recovery modules.
+ Default is 120 seconds.
+ -->
+ <property
+ name="com.arjuna.ats.arjuna.recovery.periodicRecoveryPeriod" value="120"/>
+ <!--
+ Interval in seconds between first and second pass of periodic recovery.
+ Default is 10 seconds.
+ -->
+ <property
+ name="com.arjuna.ats.arjuna.recovery.recoveryBackoffPeriod" value="10"/>
+ <!--
+ The port number on which the recovery manager listens.
+ -->
+ <property name="com.arjuna.ats.arjuna.recovery.recoveryPort" value="4712"/>
+ <!--
+ The address on which the recovery manager listens.
+ If running within an AS then the address the AS is bound to (jboss.bind.address) takes precedence
+ -->
+ <property name="com.arjuna.ats.arjuna.recovery.recoveryAddress" value=""/>
+ <!--
+ Periodic recovery modules to use. Invoked in sort-order of names.
+ -->
+ <property
+ name="com.arjuna.ats.arjuna.recovery.recoveryExtension1" value="com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule"/>
+ <property
+ name="com.arjuna.ats.arjuna.recovery.recoveryExtension2" value="com.arjuna.ats.internal.txoj.recovery.TORecoveryModule"/>
+ <property
+ name="com.arjuna.ats.arjuna.recovery.recoveryExtension3" value="com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule"/>
+ <!--
+ Expired entry removal
+ -->
+ <!--
+ Expiry scanners to use (order of invocation is random).
+ Names must begin with "com.arjuna.ats.arjuna.recovery.expiryScanner"
+ -->
+ <property
+ name="com.arjuna.ats.arjuna.recovery.expiryScannerTransactionStatusManager" value="com.arjuna.ats.internal.arjuna.recovery.ExpiredTransactionStatusManagerScanner"/>
+ <!--
+ Interval, in hours, between running the expiry scanners.
+ This can be quite long. The absolute value determines the interval -
+ if the value is negative, the scan will NOT be run until after one
+ interval has elapsed. If positive the first scan will be immediately
+ after startup. Zero will prevent any scanning.
+ Default = 12 = run immediately, then every 12 hours.
+ -->
+ <property
+ name="com.arjuna.ats.arjuna.recovery.expiryScanInterval" value="12"/>
+ <!--
+ This is the interval, in hours, after which a process that cannot be contacted will be considered dead.
+ It should be long enough to avoid accidentally removing valid entries due to short lived
+ transient errors such as network downtime. Zero = Never removed. Default is 12.
+ -->
+ <property
+ name="com.arjuna.ats.arjuna.recovery.transactionStatusManagerExpiryTime" value="12"/>
+ <!--
+ Use this to fix the port on which the TransactionStatusManager listens,
+ The default behaviour is to use any free port.
+ -->
+ <property
+ name="com.arjuna.ats.arjuna.recovery.transactionStatusManagerPort" value="0"/>
+ <!--
+ Use this to fix the address on which the TransactionStatusManager binds,
+ The default behaviour is to use the loopback address (ie localhost).
+ If running within an AS then the address the AS is bound to (jboss.bind.address) takes precedence
+ -->
+ <property
+ name="com.arjuna.ats.arjuna.recovery.transactionStatusManagerAddress" value=""/>
+ <!--
+ For cases where the recovery manager is in process with the transaction manager and nothing else uses
+ the ObjectStore, it is possible to disable the socket based recovery listener by setting this to NO.
+ Caution: use of this property can allow multiple recovery processes to run on the same ObjectStore
+ if you are not careful. That in turn can lead to incorrect transaction processing. Use with care.
+ -->
+ <property name="com.arjuna.ats.arjuna.recovery.recoveryListener" value="NO"/>
+ </properties>
+ <properties depends="jta" name="jdbc">
+ <!--
+ property name="com.arjuna.ats.jdbc.isolationLevel" value="TRANSACTION_SERIALIZABLE"/>
+ -->
+ </properties>
+</transaction-service>
Property changes on: labs/jbosstm/workspace/resttx/src/test/resources/jbossjta-properties.xml
___________________________________________________________________
Name: svn:mergeinfo
+
Modified: labs/jbosstm/workspace/resttx/src/test/resources/log4j.xml
===================================================================
--- labs/jbosstm/workspace/resttx/src/test/resources/log4j.xml 2009-02-02 17:28:58 UTC (rev 25060)
+++ labs/jbosstm/workspace/resttx/src/test/resources/log4j.xml 2009-02-02 18:59:59 UTC (rev 25061)
@@ -22,14 +22,20 @@
</layout>
</appender>
+ <category name="org.jboss.resteasy">
+ <level value="WARN"/>
+ <appender-ref ref="console"/>
+ <appender-ref ref="file"/>
+ </category>
+
<category name="org.jboss.jbossts.rts">
- <level value="TRACE"/>
+ <level value="INFO"/>
<appender-ref ref="console"/>
<appender-ref ref="file"/>
</category>
<category name="com.arjuna">
- <level value="INFO"/>
+ <level value="WARN"/>
<appender-ref ref="console"/>
<appender-ref ref="file"/>
</category>
More information about the jboss-svn-commits
mailing list