[JBoss JIRA] (JBTM-1625) Retain the commit id of the app server being used for testing
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1625?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris updated JBTM-1625:
----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/jbosstm/narayana/pull/266
> Retain the commit id of the app server being used for testing
> -------------------------------------------------------------
>
> Key: JBTM-1625
> URL: https://issues.jboss.org/browse/JBTM-1625
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Build System
> Reporter: Tom Jenkinson
> Assignee: Gytis Trikleris
> Priority: Critical
> Fix For: 5.0.0.M3
>
> Original Estimate: 10 minutes
> Remaining Estimate: 10 minutes
>
> When we rebase jboss-as we should log the commit of the rebased master branch.
> If you just add the command:
> echo This is the JBoss-AS commit
> git rev-parse upstream/master
> That will be enough as the build log will have:
> This is the JBoss-AS commit
> d56a7873e277017e56fcbfc74f814e0d2703f503
> For example.
> This is important when we have problems introduced in the AS so we can help to identify when the problem is first observed more defined way than a timestamp (which is timezoned against a failure in Newcastle and a GitHub timestamp (whenever they are)).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (JBTM-1625) Retain the commit id of the app server being used for testing
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1625?focusedWorklogId=12428995&page=... ]
Gytis Trikleris logged work on JBTM-1625:
-----------------------------------------
Author: Gytis Trikleris
Created on: 10/Apr/13 9:08 AM
Start Date: 10/Apr/13 9:08 AM
Worklog Time Spent: 10 minutes
Issue Time Tracking
-------------------
Remaining Estimate: 0 minutes (was: 10 minutes)
Time Spent: 10 minutes
Worklog Id: (was: 12428995)
> Retain the commit id of the app server being used for testing
> -------------------------------------------------------------
>
> Key: JBTM-1625
> URL: https://issues.jboss.org/browse/JBTM-1625
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Build System
> Reporter: Tom Jenkinson
> Assignee: Gytis Trikleris
> Priority: Critical
> Fix For: 5.0.0.M3
>
> Original Estimate: 10 minutes
> Time Spent: 10 minutes
> Remaining Estimate: 0 minutes
>
> When we rebase jboss-as we should log the commit of the rebased master branch.
> If you just add the command:
> echo This is the JBoss-AS commit
> git rev-parse upstream/master
> That will be enough as the build log will have:
> This is the JBoss-AS commit
> d56a7873e277017e56fcbfc74f814e0d2703f503
> For example.
> This is important when we have problems introduced in the AS so we can help to identify when the problem is first observed more defined way than a timestamp (which is timezoned against a failure in Newcastle and a GitHub timestamp (whenever they are)).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (JBTM-1625) Retain the commit id of the app server being used for testing
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1625?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris updated JBTM-1625:
----------------------------------
Original Estimate: 10 minutes
Remaining Estimate: 10 minutes
> Retain the commit id of the app server being used for testing
> -------------------------------------------------------------
>
> Key: JBTM-1625
> URL: https://issues.jboss.org/browse/JBTM-1625
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Build System
> Reporter: Tom Jenkinson
> Assignee: Gytis Trikleris
> Priority: Critical
> Fix For: 5.0.0.M3
>
> Original Estimate: 10 minutes
> Remaining Estimate: 10 minutes
>
> When we rebase jboss-as we should log the commit of the rebased master branch.
> If you just add the command:
> echo This is the JBoss-AS commit
> git rev-parse upstream/master
> That will be enough as the build log will have:
> This is the JBoss-AS commit
> d56a7873e277017e56fcbfc74f814e0d2703f503
> For example.
> This is important when we have problems introduced in the AS so we can help to identify when the problem is first observed more defined way than a timestamp (which is timezoned against a failure in Newcastle and a GitHub timestamp (whenever they are)).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (JBTM-1617) When testing pull requests do a rebase to the merge point
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1617?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris updated JBTM-1617:
----------------------------------
Original Estimate: 2 hours
Remaining Estimate: 2 hours
> When testing pull requests do a rebase to the merge point
> ---------------------------------------------------------
>
> Key: JBTM-1617
> URL: https://issues.jboss.org/browse/JBTM-1617
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Build System
> Reporter: Tom Jenkinson
> Assignee: Gytis Trikleris
> Priority: Critical
> Fix For: 4.17.4, 5.0.0.M3
>
> Original Estimate: 2 hours
> Remaining Estimate: 2 hours
>
> These instructions can go in the pull job config rather than narayana.sh I think as they do a full clean and that would be dangerous on a dev box
> # Clean up the local repo
> git rebase --abort
> rm -rf .git/rebase-apply
> git clean -f -d -x
> # Work out the branch point
> git branch -D 4.17
> git branch 4.17 origin/4.17
> git branch -D master
> git branch master origin/master
> myRev=`git rev-parse HEAD`
> ancestor417=`git merge-base $myRev 4.17`
> ancestorMaster=`git merge-base $myRev master`
> distanceFromMaster=`git log $ancestorMaster..$myRev | grep commit | wc | cut -c 1-7 | tr -d ' '`
> distanceFrom417=`git log $ancestor417..$myRev | grep commit | wc | cut -c 1-7 | tr -d ' '`
> if [ "$distanceFromMaster" -lt "$distanceFrom417" ]
> then
> export BRANCHPOINT=master
> else
> export BRANCHPOINT=4.17
> fi
> # Update the pull to head
> git pull --rebase --ff-only origin $BRANCHPOINT
> # if this fails ($? -ne 0) fail the build and tell the committer (commentOnPull) that they need to rebase
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (JBTM-1617) When testing pull requests do a rebase to the merge point
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1617?focusedWorklogId=12428944&page=... ]
Gytis Trikleris logged work on JBTM-1617:
-----------------------------------------
Author: Gytis Trikleris
Created on: 10/Apr/13 7:28 AM
Start Date: 10/Apr/13 7:28 AM
Worklog Time Spent: 2 hours
Issue Time Tracking
-------------------
Remaining Estimate: 0 minutes (was: 2 hours)
Time Spent: 2 hours
Worklog Id: (was: 12428944)
> When testing pull requests do a rebase to the merge point
> ---------------------------------------------------------
>
> Key: JBTM-1617
> URL: https://issues.jboss.org/browse/JBTM-1617
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Build System
> Reporter: Tom Jenkinson
> Assignee: Gytis Trikleris
> Priority: Critical
> Fix For: 4.17.4, 5.0.0.M3
>
> Original Estimate: 2 hours
> Time Spent: 2 hours
> Remaining Estimate: 0 minutes
>
> These instructions can go in the pull job config rather than narayana.sh I think as they do a full clean and that would be dangerous on a dev box
> # Clean up the local repo
> git rebase --abort
> rm -rf .git/rebase-apply
> git clean -f -d -x
> # Work out the branch point
> git branch -D 4.17
> git branch 4.17 origin/4.17
> git branch -D master
> git branch master origin/master
> myRev=`git rev-parse HEAD`
> ancestor417=`git merge-base $myRev 4.17`
> ancestorMaster=`git merge-base $myRev master`
> distanceFromMaster=`git log $ancestorMaster..$myRev | grep commit | wc | cut -c 1-7 | tr -d ' '`
> distanceFrom417=`git log $ancestor417..$myRev | grep commit | wc | cut -c 1-7 | tr -d ' '`
> if [ "$distanceFromMaster" -lt "$distanceFrom417" ]
> then
> export BRANCHPOINT=master
> else
> export BRANCHPOINT=4.17
> fi
> # Update the pull to head
> git pull --rebase --ff-only origin $BRANCHPOINT
> # if this fails ($? -ne 0) fail the build and tell the committer (commentOnPull) that they need to rebase
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (JBTM-1617) When testing pull requests do a rebase to the merge point
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1617?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris updated JBTM-1617:
----------------------------------
Fix Version/s: 4.17.4
> When testing pull requests do a rebase to the merge point
> ---------------------------------------------------------
>
> Key: JBTM-1617
> URL: https://issues.jboss.org/browse/JBTM-1617
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Build System
> Reporter: Tom Jenkinson
> Assignee: Gytis Trikleris
> Priority: Critical
> Fix For: 4.17.4, 5.0.0.M3
>
>
> These instructions can go in the pull job config rather than narayana.sh I think as they do a full clean and that would be dangerous on a dev box
> # Clean up the local repo
> git rebase --abort
> rm -rf .git/rebase-apply
> git clean -f -d -x
> # Work out the branch point
> git branch -D 4.17
> git branch 4.17 origin/4.17
> git branch -D master
> git branch master origin/master
> myRev=`git rev-parse HEAD`
> ancestor417=`git merge-base $myRev 4.17`
> ancestorMaster=`git merge-base $myRev master`
> distanceFromMaster=`git log $ancestorMaster..$myRev | grep commit | wc | cut -c 1-7 | tr -d ' '`
> distanceFrom417=`git log $ancestor417..$myRev | grep commit | wc | cut -c 1-7 | tr -d ' '`
> if [ "$distanceFromMaster" -lt "$distanceFrom417" ]
> then
> export BRANCHPOINT=master
> else
> export BRANCHPOINT=4.17
> fi
> # Update the pull to head
> git pull --rebase --ff-only origin $BRANCHPOINT
> # if this fails ($? -ne 0) fail the build and tell the committer (commentOnPull) that they need to rebase
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (JBTM-1617) When testing pull requests do a rebase to the merge point
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1617?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris updated JBTM-1617:
----------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/jbosstm/narayana/pull/264, https://github.com/jbosstm/narayana/pull/265
> When testing pull requests do a rebase to the merge point
> ---------------------------------------------------------
>
> Key: JBTM-1617
> URL: https://issues.jboss.org/browse/JBTM-1617
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Build System
> Reporter: Tom Jenkinson
> Assignee: Gytis Trikleris
> Priority: Critical
> Fix For: 4.17.4, 5.0.0.M3
>
>
> These instructions can go in the pull job config rather than narayana.sh I think as they do a full clean and that would be dangerous on a dev box
> # Clean up the local repo
> git rebase --abort
> rm -rf .git/rebase-apply
> git clean -f -d -x
> # Work out the branch point
> git branch -D 4.17
> git branch 4.17 origin/4.17
> git branch -D master
> git branch master origin/master
> myRev=`git rev-parse HEAD`
> ancestor417=`git merge-base $myRev 4.17`
> ancestorMaster=`git merge-base $myRev master`
> distanceFromMaster=`git log $ancestorMaster..$myRev | grep commit | wc | cut -c 1-7 | tr -d ' '`
> distanceFrom417=`git log $ancestor417..$myRev | grep commit | wc | cut -c 1-7 | tr -d ' '`
> if [ "$distanceFromMaster" -lt "$distanceFrom417" ]
> then
> export BRANCHPOINT=master
> else
> export BRANCHPOINT=4.17
> fi
> # Update the pull to head
> git pull --rebase --ff-only origin $BRANCHPOINT
> # if this fails ($? -ne 0) fail the build and tell the committer (commentOnPull) that they need to rebase
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (JBTM-1617) When testing pull requests do a rebase to the merge point
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1617?page=com.atlassian.jira.plugin.... ]
Work on JBTM-1617 started by Gytis Trikleris.
> When testing pull requests do a rebase to the merge point
> ---------------------------------------------------------
>
> Key: JBTM-1617
> URL: https://issues.jboss.org/browse/JBTM-1617
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Build System
> Reporter: Tom Jenkinson
> Assignee: Gytis Trikleris
> Priority: Critical
> Fix For: 5.0.0.M3
>
>
> These instructions can go in the pull job config rather than narayana.sh I think as they do a full clean and that would be dangerous on a dev box
> # Clean up the local repo
> git rebase --abort
> rm -rf .git/rebase-apply
> git clean -f -d -x
> # Work out the branch point
> git branch -D 4.17
> git branch 4.17 origin/4.17
> git branch -D master
> git branch master origin/master
> myRev=`git rev-parse HEAD`
> ancestor417=`git merge-base $myRev 4.17`
> ancestorMaster=`git merge-base $myRev master`
> distanceFromMaster=`git log $ancestorMaster..$myRev | grep commit | wc | cut -c 1-7 | tr -d ' '`
> distanceFrom417=`git log $ancestor417..$myRev | grep commit | wc | cut -c 1-7 | tr -d ' '`
> if [ "$distanceFromMaster" -lt "$distanceFrom417" ]
> then
> export BRANCHPOINT=master
> else
> export BRANCHPOINT=4.17
> fi
> # Update the pull to head
> git pull --rebase --ff-only origin $BRANCHPOINT
> # if this fails ($? -ne 0) fail the build and tell the committer (commentOnPull) that they need to rebase
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (JBTM-1626) Service jboss.binding.undefined not found in AdvertiseUnadvertiseTest
by Gytis Trikleris (JIRA)
Gytis Trikleris created JBTM-1626:
-------------------------------------
Summary: Service jboss.binding.undefined not found in AdvertiseUnadvertiseTest
Key: JBTM-1626
URL: https://issues.jboss.org/browse/JBTM-1626
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: BlackTie
Reporter: Gytis Trikleris
Assignee: Amos Feng
Priority: Minor
Fix For: 5.0.0.M3
http://172.17.131.2/job/blacktie-linux64/1469
{noformat}
Running AdvertiseUnadvertiseTest
2013-04-10 07:43:10,924 [main] INFO (org.xnio :73 ) - XNIO Version 3.1.0.Beta9
2013-04-10 07:43:10,946 [main] INFO (xnio.nio :51 ) - XNIO NIO Implementation Version 3.1.0.Beta9
2013-04-10 07:43:11,013 [main] INFO (jboss.remoting :70 ) - JBoss Remoting version 3.2.15.GA
[0m07:43:12,415 INFO [org.jboss.as.repository] (management-handler-thread - 5) JBAS014900: Content added at location /home/hudson/workspace/blacktie-linux64/jboss-as/standalone/data/content/03/0b85cbbfba334c502c74b16edf96ec3b7c581d/content
[0m[0m07:43:12,417 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015876: Starting deployment of "test.war" (runtime-name: "test.war")
[0m[33m07:43:13,135 WARN [org.jboss.as.dependency.private] (MSC service thread 1-3) JBAS018567: Deployment "deployment.test.war" is using a private module ("org.jboss.jts:main") which may be changed or removed in future versions without notice.
[0m[33m07:43:13,346 WARN [org.jboss.weld.deployer] (MSC service thread 1-4) JBAS016012: Deployment deployment "test.war" contains CDI annotations but beans.xml was not found.
[0m[0m07:43:13,482 INFO [org.jboss.as.ejb3] (MSC service thread 1-2) JBAS014142: Started message driven bean 'BlacktieStompAdministrationService' with 'hornetq-ra' resource adapter
[0m[0m07:43:13,487 INFO [org.jboss.as.undertow] (MSC service thread 1-1) JBAS018210: Register web context: /test
[0m[0m07:43:13,523 INFO [org.hornetq.ra] (default-threads - 1) HQ151000: awaiting topic/queue creation queue/BTR_BTStompAdmin
[0m[0m07:43:13,638 INFO [org.jboss.as.server] (management-handler-thread - 5) JBAS018559: Deployed "test.war" (runtime-name : "test.war")
[0m[31m07:43:14,344 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 7) JBAS014612: Operation ("read-attribute") failed - address: ({
"socket-binding-group" => "standard-sockets",
"socket-binding" => "undefined"
}): org.jboss.msc.service.ServiceNotFoundException: Service service jboss.binding.undefined not found
at org.jboss.msc.service.ServiceContainerImpl.getRequiredService(ServiceContainerImpl.java:625) [jboss-msc-1.1.2.Final.jar:1.1.2.Final]
at org.jboss.as.controller.OperationContextImpl$OperationContextServiceRegistry.getRequiredService(OperationContextImpl.java:1081) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.server.services.net.BindingMetricHandlers$AbstractBindingMetricsHandler$1.execute(BindingMetricHandlers.java:66) [jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:439) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:321) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:228) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:223) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:193) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:114) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108) [jboss-as-controller-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [jboss-as-protocol-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [jboss-as-protocol-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
[0m[0m07:43:14,419 INFO [org.jboss.as.undertow] (MSC service thread 1-3) JBAS018224: Unregister web context: /test
[0m[0m07:43:14,446 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015877: Stopped deployment test.war (runtime-name: test.war) in 56ms
[0m[0m07:43:14,539 INFO [org.jboss.as.repository] (management-handler-thread - 8) JBAS014901: Content removed from location /home/hudson/workspace/blacktie-linux64/jboss-as/standalone/data/content/03/0b85cbbfba334c502c74b16edf96ec3b7c581d/content
[0m[0m07:43:14,539 INFO [org.jboss.as.server] (management-handler-thread - 8) JBAS018558: Undeployed "test.war" (runtime-name: "test.war")
[0mTests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 5.814 sec <<< FAILURE!
Results :
Tests in error:
AdvertiseUnadvertiseTest: org.jboss.as.arquillian.container.ManagementClient$UnSuccessfulOperationException: "JBAS014749: Operation handler failed: Service service jboss.binding.undefined not found"
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (JBTM-1622) StackOverflowError when loading org.jboss.ws.common:main module
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1622?page=com.atlassian.jira.plugin.... ]
Paul Robinson edited comment on JBTM-1622 at 4/10/13 4:06 AM:
--------------------------------------------------------------
Fails:
jaime, CentOS 5.8 32bit, JDK 1.7.0_09
tenafly, CentOS 6 32bit, JDK 1.7.0_17
Passes:
beacon, CentOS 5.6, 64bit, JDK 1.7.0_17
hoboken, CentOS 6, 64bit, JDK 1.7.0_17
Seems to only fail on 32bit machines: jaime & tenafly. Succeeds on 64 bit beacon and hoboken.
jaime is running JDK 1.7.0_09, where as hoboken runs jdk1.7.0_17. I tried running the test many times (~5) on hoboken with JDK 1.7.0_09, but I couldn't get it to fail.
was (Author: paul.robinson):
Seems to only fail on 32bit machines: jaime & tenafly. Succeeds on 64 bit beacon and hoboken.
jaime is running JDK 1.7.0_09, where as hoboken runs jdk1.7.0_17. I tried running the test many times (~5) on hoboken with JDK 1.7.0_09, but I couldn't get it to fail.
> StackOverflowError when loading org.jboss.ws.common:main module
> ---------------------------------------------------------------
>
> Key: JBTM-1622
> URL: https://issues.jboss.org/browse/JBTM-1622
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: XTS
> Reporter: Gytis Trikleris
> Assignee: Paul Robinson
> Priority: Minor
> Fix For: 5.0.0.M3
>
>
> See: http://172.17.131.2/job/narayana/229
> {noformat}
> Tests in error:
> testRollback(org.jboss.as.test.xts.simple.wsat.client.WSATTestCase): Receiver[com.arjuna.webservices.util.InvalidEnumerationException: ARJUNA042002: Invalid fault type enumeration: No namespace on "html" element. You must send a SOAP request.][com.arjuna.webservices.util.InvalidEnumerationException: ARJUNA042002: Invalid fault type enumeration: No namespace on "html" element. You must send a SOAP request.(..)
> testCommit(org.jboss.as.test.xts.simple.wsat.client.WSATTestCase): Receiver[com.arjuna.webservices.util.InvalidEnumerationException: ARJUNA042002: Invalid fault type enumeration: No namespace on "html" element. You must send a SOAP request.][com.arjuna.webservices.util.InvalidEnumerationException: ARJUNA042002: Invalid fault type enumeration: No namespace on "html" element. You must send a SOAP request.(..)
> testCannotComplete(org.jboss.as.test.xts.simple.wsba.coordinatorcompletion.client.WSBACoordinatorCompletionTestCase): Unexpected exception, expected<com.arjuna.wst.TransactionRolledBackException> but was<java.lang.Exception>
> testCancel(org.jboss.as.test.xts.simple.wsba.coordinatorcompletion.client.WSBACoordinatorCompletionTestCase): Receiver[com.arjuna.webservices.util.InvalidEnumerationException: ARJUNA042002: Invalid fault type enumeration: No namespace on "html" element. You must send a SOAP request.][com.arjuna.webservices.util.InvalidEnumerationException: ARJUNA042002: Invalid fault type enumeration: No namespace on "html" element. You must send a SOAP request.(..)
> testSuccess(org.jboss.as.test.xts.simple.wsba.coordinatorcompletion.client.WSBACoordinatorCompletionTestCase): Receiver[com.arjuna.webservices.util.InvalidEnumerationException: ARJUNA042002: Invalid fault type enumeration: No namespace on "html" element. You must send a SOAP request.][com.arjuna.webservices.util.InvalidEnumerationException: ARJUNA042002: Invalid fault type enumeration: No namespace on "html" element. You must send a SOAP request.(..)
> testCancel(org.jboss.as.test.xts.simple.wsba.participantcompletion.client.WSBAParticipantCompletionTestCase): Receiver[com.arjuna.webservices.util.InvalidEnumerationException: ARJUNA042002: Invalid fault type enumeration: No namespace on "html" element. You must send a SOAP request.][com.arjuna.webservices.util.InvalidEnumerationException: ARJUNA042002: Invalid fault type enumeration: No namespace on "html" element. You must send a SOAP request.(..)
> testSuccess(org.jboss.as.test.xts.simple.wsba.participantcompletion.client.WSBAParticipantCompletionTestCase): Receiver[com.arjuna.webservices.util.InvalidEnumerationException: ARJUNA042002: Invalid fault type enumeration: No namespace on "html" element. You must send a SOAP request.][com.arjuna.webservices.util.InvalidEnumerationException: ARJUNA042002: Invalid fault type enumeration: No namespace on "html" element. You must send a SOAP request.(..)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months