[JBoss-dev] jbossweb build.15 Build Successful

2006-03-23 Thread qa

View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jbossweb?log=log20060323220025Lbuild.15
BUILD COMPLETE - build.15Date of build: 03/23/2006 22:00:25Time to build: 24 minutes 3 seconds




    Unit Tests: (0)    Total Errors and Failures: (0) 
 Modifications since last build: (first 50 of 0)



Re: [JBoss-dev] how do Class-Path entries effect deployment?

2006-03-23 Thread Bill Burke
Can you take a look at the forum post?  It looks like the Class-path 
entries are being scanned.  Not sure how that is possible since di.url 
is being used as the scanned thing.


Scott M Stark wrote:

The referenced jars are added to the DeplomentInfo's class loader
classapth. Any other standard class loaders such as URLClassLoaders that
are created for the jar will also pickup these as part of their
classpath.



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

Sent: Thursday, March 23, 2006 2:39 PM
To: Jboss-Dev
Subject: [JBoss-dev] how do Class-Path entries effect deployment?

User running into severe deployment problems.

http://www.jboss.com/index.html?module=bb&op=viewtopic&p=39322
57#3932257


--
Bill Burke
Chief Architect
JBoss Inc.


---
This SF.Net email is sponsored by xPML, a groundbreaking 
scripting language
that extends applications into web and mobile media. Attend 
the live webcast
and join the prime developer group breaking into this new 
coding territory!

http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&;
dat=121642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development





---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development



--
Bill Burke
Chief Architect
JBoss Inc.


---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] RE: jboss-4.0-testsuite Build Completed With Testsuite Errors

2006-03-23 Thread Ryan Campbell








>>I'm not seeing the
jbossretro-rt.jar anywhere in the current 4.0 build, and my workspace is up to
date. Has this been integrated into the dist structure yet?

 

 

http://fisheye.jboss.com/changelog/JBoss/build/jboss?cs=Branch_4_0:rcampbell:20060323050136




 

I see it in the cruisecontrol checkout:

 

/services/cruisecontrol/work/checkout/jboss-4.0-testsuite/build/output/jboss-4.0.4.CR2/server/all/lib

[EMAIL PROTECTED] lib]$ ls jbossretro-rt.jar

jbossretro-rt.jar

 







From: Scott M Stark 
Sent: Thursday, March 23, 2006
7:31 PM
To: Scott M Stark; Ryan Campbell;
'[EMAIL PROTECTED]'; 'jboss-development@lists.sourceforge.net'
Subject: RE: jboss-4.0-testsuite
Build Completed With Testsuite Errors



 

This is failing under 1.4.2 because
javassist is not getting pulled into the jacc config:

 

2006-03-23 15:59:02,535 ERROR
[org.jboss.deployment.MainDeployer] Could not create deployment: file:/services/cruisecontrol/checkout/jboss-4.0-testsuite/testsuite/output/lib/cmp2-audit.jar
java.lang.NoClassDefFoundError: javassist/NotFoundException
   at
org.jboss.ws.server.WebServiceDeployerEJB21.isWebserviceDeployment(WebServiceDeployerEJB21.java:76)
   at
org.jboss.ws.server.WebServiceDeployer.create(WebServiceDeployer.java:101)

 

javassist should be integrated via the
server lib dir rather than the aop deployer due to the jbossretro, hibernate,
etc dependencies not related to aop. I'm not seeing the jbossretro-rt.jar
anywhere in the current 4.0 build, and my workspace is up to date. Has this
been integrated into the dist structure yet?



 







From: Scott M
Stark 
Sent: Thursday, March 23, 2006
4:50 PM
To: Ryan Campbell; '[EMAIL PROTECTED]';
'jboss-development@lists.sourceforge.net'
Subject: RE: jboss-4.0-testsuite
Build Completed With Testsuite Errors

That is an irrelevant debug level log
message indicating that the does not have a setter for injecting the xmbean
object name. It has no affect on the jacc service. I'm looking at the failures.



 







From: Ryan
Campbell 
Sent: Thursday, March 23, 2006
3:03 PM
To: [EMAIL PROTECTED]; 'jboss-development@lists.sourceforge.net'
Subject: RE: jboss-4.0-testsuite
Build Completed With Testsuite Errors

All these JACC tests are failing, and the
jacc-security-mgr logs show this:

 

java.lang.NoSuchMethodException: org.jboss.security.jacc.SecurityService.setObjectName(javax.management.ObjectName)    at java.lang.Class.getMethod(Class.java:986)    at org.jboss.mx.server.AbstractMBeanInvoker.inject(AbstractMBeanInvoker.java:944)    at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:658)    at org.jboss.mx.server.registry.BasicMBeanRegistry.invokePreRegister(BasicMBeanRegistry.java:697)    at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:211)    at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)    at java.lang.reflect.Method.invoke(Method.java:324)    at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)    at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)    at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)    at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)    at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)    at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)    at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:260)    at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)    at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1422)    at java.security.AccessController.doPrivileged(Native Method)    at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1417)    at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1350)    at org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:345)    at org.jboss.system.ServiceCreator.install(ServiceCreator.java:181)

 

 

 









From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 
Sent: Thursday, March 23, 2006
3:12 PM
To: Adrian Brock; Anil Saldhana; Bill Burke; Brian Stansberry; jboss-development@lists.sourceforge.net;
[EMAIL PROTECTED]; QA; Ryan Campbell; Ruel Loehr;
Scott M Stark; Thomas Diesler
Subject: jboss-4.0-testsuite Build
Completed With Testsuite Errors
Importance: High



 

View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-4.0-testsuite?log=log20060323142936




 
  
  TESTS
  FAILED
  
 
 
  
  Ant
  Error Message: /services/cruisecontrol/work/scripts/build-jboss-common.xml:235:
  The following error occurred while executing this line:
  /services/cruisecontrol/work/scripts/build-common-targets.xml:26: Build
  Successful - Tests completed w

[JBoss-dev] RE: jboss-4.0-testsuite Build Completed With Testsuite Errors

2006-03-23 Thread Scott M Stark



This is failing under 1.4.2 because javassist is not 
getting pulled into the jacc config:
 
2006-03-23 
15:59:02,535 ERROR [org.jboss.deployment.MainDeployer] Could not create 
deployment: 
file:/services/cruisecontrol/checkout/jboss-4.0-testsuite/testsuite/output/lib/cmp2-audit.jarjava.lang.NoClassDefFoundError: 
javassist/NotFoundException   at 
org.jboss.ws.server.WebServiceDeployerEJB21.isWebserviceDeployment(WebServiceDeployerEJB21.java:76)   
at 
org.jboss.ws.server.WebServiceDeployer.create(WebServiceDeployer.java:101)
 
javassist should be integrated via the server lib dir 
rather than the aop deployer due to the jbossretro, hibernate, etc dependencies 
not related to aop. I'm not seeing the jbossretro-rt.jar anywhere in the current 
4.0 build, and my workspace is up to date. Has this been integrated into the 
dist structure yet?

  
  
  From: Scott M Stark Sent: Thursday, 
  March 23, 2006 4:50 PMTo: Ryan Campbell; '[EMAIL PROTECTED]'; 
  'jboss-development@lists.sourceforge.net'Subject: RE: 
  jboss-4.0-testsuite Build Completed With Testsuite Errors
  
  That is an irrelevant debug level log message indicating 
  that the does not have a setter for injecting the xmbean object name. It has 
  no affect on the jacc service. I'm looking at the 
  failures.
  


From: Ryan Campbell Sent: 
Thursday, March 23, 2006 3:03 PMTo: [EMAIL PROTECTED]; 
'jboss-development@lists.sourceforge.net'Subject: RE: 
jboss-4.0-testsuite Build Completed With Testsuite 
Errors


All these JACC 
tests are failing, and the jacc-security-mgr logs show 
this:
 java.lang.NoSuchMethodException: org.jboss.security.jacc.SecurityService.setObjectName(javax.management.ObjectName)    at java.lang.Class.getMethod(Class.java:986)    at org.jboss.mx.server.AbstractMBeanInvoker.inject(AbstractMBeanInvoker.java:944)    at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:658)    at org.jboss.mx.server.registry.BasicMBeanRegistry.invokePreRegister(BasicMBeanRegistry.java:697)    at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:211)    at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)    at java.lang.reflect.Method.invoke(Method.java:324)    at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)    at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)    at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)    at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)    at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)    at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)    at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:260)    at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)    at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1422)    at java.security.AccessController.doPrivileged(Native Method)    at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1417)    at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1350)    at org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:345)    at org.jboss.system.ServiceCreator.install(ServiceCreator.java:181)
 
 
 




From: 
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, March 23, 2006 3:12 
PMTo: Adrian Brock; 
Anil Saldhana; Bill Burke; Brian 
Stansberry; jboss-development@lists.sourceforge.net; 
[EMAIL PROTECTED]; QA; Ryan Campbell; Ruel 
Loehr; Scott M Stark; Thomas 
DieslerSubject: jboss-4.0-testsuite Build 
Completed With Testsuite ErrorsImportance: 
High
 
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-4.0-testsuite?log=log20060323142936


  
  

  TESTS 
  FAILED
  

  Ant Error 
  Message: /services/cruisecontrol/work/scripts/build-jboss-common.xml:235: 
  The following error occurred while executing this line: 
  /services/cruisecontrol/work/scripts/build-common-targets.xml:26: 
  Build Successful - Tests completed with errors or 
  failures.
  

  Date of 
  build: 03/23/2006 
  14:29:36
  

  Time to 
  build: 98 minutes 
  20 seconds
  

  Last 
  changed: 03/23/2006 
  14:22:36
  

  Last log 
  entry: fix uneeded 
  dependency
 


  
  

  
  


  
 Unit 
  

[JBoss-dev] RE: jboss-4.0-testsuite Build Completed With Testsuite Errors

2006-03-23 Thread Scott M Stark



That is an irrelevant debug level log message indicating 
that the does not have a setter for injecting the xmbean object name. It has no 
affect on the jacc service. I'm looking at the failures.

  
  
  From: Ryan Campbell Sent: Thursday, 
  March 23, 2006 3:03 PMTo: [EMAIL PROTECTED]; 
  'jboss-development@lists.sourceforge.net'Subject: RE: 
  jboss-4.0-testsuite Build Completed With Testsuite Errors
  
  
  All these JACC tests 
  are failing, and the jacc-security-mgr logs show 
  this:
   java.lang.NoSuchMethodException: org.jboss.security.jacc.SecurityService.setObjectName(javax.management.ObjectName)    at java.lang.Class.getMethod(Class.java:986)    at org.jboss.mx.server.AbstractMBeanInvoker.inject(AbstractMBeanInvoker.java:944)    at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:658)    at org.jboss.mx.server.registry.BasicMBeanRegistry.invokePreRegister(BasicMBeanRegistry.java:697)    at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:211)    at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)    at java.lang.reflect.Method.invoke(Method.java:324)    at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)    at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)    at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)    at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)    at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)    at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)    at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:260)    at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)    at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1422)    at java.security.AccessController.doPrivileged(Native Method)    at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1417)    at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1350)    at org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:345)    at org.jboss.system.ServiceCreator.install(ServiceCreator.java:181)
   
   
   
  
  
  
  
  From: 
  [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, March 23, 2006 3:12 
  PMTo: Adrian Brock; 
  Anil Saldhana; Bill Burke; Brian 
  Stansberry; jboss-development@lists.sourceforge.net; 
  [EMAIL PROTECTED]; QA; Ryan Campbell; Ruel 
  Loehr; Scott M Stark; Thomas 
  DieslerSubject: jboss-4.0-testsuite Build 
  Completed With Testsuite ErrorsImportance: 
  High
   
  View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-4.0-testsuite?log=log20060323142936
  
  


  
TESTS 
FAILED

  
Ant Error 
Message: /services/cruisecontrol/work/scripts/build-jboss-common.xml:235: 
The following error occurred while executing this line: 
/services/cruisecontrol/work/scripts/build-common-targets.xml:26: Build 
Successful - Tests completed with errors or 
failures.

  
Date of 
build: 03/23/2006 
14:29:36

  
Time to 
build: 98 minutes 20 
seconds

  
Last 
changed: 03/23/2006 
14:22:36

  
Last log 
entry: fix uneeded 
dependency
   
  
  


  


  
  

   Unit 
  Tests: (2879)  Total Errors and Failures: (234) 
  
  

   
  

   

   

   
  

   

   

   

   
  

   

   

   
 


  
  

   

   


RE: [JBoss-dev] how do Class-Path entries effect deployment?

2006-03-23 Thread Scott M Stark
The referenced jars are added to the DeplomentInfo's class loader
classapth. Any other standard class loaders such as URLClassLoaders that
are created for the jar will also pickup these as part of their
classpath.

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On 
> Behalf Of Bill Burke
> Sent: Thursday, March 23, 2006 2:39 PM
> To: Jboss-Dev
> Subject: [JBoss-dev] how do Class-Path entries effect deployment?
> 
> User running into severe deployment problems.
> 
> http://www.jboss.com/index.html?module=bb&op=viewtopic&p=39322
> 57#3932257
> 
> 
> --
> Bill Burke
> Chief Architect
> JBoss Inc.
> 
> 
> ---
> This SF.Net email is sponsored by xPML, a groundbreaking 
> scripting language
> that extends applications into web and mobile media. Attend 
> the live webcast
> and join the prime developer group breaking into this new 
> coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&;
> dat=121642
> ___
> JBoss-Development mailing list
> JBoss-Development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jboss-development
> 


---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] Re: jboss-4.0-testsuite Build Completed With Testsuite Errors

2006-03-23 Thread Bill Burke

Hmmm, probably related to the EJB3 jacc failures?

Ryan Campbell wrote:

All these JACC tests are failing, and the jacc-security-mgr logs show this:

 


java.lang.NoSuchMethodException: 
org.jboss.security.jacc.SecurityService.setObjectName(javax.management.ObjectName)

at java.lang.Class.getMethod(Class.java:986)

at 
org.jboss.mx.server.AbstractMBeanInvoker.inject(AbstractMBeanInvoker.java:944)

at 
org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:658)

at 
org.jboss.mx.server.registry.BasicMBeanRegistry.invokePreRegister(BasicMBeanRegistry.java:697)

at 
org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:211)

at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)

at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:324)

at 
org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)

at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)

at 
org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)

at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)

at 
org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)

at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)

at 
org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:260)

at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)

at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1422)

at java.security.AccessController.doPrivileged(Native Method)

at 
org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1417)

at 
org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1350)

at 
org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:345)

at org.jboss.system.ServiceCreator.install(ServiceCreator.java:181)

 

 

 




*From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
*Sent:* Thursday, March 23, 2006 3:12 PM
*To:* Adrian Brock; Anil Saldhana; Bill Burke; Brian Stansberry; 
jboss-development@lists.sourceforge.net; [EMAIL PROTECTED]; QA; Ryan 
Campbell; Ruel Loehr; Scott M Stark; Thomas Diesler

*Subject:* jboss-4.0-testsuite Build Completed With Testsuite Errors
*Importance:* High

 

View results here -> 
http://cruisecontrol.jboss.com/cc/buildresults/jboss-4.0-testsuite?log=log20060323142936


*TESTS FAILED*

*Ant Error 
Message: */services/cruisecontrol/work/scripts/build-jboss-common.xml:235: 
The following error occurred while executing this line: 
/services/cruisecontrol/work/scripts/build-common-targets.xml:26: Build 
Successful - Tests completed with errors or failures.


*Date of build: *03/23/2006 14:29:36

*Time to build: *98 minutes 20 seconds

*Last changed: *03/23/2006 14:22:36

*Last log entry: *fix uneeded dependency

 


 Unit Tests: (2879)  Total Errors and Failures: (234)

testServerFound



org.jboss.test.cluster.test.UndeployTestCase(Default-UDP)

testRelations



org.jboss.test.cmp2.cmrstress.CMRStressTestCase(JACC+SecurityMgr)

testRelations



org.jboss.test.cmp2.cmrstress.CMRStressTestCase(JACC)

testCMRTransaction



org.jboss.test.cmp2.cmrtransaction.test.CMRTransactionUnitTestCase(JACC+SecurityMgr)

testCMRTransaction



org.jboss.test.cmp2.cmrtransaction.test.CMRTransactionUnitTestCase(JACC)

testLazyResultSetLoading



org.jboss.test.cmp2.commerce.CompleteUnitTestCase(JACC+SecurityMgr)

testCascadeDelete



org.jboss.test.cmp2.commerce.CompleteUnitTestCase(JACC+SecurityMgr)

testCategory_Type



org.jboss.test.cmp2.commerce.CompleteUnitTestCase(JACC+SecurityMgr)

testCategory_Type_BatchCascadeDelete



org.jboss.test.cmp2.commerce.CompleteUnitTestCase(JACC+SecurityMgr)

testTxTester_none



org.jboss.test.cmp2.commerce.CompleteUnitTestCase(JACC+SecurityMgr)

testJBossQL



org.jboss.test.cmp2.commerce.CompleteUnitTestCase(JACC+SecurityMgr)

testEJBQL



org.jboss.test.cmp2.commerce.CompleteUnitTestCase(JACC+SecurityMgr)

testCompiler



org.jboss.test.cmp2.commerce.CompleteUnitTestCase(JACC+SecurityMgr)

testLimitOffset



org.jboss.test.cmp2.commerce.CompleteUnitTestCase(JACC+SecurityMgr)

testFinderWithLimitOffset



org.jboss.test.cmp2.commerce.CompleteUnitTestCase(JACC+SecurityMgr)

test_setInPostCreate



org.jboss.test.cmp2.commerce.CompleteUnitTestCase(JACC+SecurityMgr)

test_dvo



org.jboss.test.cmp2.commerce.CompleteUnitTestCase(JACC+SecurityMgr)

test_getOrdersShippedToCA



org.jboss.test.cmp2.commerce.CompleteUnitTestCase(JACC+SecurityMgr)

test_ge

[JBoss-dev] how do Class-Path entries effect deployment?

2006-03-23 Thread Bill Burke

User running into severe deployment problems.

http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3932257#3932257


--
Bill Burke
Chief Architect
JBoss Inc.


---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] RE: JBAS-2972 - OOME / Redeployment leakages

2006-03-23 Thread Adrian Brock
On Thu, 2006-03-23 at 09:52 -0600, Clebert Suconic wrote:
> 1) It is slow
>  - It's the best I can do now, since there is no way on the API to get
> such thing. I can verify later if there is a way to associate two tags
> with a class on JVMTI, that would help me doing a faster navigation.
> 

I'm not familiar with JVMTI and the doco is not very good,
at least for "newbies" trying to understands the semantics of the
call. I need to expermient. ;-)


> 2) The formatting is not good
>   - Any ideas on how to improve it? I have just made a quick fix,
> improved a little bit, but not much

I'd like to see something like
reference <- referer1.field
  <- referer2.field <- referer3.field

And although using object.toString() is useful,
it can be obscure when it doesn't include [EMAIL PROTECTED]
like some of the jsr77 classes
and it is totally uninformative for arrays.

Similarly, some collections like linked lists or HashMaps don't show up
well with the algorithm you are using.

> 
> 3) Showing the field name
>   - I don't have a way on the event chain to determine what's the field
> keeping a reference. It would be nice though. 
> 

http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#jvmtiObjectReferenceCallback
http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#JVMTI_REFERENCE_FIELD

-- 

Adrian Brock
Chief Scientist
JBoss Inc.




---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] RE: JBAS-2972 - OOME / Redeployment leakages

2006-03-23 Thread Clebert Suconic
- My first implementation was an InMemory model. It was fast and
beautiful, but I couldn't process large snapshots.

- My second implementation was then HSQLDB. 

But when I was navigating, if I needed for instance to lookup on
references for Strings, I had to look for reference holders on more than
a thousand objects. The query was fast, but since I needed to execute it
several times, took me a lot of time to process.

Then I tried to use dynamic queries (if ID=1 or id=2 or id=3.
it=100) and couldn't find a way to process

- My third implementation (current) now is to use what I called
FileCollections with a dummy quick sort. Since I was using just
quickSort/binarySearch that was way faster than using HSQLDB.



-Original Message-
From: Adrian Brock 
Sent: Thursday, March 23, 2006 9:44 AM
To: Clebert Suconic
Cc: Scott M Stark; QA; jboss-development@lists.sourceforge.net
Subject: RE: JBAS-2972 - OOME / Redeployment leakages

On Thu, 2006-03-23 at 09:23 -0600, Clebert Suconic wrote:
> > I can imagine a visitor pattern that understands what is
> permenantly deployed and what is hotdeployed and determines
> the root cause.
> 
> I have that already. I can create a heapSnapshot, and analyze it
later.
> But at this point the method I have to sort the will takes a lot of
time
> to process now. I need a faster way to index file (without using a
> database).
> 

Can't you just use hsqldb in memory? That is what it was designed
for ;-)

-- 

Adrian Brock
Chief Scientist
JBoss Inc.




---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] RE: JBAS-2972 - OOME / Redeployment leakages

2006-03-23 Thread Clebert Suconic
1) It is slow
 - It's the best I can do now, since there is no way on the API to get
such thing. I can verify later if there is a way to associate two tags
with a class on JVMTI, that would help me doing a faster navigation.

2) The formatting is not good
  - Any ideas on how to improve it? I have just made a quick fix,
improved a little bit, but not much

3) Showing the field name
  - I don't have a way on the event chain to determine what's the field
keeping a reference. It would be nice though. 


-Original Message-
From: Adrian Brock 
Sent: Thursday, March 23, 2006 9:46 AM
To: Clebert Suconic
Cc: Scott M Stark; QA; jboss-development@lists.sourceforge.net
Subject: RE: JBAS-2972 - OOME / Redeployment leakages

On Thu, 2006-03-23 at 09:23 -0600, Clebert Suconic wrote:
> The new features uses getRerenceHolders Method, which does an inverted
> walkthrough everyObject looking for references on the object passed by
> parameter, what can be done on a life JVM (I can discover holders
> without create a snapshot)
> 
> The method takes probably one second to run every time you call it,
> since it walks through the whole heap. I have to do that, since there
> isn't a way to fire reference events by its referenced objects. I have
> to calculate the equivalent backward operation. For a 10 levels
analysis
> on a classLoader will probably take 1 minute or two.
> 


I've been look at that this morning.
1) It is slow
2) The formatting is not good
3) Showing the field name

There must be a better way to implement it, since that is what
the api was designed for.

> 
> BTW: If someone is using JVMTIInterface, I will create a xmdesc to the
> MBean today/tomorrow. Right now you will have to look at parameter
names
> on source code (JVMTIInterfaceMBean)
> 
> 
> 
> 
> 
> -Original Message-
> From: Adrian Brock 
> Sent: Thursday, March 23, 2006 4:27 AM
> To: Clebert Suconic
> Cc: Scott M Stark; QA
> Subject: RE: JBAS-2972 - OOME / Redeployment leakages
> 
> On Thu, 2006-03-23 at 01:37 -0600, Clebert Suconic wrote:
> > I created another method on JVMTIInterface, called
> > exploreClassRefernces. With that method you can use JMXConsole to
> > explore class and classLoader references to a class (given by name).
> > 
> > - First let me explain how the data is organized:
> > 
> > 
> > ReferencesToClassLoader.html shows every reference to
> > [EMAIL PROTECTED] url=null
> > ,addedOrder=50}, on this case the ClassLoader responsible for
> deploying
> > testbyvalue.ear.
> > 
> > 
> > I have limited this analysis up to 10 levels. 
> 
> A better approach would be dump all objects and their
> references out to a file. Then write something
> that runs a full gc() over that information.
> 
> Once that is done, you need something that lets you "walk the tree".
> 
> I can imagine a visitor pattern that understands what is
> permenantly deployed and what is hotdeployed and determines
> the root cause.
> 
> Otherwise, a simple GUI would do the trick.
-- 

Adrian Brock
Chief Scientist
JBoss Inc.




---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] RE: JBAS-2972 - OOME / Redeployment leakages

2006-03-23 Thread Adrian Brock
On Thu, 2006-03-23 at 09:23 -0600, Clebert Suconic wrote:
> The new features uses getRerenceHolders Method, which does an inverted
> walkthrough everyObject looking for references on the object passed by
> parameter, what can be done on a life JVM (I can discover holders
> without create a snapshot)
> 
> The method takes probably one second to run every time you call it,
> since it walks through the whole heap. I have to do that, since there
> isn't a way to fire reference events by its referenced objects. I have
> to calculate the equivalent backward operation. For a 10 levels analysis
> on a classLoader will probably take 1 minute or two.
> 


I've been look at that this morning.
1) It is slow
2) The formatting is not good
3) Showing the field name

There must be a better way to implement it, since that is what
the api was designed for.

> 
> BTW: If someone is using JVMTIInterface, I will create a xmdesc to the
> MBean today/tomorrow. Right now you will have to look at parameter names
> on source code (JVMTIInterfaceMBean)
> 
> 
> 
> 
> 
> -Original Message-
> From: Adrian Brock 
> Sent: Thursday, March 23, 2006 4:27 AM
> To: Clebert Suconic
> Cc: Scott M Stark; QA
> Subject: RE: JBAS-2972 - OOME / Redeployment leakages
> 
> On Thu, 2006-03-23 at 01:37 -0600, Clebert Suconic wrote:
> > I created another method on JVMTIInterface, called
> > exploreClassRefernces. With that method you can use JMXConsole to
> > explore class and classLoader references to a class (given by name).
> > 
> > - First let me explain how the data is organized:
> > 
> > 
> > ReferencesToClassLoader.html shows every reference to
> > [EMAIL PROTECTED] url=null
> > ,addedOrder=50}, on this case the ClassLoader responsible for
> deploying
> > testbyvalue.ear.
> > 
> > 
> > I have limited this analysis up to 10 levels. 
> 
> A better approach would be dump all objects and their
> references out to a file. Then write something
> that runs a full gc() over that information.
> 
> Once that is done, you need something that lets you "walk the tree".
> 
> I can imagine a visitor pattern that understands what is
> permenantly deployed and what is hotdeployed and determines
> the root cause.
> 
> Otherwise, a simple GUI would do the trick.
-- 

Adrian Brock
Chief Scientist
JBoss Inc.




---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] RE: JBAS-2972 - OOME / Redeployment leakages

2006-03-23 Thread Adrian Brock
On Thu, 2006-03-23 at 09:23 -0600, Clebert Suconic wrote:
> > I can imagine a visitor pattern that understands what is
> permenantly deployed and what is hotdeployed and determines
> the root cause.
> 
> I have that already. I can create a heapSnapshot, and analyze it later.
> But at this point the method I have to sort the will takes a lot of time
> to process now. I need a faster way to index file (without using a
> database).
> 

Can't you just use hsqldb in memory? That is what it was designed
for ;-)

-- 

Adrian Brock
Chief Scientist
JBoss Inc.




---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] RE: FW: JBAS-2972 - OOME / Redeployment leakages

2006-03-23 Thread Adrian Brock
On Thu, 2006-03-23 at 09:05 -0600, Clebert Suconic wrote:
> > I don't even know what ThreadPool changes you are referring to, are
> they real or proposed?
> 
> I thought we had some changes on the ThreadPools. My bad.
> I meant that because of references through ThreadWithAttributes (they
> will be always appear for some reason on JVMTI).
> 
> 
> Anyway, I need to know if a Thread is cleared
> (Thread.setContextClassLoader(somethingElse) before the Thread goes to
> sleep.
> If the Thread keeps the ClassLoader reference until next request, that
> will make my life harder creating a TestCase structure for testing
> redeployment/classLeakages.

All code should be switching and restoring the classloader
during the invocations.  Anything else is a bug.

ClassLoader old = tcl;
tcl = myClassLoader
try
{
}
finally
{
tcl = old;
}

Of course if something (e.g. an MBean)
that is hotdeployed starts a thread
and doesn't stop it at undeployment then it will leak
the classloader. But that is also a bug.
-- 

Adrian Brock
Chief Scientist
JBoss Inc.




---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] RE: JBAS-2972 - OOME / Redeployment leakages

2006-03-23 Thread Clebert Suconic
> I can imagine a visitor pattern that understands what is
permenantly deployed and what is hotdeployed and determines
the root cause.

I have that already. I can create a heapSnapshot, and analyze it later.
But at this point the method I have to sort the will takes a lot of time
to process now. I need a faster way to index file (without using a
database).


The new features uses getRerenceHolders Method, which does an inverted
walkthrough everyObject looking for references on the object passed by
parameter, what can be done on a life JVM (I can discover holders
without create a snapshot)

The method takes probably one second to run every time you call it,
since it walks through the whole heap. I have to do that, since there
isn't a way to fire reference events by its referenced objects. I have
to calculate the equivalent backward operation. For a 10 levels analysis
on a classLoader will probably take 1 minute or two.


BTW: If someone is using JVMTIInterface, I will create a xmdesc to the
MBean today/tomorrow. Right now you will have to look at parameter names
on source code (JVMTIInterfaceMBean)





-Original Message-
From: Adrian Brock 
Sent: Thursday, March 23, 2006 4:27 AM
To: Clebert Suconic
Cc: Scott M Stark; QA
Subject: RE: JBAS-2972 - OOME / Redeployment leakages

On Thu, 2006-03-23 at 01:37 -0600, Clebert Suconic wrote:
> I created another method on JVMTIInterface, called
> exploreClassRefernces. With that method you can use JMXConsole to
> explore class and classLoader references to a class (given by name).
> 
> - First let me explain how the data is organized:
> 
> 
> ReferencesToClassLoader.html shows every reference to
> [EMAIL PROTECTED] url=null
> ,addedOrder=50}, on this case the ClassLoader responsible for
deploying
> testbyvalue.ear.
> 
> 
> I have limited this analysis up to 10 levels. 

A better approach would be dump all objects and their
references out to a file. Then write something
that runs a full gc() over that information.

Once that is done, you need something that lets you "walk the tree".

I can imagine a visitor pattern that understands what is
permenantly deployed and what is hotdeployed and determines
the root cause.

Otherwise, a simple GUI would do the trick.
-- 

Adrian Brock
Chief Scientist
JBoss Inc.




---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] RE: FW: JBAS-2972 - OOME / Redeployment leakages

2006-03-23 Thread Clebert Suconic
> I don't even know what ThreadPool changes you are referring to, are
they real or proposed?

I thought we had some changes on the ThreadPools. My bad.
I meant that because of references through ThreadWithAttributes (they
will be always appear for some reason on JVMTI).


Anyway, I need to know if a Thread is cleared
(Thread.setContextClassLoader(somethingElse) before the Thread goes to
sleep.
If the Thread keeps the ClassLoader reference until next request, that
will make my life harder creating a TestCase structure for testing
redeployment/classLeakages.

http://jira.jboss.org/jira/browse/JBAS-2909



-Original Message-
From: Adrian Brock 
Sent: Thursday, March 23, 2006 3:41 AM
To: Clebert Suconic
Cc: Scott M Stark; jboss-development@lists.sourceforge.net
Subject: Re: FW: JBAS-2972 - OOME / Redeployment leakages

On Wed, 2006-03-22 at 21:03 -0600, Clebert Suconic wrote:
> Sorry... pressed Ctrl-enter instead of Enter. (Damn Outlook)
> 
> Do you think that our changes on ThreadPool would eventually leak
> redeployments on the testsuite? (for instance, by keeping
> Thread.currentThread().contextClassLoader() still alive) ?

Clebert, can you please include  some hard facts.
I am not going to comment on speculation.

If you want me to "get the facts" - 
(and I don't mean MSFacts ;-) then tell me.

I don't even know what ThreadPool changes you are referring to,
are they real or proposed?
-- 

Adrian Brock
Chief Scientist
JBoss Inc.




---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


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

2006-03-23 Thread qa

View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-3.2-testsuite?log=log20060323081050
TESTS FAILEDAnt Error Message: /services/cruisecontrol/work/scripts/build-jboss-common.xml:235: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-common-targets.xml:26: Build Successful - Tests completed with errors or failures.Date of build: 03/23/2006 08:10:50Time to build: 48 minutes 29 seconds




    Unit Tests: (1851)    Total Errors and Failures: (1)testUnackedQueueorg.jboss.test.jbossmq.test.UnackedUnitTestCase 
 Modifications since last build: (first 50 of 0)



[JBoss-dev] Re: FW: JBAS-2972 - OOME / Redeployment leakages

2006-03-23 Thread Adrian Brock
On Wed, 2006-03-22 at 21:03 -0600, Clebert Suconic wrote:
> Sorry... pressed Ctrl-enter instead of Enter. (Damn Outlook)
> 
> Do you think that our changes on ThreadPool would eventually leak
> redeployments on the testsuite? (for instance, by keeping
> Thread.currentThread().contextClassLoader() still alive) ?

Clebert, can you please include  some hard facts.
I am not going to comment on speculation.

If you want me to "get the facts" - 
(and I don't mean MSFacts ;-) then tell me.

I don't even know what ThreadPool changes you are referring to,
are they real or proposed?
-- 

Adrian Brock
Chief Scientist
JBoss Inc.




---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development