[JBoss-dev] jboss-cache-testsuite Build Completed With Testsuite Errors

2006-02-04 Thread qa 

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/build-common-targets.xml:11: Build Successful - Tests completed with errors or failures.Date of build: 02/04/2006 02:48:40Time to build: 38 minutes 53 secondsLast changed: 12/28/2005 10:48:11Last log entry: Add the 1.2.4SP1 changelog notes.




    Unit Tests: (1349)    Total Errors and Failures: (41)testorg.jboss.cache.ConcurrentEvictAndRemoveTesttestAllTx_RWLockorg.jboss.cache.EvictionLocalStressTesttestDataSourceIntegrationorg.jboss.cache.loader.DataSourceIntegrationTesttestCollectionWithCacheLoaderorg.jboss.cache.aop.loader.FileCacheLoaderAopTesttestConcurrentUseSyncorg.jboss.cache.aop.statetransfer.StateTransfer1241AopTesttestConcurrentUseSyncorg.jboss.cache.aop.statetransfer.StateTransfer124AopTesttestConcurrentUseSyncorg.jboss.cache.aop.statetransfer.StateTransfer130AopTestwarningorg.jboss.cache.benchmark.support.BaseTestwarningorg.jboss.cache.benchmark.support.Read50PercentTestwarningorg.jboss.cache.benchmark.support.Read75PercentTestwarningorg.jboss.cache.benchmark.support.Read90PercentTestwarningorg.jboss.cache.benchmark.tests.HashMapRead50JRunitTestwarningorg.jboss.cache.benchmark.tests.HashMapRead75JRunitTestwarningorg.jboss.cache.benchmark.tests.HashMapRead90JRunitTestwarningorg.jboss.cache.benchmark.tests.LocalPessIsoNoneRead50JRunitTestwarningorg.jboss.cache.benchmark.tests.LocalPessIsoNoneRead75JRunitTestwarningorg.jboss.cache.benchmark.tests.LocalPessIsoNoneRead90JRunitTestwarningorg.jboss.cache.benchmark.tests.LocalPessIsoRRRead50JRunitTestwarningorg.jboss.cache.benchmark.tests.LocalPessIsoRRRead75JRunitTestwarningorg.jboss.cache.benchmark.tests.LocalPessIsoRRRead90JRunitTestwarningorg.jboss.cache.benchmark.tests.ReplAsyncPessRead50JRunitTestwarningorg.jboss.cache.benchmark.tests.ReplAsyncPessRead75JRunitTestwarningorg.jboss.cache.benchmark.tests.ReplAsyncPessRead90JRunitTestwarningorg.jboss.cache.benchmark.tests.ReplSyncPessRead50JRunitTestwarningorg.jboss.cache.benchmark.tests.ReplSyncPessRead75JRunitTestwarningorg.jboss.cache.benchmark.tests.ReplSyncPessRead90JRunitTesttestUpdateEvictionorg.jboss.cache.eviction.AopLRUPolicyTesttestConcurrentPutAndEvictorg.jboss.cache.eviction.FIFOPolicyTesttestConcurrentPutAndEvictorg.jboss.cache.eviction.LFUPolicyTesttestConcurrentPutAndEvictorg.jboss.cache.eviction.LRUPolicyTesttestConcurrentPutAndEvictorg.jboss.cache.eviction.MRUPolicyTesttestOptSyncReplorg.jboss.cache.loader.CacheLoaderWithReplicationTesttestReadCommittedorg.jboss.cache.lock.LockTesttest2ReadersAnd1Writerorg.jboss.cache.lock.ReentrantWriterPreferenceReadWriteLockTestwarningorg.jboss.cache.optimistic.LocalCLTestwarningorg.jboss.cache.optimistic.LocalPessimisticCLTestwarningorg.jboss.cache.optimistic.LocalPessimisticTestwarningorg.jboss.cache.optimistic.LocalTesttestConcurrentUseAsyncorg.jboss.cache.statetransfer.StateTransfer130TesttestConcurrentAccessWithRWLockorg.jboss.cache.transaction.ConcurrentTransactionalTesttestNodeCreationRollbackorg.jboss.cache.transaction.IsolationLevelReadCommittedTest 
 Modifications since last build: (first 50 of 1351)1.3modifiedmsurtanitests/perf/org/jboss/cache/loader/CacheLoaderPerfTest.javaFixes rating to JBCACHE-118 - optimising cache loader functionality.1.2modifiedmsurtanitests/perf/org/jboss/cache/loader/CacheLoaderPerfTest.javaAdded a perf test to measure performance on basic operations with a cache loader1.1addedmsurtanitests/perf/org/jboss/cache/loader/CacheLoaderPerfTest.javaAdded a perf test to measure performance on basic operations with a cache loader1.2modifieddhuangtests/stress/org/jboss/cache/EvictionLocalStressTest.javaEviction policy refactoring to support 1 Policy per Region.Refactoring of Eviction Policies to allow for easier user extension.Introduce EvictionQueue and EvictionConfiguration interfaces.New Eviction Policies for MRU and LFU.Allow configuration of EvictionPolicies at runtime.References JIRA tasks:JBCACHE-314JBCACHE-313JBCACHE-312JBCACHE-286JBCACHE-225JBCACHE-2131.2modifieddhuangtests/stress/org/jboss/cache/LocalStressTest.javaEviction policy refactoring to support 1 Policy per Region.Refactoring of Eviction Policies to allow for easier user extension.Introduce EvictionQueue and EvictionConfiguration interfaces.New Eviction Policies for MRU and LFU.Allow configuration of EvictionPolicies at runtime.References JIRA tasks:JBCACHE-314JBCACHE-313JBCACHE-312JBCACHE-286JBCACHE-225JBCACHE-2131.1addedmsurtanitests/perf/org/jboss/cache/benchmark/tests/ReplAsyncPessRead50JRunitTest.javaAdded replicated tests1.1addedmsurtanitests/perf/org/jboss/cache/benchmark/tests/ReplAsyncPessRead75JRunitTest.javaAdded replicated tests1.1addedmsurt

[JBoss-dev] jboss-remoting-testsuite-1.4 Build Completed With Testsuite Errors

2006-02-04 Thread qa 

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/work/scripts/build-common-targets.xml:11: Build Successful - Tests completed with errors or failures.Date of build: 02/04/2006 03:27:49Time to build: 16 minutes 46 secondsLast changed: 02/03/2006 22:52:34Last log entry: JBREM-313 - fixed problem where client lease not working when client and server within same vm.




    Unit Tests: (140)    Total Errors and Failures: (3)testMultipleClientsDifferentLocatorsDontWaitOnServerorg.jboss.test.remoting.transport.multiplex.InvokerGroupTestCase(java_serialization)testMultipleClientsDifferentLocatorsWaitOnServerorg.jboss.test.remoting.transport.multiplex.InvokerGroupTestCase(java_serialization)testMultipleClientsMixedLocatorsorg.jboss.test.remoting.transport.multiplex.InvokerGroupTestCase(java_serialization) 
 Modifications since last build: (first 50 of 2)1.6modifiedtelrodsrc/main/org/jboss/remoting/transport/local/LocalClientInvoker.javaJBREM-313 - fixed problem where client lease not working when client and server within same vm.1.1addedtelrodsrc/tests/org/jboss/test/remoting/lease/LocalLeaseTestCase.javaJBREM-313 - added test case for client leasing when both client and server in same vm (so would use local invoker).

[JBoss-dev] jboss-remoting-testsuite-1.5 Build Completed With Testsuite Errors

2006-02-04 Thread qa 

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/work/scripts/build-common-targets.xml:11: Build Successful - Tests completed with errors or failures.Date of build: 02/04/2006 03:47:07Time to build: 72 minutes 33 secondsLast changed: 12/31/2005 20:37:24Last log entry: JBREM-272:Added tests for (clientPool != null) and (threadPool != null) in cleanup.




    Unit Tests: (283)    Total Errors and Failures: (3)testStartorg.jboss.test.remoting.callback.pull.memory.callbackstore.CallbackStoreCallbackTestCase(java_serialization)testStartorg.jboss.test.remoting.callback.pull.memory.callbackstore.CallbackStoreCallbackTestCase(jboss_serialization)testStartorg.jboss.test.remoting.handler.mbean.MBeanHandlerTestCase(java_serialization) 
 Modifications since last build: (first 50 of 2028)1.3modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/timeout/TimeoutClientTest.javaJBREM-235 - added new lgpl headers.1.3modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/timeout/TimeoutServerTest.javaJBREM-235 - added new lgpl headers.1.2modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/timeout/TimeoutTestCase.javaJBREM-235 - added new lgpl headers.1.3modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/web/ComplexObject.javaJBREM-235 - added new lgpl headers.1.4modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/web/WebInvocationHandler.javaJBREM-235 - added new lgpl headers.1.6modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/web/WebInvokerTestClient.javaJBREM-235 - added new lgpl headers.1.2modifiedtelrodsrc/tests/org/jboss/test/remoting/transporter/TestClient.javaJBREM-235 - added new lgpl headers.1.2modifiedtelrodsrc/tests/org/jboss/test/remoting/transporter/TestServer.javaJBREM-235 - added new lgpl headers.1.2modifiedtelrodsrc/tests/org/jboss/test/remoting/transporter/TestServerImpl.javaJBREM-235 - added new lgpl headers.1.2modifiedtelrodsrc/tests/org/jboss/test/remoting/transporter/TransporterTestCase.javaJBREM-235 - added new lgpl headers.1.2modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/SSLInvokerConstants.javaJBREM-235 - added new lgpl headers.1.4modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/basic/InvokerClientTest.javaJBREM-235 - added new lgpl headers.1.8modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/basic/InvokerServerTest.javaJBREM-235 - added new lgpl headers.1.4modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/basic/InvokerTestCase.javaJBREM-235 - added new lgpl headers.1.4modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/custom/InvokerClientTest.javaJBREM-235 - added new lgpl headers.1.7modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/custom/InvokerServerTest.javaJBREM-235 - added new lgpl headers.1.5modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/custom/InvokerTestCase.javaJBREM-235 - added new lgpl headers.1.2modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/test/SSLSimpleClient.javaJBREM-235 - added new lgpl headers.1.3modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/test/SSLSimpleServer.javaJBREM-235 - added new lgpl headers.1.6modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/timeout/keepalive/TimeoutClientTest.javaJBREM-235 - added new lgpl headers.1.6modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/timeout/keepalive/TimeoutServerTest.javaJBREM-235 - added new lgpl headers.1.7modifiedrsigalsrc/tests/org/jboss/test/remoting/transport/socket/ssl/basic/InvokerServerTest.javaJBREM-270:Replaced "," with "&"1.6modifiedrsigalsrc/tests/org/jboss/test/remoting/transport/socket/ssl/custom/InvokerServerTest.javaJBREM-270:Replaced "," with "&"1.5modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/web/WebInvokerTestClient.javaJBREM-253 - changed to use coyote connector by default instead of http server invoker.  Also adding many fixes so now only ssl related http tests are failing within the tests suite.1.3modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/.truststoreJBREM-214 - fixes for test failures (includes replacing keystore for ssl tests with one that will not expire for many years).1.6modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/basic/InvokerServerTest.javaJBREM-214 - fixes for test failures (includes replacing keystore for ssl tests with one that will not expire for many years).1.5modifiedtelrodsrc/tests/org/jboss/test/remoting/transport/socket/ssl/custom/InvokerServerTest.javaJBREM-214 - fixes for test failures (includes replacing keystore for ssl

[JBoss-dev] ejb3-4.0-testsuite Build Failed

2006-02-04 Thread qa 

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/2006 05:55:31Time to build: 27 minutes 1 secondLast changed: 12/31/2005 16:46:08Last log entry: call isOpen() when obtaining session so that HEM registers with EM with TXset cglib_use_reflection flag to false




    Unit Tests: (0)    Total Errors and Failures: (0) 
 Modifications since last build: (first 50 of 3659)1.3modifiedbillsrc/test/org/jboss/ejb3/test/tableperinheritance/unit/EntityUnitTestCase.javaEJBs and Persistence can now be within a .jar file1.7modifiedbillsrc/test/org/jboss/ejb3/test/timer/unit/RemoteUnitTestCase.javaEJBs and Persistence can now be within a .jar file1.6modifiedbillsrc/test/org/jboss/ejb3/test/txexceptions/unit/TxExceptionsTestCase.javaEJBs and Persistence can now be within a .jar file1.3modifiedbillsrc/test/org/jboss/ejb3/test/xmlcfg/unit/EntityUnitTestCase.javaEJBs and Persistence can now be within a .jar file1.4modifiedbdecostesrc/test/org/jboss/ejb3/test/txexceptions/Dao.javaapplication-exception support1.7modifiedbdecostesrc/test/org/jboss/ejb3/test/txexceptions/DaoBean.javaapplication-exception support1.1addedbdecostesrc/test/org/jboss/ejb3/test/txexceptions/DeploymentDescriptorAppException.javabranches:  1.1.2;application-exception support1.1addedbdecostesrc/test/org/jboss/ejb3/test/txexceptions/DeploymentDescriptorCheckedRollbackException.javabranches:  1.1.2;application-exception support1.5modifiedbdecostesrc/test/org/jboss/ejb3/test/txexceptions/unit/TxExceptionsTestCase.javaapplication-exception support1.2modifiedbdecostesrc/test/org/jboss/ejb3/test/wls/embeddedwar/QueueTestMDB.javabranches:  1.2.2;activateConfig to activationConfig1.2modifiedbdecostesrc/test/org/jboss/ejb3/test/wls/embeddedwar/TopicTestMDB.javabranches:  1.2.2;activateConfig to activationConfig1.1addedbdecostesrc/test/org/jboss/ejb3/test/wls/embeddedwar/unit/EmbeddedEjb3TestCase.javatest for embedded EJB3 in WLS1.1addedbdecostesrc/test/org/jboss/ejb3/test/wls/embeddedwar/Customer.javatest for embedded EJB3 in WLS1.1addedbdecostesrc/test/org/jboss/ejb3/test/wls/embeddedwar/CustomerDAOBean.javabranches:  1.1.2;test for embedded EJB3 in WLS1.1addedbdecostesrc/test/org/jboss/ejb3/test/wls/embeddedwar/CustomerDAOLocal.javabranches:  1.1.2;test for embedded EJB3 in WLS1.1addedbdecostesrc/test/org/jboss/ejb3/test/wls/embeddedwar/CustomerDAORemote.javabranches:  1.1.2;test for embedded EJB3 in WLS1.1addedbdecostesrc/test/org/jboss/ejb3/test/wls/embeddedwar/EmbeddedEJB3.jsptest for embedded EJB3 in WLS1.1addedbdecostesrc/test/org/jboss/ejb3/test/wls/embeddedwar/JndiTest.jsptest for embedded EJB3 in WLS1.1addedbdecostesrc/test/org/jboss/ejb3/test/wls/embeddedwar/QueueTestMDB.javatest for embedded EJB3 in WLS1.1addedbdecostesrc/test/org/jboss/ejb3/test/wls/embeddedwar/TopicTestMDB.javatest for embedded EJB3 in WLS1.3modifiedstarksmsrc/test/org/jboss/ejb3/test/xmlcfg/Customer.javaUpdate the jboss LGPL headers1.3modifiedstarksmsrc/test/org/jboss/ejb3/test/xmlcfg/EntityTest.javaUpdate the jboss LGPL headers1.6modifiedstarksmsrc/test/org/jboss/ejb3/test/xmlcfg/EntityTestBean.javaUpdate the jboss LGPL headers1.4modifiedstarksmsrc/test/org/jboss/ejb3/test/timer/TimerTester.javaUpdate the jboss LGPL headers1.9modifiedstarksmsrc/test/org/jboss/ejb3/test/timer/TimerTesterBean.javaUpdate the jboss LGPL headers1.2modifiedstarksmsrc/test/org/jboss/ejb3/test/timer/TimerTesterBean21.javaUpdate the jboss LGPL headers1.6modifiedstarksmsrc/test/org/jboss/ejb3/test/timer/unit/RemoteUnitTestCase.javaUpdate the jboss LGPL headers1.2modifiedstarksmsrc/test/org/jboss/ejb3/test/txexceptions/AnnotatedAppException.javaUpdate the jboss LGPL headers1.2modifiedstarksmsrc/test/org/jboss/ejb3/test/txexceptions/AppException.javaUpdate the jboss LGPL headers1.2modifiedstarksmsrc/test/org/jboss/ejb3/test/txexceptions/CheckedRollbackException.javaUpdate the jboss LGPL headers1.3modifiedstarksmsrc/test/org/jboss/ejb3/test/txexceptions/Dao.javaUpdate the jboss LGPL headers1.6modifiedstarksmsrc/test/org/jboss/ejb3/test/txexceptions/DaoBean.javaUpdate the jboss LGPL headers1.2modifiedstarksmsrc/test/org/jboss/ejb3/test/txexceptions/NoRollbackRemoteException.javaUpdate the jboss LGPL headers1.2modifiedstarksmsrc/test/org/jboss/ejb3/test/txexceptions/NoRollbackRuntimeException.javaUpdate the jboss LGPL headers1.2modifiedstarksmsrc/test/org/jboss/ejb3/test/txexceptions/RollbackRemoteException.javaUpdate the jboss LGPL headers1.2modifiedstarksmsrc/test/org/jboss/ejb3/test/txexceptions/RollbackRuntimeException.javaUpdate the jboss LGPL headers1.3modifiedstarksmsrc/test/org/jboss/ejb3/test/txexceptions/SimpleEntity.javaUpdate the jboss LGPL headers1.4mod

Re: [JBoss-dev] JMS problems on Branch_4_0

2006-02-04 Thread Adrian Brock 
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 typo.  it should be a null check instead of a 
> != null check.  Typo from backmerge.   I guess if you put down the code 
> for awhile you see it!
> 
> /**
>  * Gets the ID attribute of the JMSServer object
>  *
>  * @return   The ID value
>  */
> public String getID()
> {
>String ID = null;
> 
>while (true)
>{
>   try
>   {
>  if (stateManager != null)
> throw new IllegalStateException("Null state manager");
> 
> 
> Bill Burke wrote:
> > Let me expand on this.  When deploying an MDB3, it just hangs on 
> > deployment.  Thread dump shows this.
> > 
> > Same EJB 3.0 code (same dist).  MDB runs fine on 4.0.3SP1. I also see 
> > that the MDB EJB3 tests are passing in HEAD as well from nightly build 
> > from like 5 hours ago.  I haven't gotten a successful 4.0.x message 
> > since 10:30 am.  I also see a few build timeouts for Branch_4_0 at 5:30 
> > am and 7:30 am.  Again, has anybody committed any JMS stuff to branch 4 
> > that would effect this?
> > 
> > Bill Burke wrote:
> > 
> >> My MDB tests seem to be hanging, Can't figure out why.  I do a thread 
> >> dump and got the following...  Any clues?  Did somebody recently 
> >> change JMS on Branch_4_0?
> >>
> >> Thanks
> >>
> >>
> >> "RMI TCP Connection(2)-192.168.0.2" daemon prio=5 tid=0x27bbdcf0 
> >> nid=0xc78 runnable [0x285fc000..0x285ffd68]
> >> at java.lang.Throwable.fillInStackTrace(Native Method)
> >> at java.lang.Throwable.(Throwable.java:196)
> >> at java.lang.Exception.(Exception.java:41)
> >> at java.lang.RuntimeException.(RuntimeException.java:43)
> >> at 
> >> java.lang.IllegalStateException.(IllegalStateException.java:38)
> >> at 
> >> org.jboss.mq.server.JMSDestinationManager.getID(JMSDestinationManager.java:245)
> >>  
> >>
> >> at 
> >> org.jboss.mq.server.JMSServerInterceptorSupport.getID(JMSServerInterceptorSupport.java:92)
> >>  
> >>
> >> at 
> >> org.jboss.mq.server.TracingInterceptor.getID(TracingInterceptor.java:85)
> >> at 
> >> org.jboss.mq.server.JMSServerInvoker.getID(JMSServerInvoker.java:93)
> >> at org.jboss.mq.il.jvm.JVMServerIL.getID(JVMServerIL.java:101)
> >> at org.jboss.mq.Connection.askForAnID(Connection.java:1021)
> >> at org.jboss.mq.Connection.checkClientID(Connection.java:998)
> >> - locked <0x06c37de0> (a org.jboss.mq.SpyXAConnection)
> >> at 
> >> org.jboss.mq.SpyXAConnection.createXAQueueSession(SpyXAConnection.java:105)
> >>  
> >>
> >> at 
> >> org.jboss.jms.asf.StdServerSessionPool.create(StdServerSessionPool.java:326)
> >>  
> >>
> >> at 
> >> org.jboss.jms.asf.StdServerSessionPool.(StdServerSessionPool.java:156)
> >>  
> >>
> >> at 
> >> org.jboss.jms.asf.StdServerSessionPoolFactory.getServerSessionPool(StdServerSessionPoolFactory.java:91)
> >>  
> >>
> >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >> at 
> >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> >>  
> >>
> >> at 
> >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> >>  
> >>
> >> at java.lang.reflect.Method.invoke(Method.java:585)
> >> at org.jboss.ejb3.mdb.MDB.createSessionPool(MDB.java:677)
> >> at org.jboss.ejb3.mdb.MDB.innerCreateQueue(MDB.java:522)
> > 
> > 
-- 
 
Adrian Brock
Chief Scientist
JBoss Inc.
 



---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] cglib vs javassit for proxies

2006-02-04 Thread Bill Burke 

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 Ebersole wrote:

Define "replace code for you"...  You mean as in replace the class def
*in the classloader*?

Currently field interception (using either) is only
implemented/available via build task.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bill
Burke
Sent: Friday, February 03, 2006 9:04 PM
To: jboss-development@lists.sourceforge.net
Subject: Re: [JBoss-dev] cglib vs javassit for proxies

You'll find that Javassist gives you a lot more flexibilty as it has a 
built in javacompiler and can replace code for you.  With Javassist it 
should be really easy to intercept field access for the EJB 3.0 
requirements.


Steve Ebersole wrote:


I sent this to a number of other lists, but forgot this one.


Apologies.


I actually just today checked in a pluggable bytecode API into
Hibernate.  Hibernate does now support either CGLIB or Javassist for


all


bytecode services.

As an aside, our experience with CGLIB has been very good.  Juozas


(one


of the CGLIB developers) is very active in the Hibernate community and
is always extremely responsive to any needs we might encounter.  My


$.02


The reason for allowing Javassist to be used instead of CGLIB was


merely


to allow a user choice.  Especially in the case of JBoss where


Javassist


is used in a lot of places, it just makes sense to have the option to
not have to bundle yet another jar.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of


Bill


Burke
Sent: Friday, February 03, 2006 8:39 PM
To: jboss-development@lists.sourceforge.net
Subject: Re: [JBoss-dev] cglib vs javassit for proxies

Javassist is pretty good, problem is that it doesn't have a junit
testsuite.

Jason T. Greene wrote:



I should clarify, for WS, we just need plain javabean generation. So I




can add that to our list of things to do. BTW I was too harsh, there


are 




nice things about cglib. I just ran into a lot of bugs.



-Jason










*From:* [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] *On Behalf Of 
*Jason T. Greene

*Sent:* Friday, February 03, 2006 7:56 PM
*To:* jboss-development@lists.sourceforge.net
*Subject:* RE: [JBoss-dev] cglib vs javassit for proxies



I am all for this, cglib sucks...



-Jason










*From:* [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] *On Behalf Of 
*Scott M Stark

*Sent:* Friday, February 03, 2006 1:47 PM
*To:* jboss-development@lists.sourceforge.net
*Subject:* [JBoss-dev] cglib vs javassit for proxies



So I have to introduce a proxy for a javax.net.SSLServerSocket which


is 



an abstract class and so have to use cglib or javassist. I see some 
proxy working in the head javassist, but this is not in the 4.0 branch




version. We also don't bundle javassist with 4.0 currently. I assume


we 




would rather have javassist be the only bytecode manipulation


framework 




in jboss. Is there a timeframe for completing the javassist proxy so


we 




can think about moving hibernate, webservices, cmp2.x, etc over to it?










--
Bill Burke
Chief Architect
JBoss Inc.


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] BasicThreadPool and Thread.stop()

2006-02-04 Thread Adrian Brock 
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 thread's stack are not garbage collected.
-- 
 
Adrian Brock
Chief Scientist
JBoss Inc.
 



---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] BasicThreadPool and Thread.stop()

2006-02-04 Thread Scott M Stark 
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:[EMAIL PROTECTED] On Behalf Of
Adrian Brock
Sent: Saturday, February 04, 2006 2:33 PM
To: jboss-development@lists.sourceforge.net
Subject: [JBoss-dev] BasicThreadPool and Thread.stop()

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 thread's stack are not garbage collected.
-- 
 
Adrian Brock
Chief Scientist
JBoss Inc.
 




---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development

RE: [JBoss-dev] BasicThreadPool and Thread.stop()

2006-02-04 Thread Adrian Brock 
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.

There is no real solution to that problem in java.
CPU loops don't respond to thread interrupts.

You can't even redefineClass() to add a 
Thread.interrupted()
check in the misbehaving method, because it won't take affect on that
invocation.

Stopping the thread will avoid the cpu utilization problem,
but your JVM is now in an unknown/unstable state.

Connection c = dataSource.getConnection();
try
{
   synchronized (lock)
   {
  spin(); // ---> Stop
   }
}
finally
{
   c.close(); // Never done
}

The connection leaks, I don't know what happens to the lock?

A better solution would be to "automatically" trigger a reboot if you
detect a misbehaving thread.

> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Adrian Brock
> Sent: Saturday, February 04, 2006 2:33 PM
> To: jboss-development@lists.sourceforge.net
> Subject: [JBoss-dev] BasicThreadPool and Thread.stop()
> 
> 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 thread's stack are not garbage collected.
-- 
 
Adrian Brock
Chief Scientist
JBoss Inc.
 



---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] BasicThreadPool and Thread.stop()

2006-02-04 Thread Andrew Oliver 
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 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.



There is no real solution to that problem in java.
CPU loops don't respond to thread interrupts.

You can't even redefineClass() to add a 
Thread.interrupted()

check in the misbehaving method, because it won't take affect on that
invocation.

Stopping the thread will avoid the cpu utilization problem,
but your JVM is now in an unknown/unstable state.

Connection c = dataSource.getConnection();
try
{
   synchronized (lock)
   {
  spin(); // ---> Stop
   }
}
finally
{
   c.close(); // Never done
}

The connection leaks, I don't know what happens to the lock?

A better solution would be to "automatically" trigger a reboot if you
detect a misbehaving thread.



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Adrian Brock
Sent: Saturday, February 04, 2006 2:33 PM
To: jboss-development@lists.sourceforge.net
Subject: [JBoss-dev] BasicThreadPool and Thread.stop()

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 thread's stack are not garbage collected.





---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] BasicThreadPool and Thread.stop()

2006-02-04 Thread Bill Burke 

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 working when there were uncooperative tasks. See the
org.jboss.test.util.test.
ThreadPoolTaskUnitTestCase.testCompleteTimeoutWithSpinLoop as an
example.



There is no real solution to that problem in java.
CPU loops don't respond to thread interrupts.

You can't even redefineClass() to add a 
Thread.interrupted()

check in the misbehaving method, because it won't take affect on that
invocation.

Stopping the thread will avoid the cpu utilization problem,
but your JVM is now in an unknown/unstable state.

Connection c = dataSource.getConnection();
try
{
   synchronized (lock)
   {
  spin(); // ---> Stop
   }
}
finally
{
   c.close(); // Never done
}

The connection leaks, I don't know what happens to the lock?

A better solution would be to "automatically" trigger a reboot if you
detect a misbehaving thread.



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Adrian Brock
Sent: Saturday, February 04, 2006 2:33 PM
To: jboss-development@lists.sourceforge.net
Subject: [JBoss-dev] BasicThreadPool and Thread.stop()

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 thread's stack are not garbage collected.


--
Bill Burke
Chief Architect
JBoss Inc.


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development