View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-cache-testsuite?log=log20060204024840
TESTS FAILEDAnt Error Message: /services/cruisecontrol/work/scripts/build-JBossCache.xml:96: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-remoting-testsuite-1.4?log=log20060204032749
TESTS FAILEDAnt Error Message: /services/cruisecontrol/work/scripts/build-jboss-remoting.xml:96: The following error occurred while executing this line: /services/cruisecontrol/wo
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-remoting-testsuite-1.5?log=log20060204034707
TESTS FAILEDAnt Error Message: /services/cruisecontrol/work/scripts/build-jboss-remoting.xml:96: The following error occurred while executing this line: /services/cruisecontrol/wo
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/ejb3-4.0-testsuite?log=log20060204055531
BUILD FAILEDAnt Error Message: /services/cruisecontrol/work/scripts/build-ejb3-4.0-testsuite.xml:83: Exit code: 1 See tests.log in Build Artifacts for details.Date of build: 02/04
My bad sorry!!! :-(
I can't just copy the source from head because it has
incompatible changes that need to be fixed.
I guess this was also the problem with the build timeout
Ryan and Brian were looking at concurrently?
On Fri, 2006-02-03 at 22:01, Bill Burke wrote:
> JMSDestinationManager had t
not in classloader, i mean you can get a reference to a method call and do:
CtMethod.replace("return callSomeOtherMethod(5, 4, 2");
You still need to work with bytecode form before classload. Although,
with JDK 5, you can replace a method or constructor implementation at
runtime.
Steve Eber
I don't think it is a good idea to invoke Thread.stop().
This has memory leak problems.
Why was this introduced? The pooled threads are already daemon threads
so they should not stop the system from exiting at shutdown.
If you are not shutting down the system, then any objects
on the stopped thre
It was the only way I found to implement a timeout behavior that had a
chance of working when there were uncooperative tasks. See the
org.jboss.test.util.test.
ThreadPoolTaskUnitTestCase.testCompleteTimeoutWithSpinLoop as an
example.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAI
On Sat, 2006-02-04 at 17:44, Scott M Stark wrote:
> It was the only way I found to implement a timeout behavior that had a
> chance of working when there were uncooperative tasks. See the
> org.jboss.test.util.test.
> ThreadPoolTaskUnitTestCase.testCompleteTimeoutWithSpinLoop as an
> example.
Ther
Its kind of sad there is no solution to this after all of this time.
Gosh Java sucks... ;-) I'm sure it all works perfectly in NuFuBarX
lang...we must migrate JBoss immediately.
Adrian Brock wrote:
On Sat, 2006-02-04 at 17:44, Scott M Stark wrote:
It was the only way I found to implement a
This sounds like a good blog:
"Sun, we want fixes not new features"
Talk about this thread problem as well as the serialization problems.
Adrian Brock wrote:
On Sat, 2006-02-04 at 17:44, Scott M Stark wrote:
It was the only way I found to implement a timeout behavior that had a
chance of wor
11 matches
Mail list logo
