[JBoss JIRA] Created: (JBTM-222) TestLevels common test does not work on Windows
by Mark Little (JIRA)
TestLevels common test does not work on Windows
-----------------------------------------------
Key: JBTM-222
URL: http://jira.jboss.com/jira/browse/JBTM-222
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Testing
Affects Versions: 4.2.3.SP3
Environment: Windows XP SP2. JRockit 5.0.
Reporter: Mark Little
Assigned To: Jonathan Halliday
Fix For: 4.4
TestLevels.java doesn't run correctly on Windows. It looks as though there could be a few things wrong:
(i) log4j isn't initialised correctly (though that could be local to my environment).
(ii) the test doesn't account for the differences in Windows versus Un*x formatting, so for example where there should only be 5 lines of debugging (and are on Un*x), there are 9 on Windows because there are 4 blank lines.
(iii) the resource bundle TestLevels_en_GB is not picked up, so the regex fails.
(iv) naming of threads is slightly different on Windows to Un*x
.line 0 DEBUG [main] (TestLevels.java:89) com.hp.mwtests.commonlogging.testlevels.TestLevels.writeLogMessages(TestLevels.java:89) - [testMessage] This is the 1st message, logged at level debug.
.line 0 DEBUG [Main Thread] (TestLevels.java:89) com.hp.mwtests.commonlogging.testlevels.TestLevels.writeLogMessages(TestLevels.java:89) - no default resource bundle set for this logger: [key='testMessage']1st, debug,
I'm using JRockit and am unsure which of the above are due entirely to my setup, but if at least one of them is general it will cause the test to fail on Windows anyway.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 2 months
[JBoss JIRA] Updated: (JBTM-14) Transactions over JBoss remoting support
by Mark Little (JIRA)
[ http://jira.jboss.com/jira/browse/JBTM-14?page=all ]
Mark Little updated JBTM-14:
----------------------------
Fix Version/s: 4.4
Assignee: Jonathan Halliday (was: Francisco Reverbel)
> Transactions over JBoss remoting support
> ----------------------------------------
>
> Key: JBTM-14
> URL: http://jira.jboss.com/jira/browse/JBTM-14
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: JTS Implementation, JTA Implementation
> Reporter: Mark Little
> Assigned To: Jonathan Halliday
> Priority: Minor
> Fix For: 4.4
>
>
> To the best of my knowledge, only the following features are present in the current JBoss TX codebase that are not present in the JTA/JTS codebase of ATS:
> - transactions over JBoss Remoting
> Francisco Reverbel commented: "Besides transactions over IIOP and JBoss Remoting, the JBoss TX codebase
> supports mixing these transports in a single transaction, e.g:
> - EJB-A, EJB-B, and EJB-C are deployed in different JBossAS instances
> - EJB-A has an IIOP ejb-ref to EJB-B and a JBRem ejb-ref to EJB-C
> - within a transaction, EJB-A uses these references to call EJB-B
> and EJB-C
> - at transction commit time, the coordinator TM drives the 2PC protocol
> using IIOP/OTS to talk to EJB-B's TM and JBRem/DTM to talk to EJB-C's
> TM.
> Support to a given transport is configurable: an appserver or EJB
> may support just JBRem, just IIOP, or both. (My plan was to have
> SOAP/WS-AT as a choice also.) This poses an interesting case: a root
> coordinator and some leaf server (which is acting as a remote resource)
> may not support the same transport. Example: server1 supports only IIOP,
> server2 supports both IIOP and JBRem, and server3 supports only JBRem.
> Within a transaction, server1 issues an IIOP request to server2, which
> calls server3 over JBRem. In such a case, JBoss TX automatically
> interposes a subordinate coordinator. (Talking of JBRem as a transport
> is a simplification, BTW. JBoss Remoting runs over various transports,
> so instead of "JBRem" I should have said "JBRem-sockets", or
> "JBRem-HTTP", or whatever...)
> All this is only in HEAD (no customers yet), so it might not be relevant
> for ATS integration. Still, I think the features are nice to keep. And
> it would be great to have SOAP/WS-AT alongside IIOP/OTS and JBRem."
> As far as the product release is concerned, I'd like to push this out to after the initial 4.2 integration period, unless there's a pressing need for it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 6 months