[JBoss-dev] Test Job Failed to Complete Successfully (or we gave up on it...)! JBoss (HEAD/linux1/1.4.1_05) [AUTOMATED]
=== ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS== === === Tue Jan 20 07:10:23 GMT 2004 === HERE ARE THE LAST 100 LINES OF THE LOG: === ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS== === === [junit] TEST org.jboss.test.security.test.SRPUnitTestCase FAILED (timeout) [junit] Running org.jboss.test.security.test.SecurityProxyUnitTestCase [junit] TEST org.jboss.test.security.test.SecurityProxyUnitTestCase FAILED (timeout) [junit] Running org.jboss.test.security.test.XMLLoginModulesUnitTestCase [junit] Tests run: 13, Failures: 0, Errors: 0, Time elapsed: 53.967 sec tests-standard-stress: [junit] Running org.jboss.test.bank.test.BankEJB20StressTestCase [junit] TEST org.jboss.test.bank.test.BankEJB20StressTestCase FAILED (timeout) [junit] Running org.jboss.test.bank.test.BankStressTestCase [junit] TEST org.jboss.test.bank.test.BankStressTestCase FAILED (timeout) [junit] Running org.jboss.test.cache.stress.LocalStressTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 81.068 sec [junit] Running org.jboss.test.cache.stress.ReadWriteLockWithUpgradeStressTestCase [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 1.886 sec [junit] Running org.jboss.test.cmp2.cmrstress.CMRStressTestCase [junit] TEST org.jboss.test.cmp2.cmrstress.CMRStressTestCase FAILED (timeout) [junit] Running org.jboss.test.cts.test.StatelessSessionStressTestCase [junit] TEST org.jboss.test.cts.test.StatelessSessionStressTestCase FAILED (timeout) [junit] Running org.jboss.test.deadlock.test.BeanStressTestCase [junit] TEST org.jboss.test.deadlock.test.BeanStressTestCase FAILED (timeout) [junit] Running org.jboss.test.hello.test.HelloClusteredHttpStressTestCase [junit] TEST org.jboss.test.hello.test.HelloClusteredHttpStressTestCase FAILED (timeout) [junit] Running org.jboss.test.hello.test.HelloHttpStressTestCase [junit] TEST org.jboss.test.hello.test.HelloHttpStressTestCase FAILED (timeout) [junit] Running org.jboss.test.hello.test.HelloTimingStressTestCase [junit] TEST org.jboss.test.hello.test.HelloTimingStressTestCase FAILED (timeout) [junit] Running org.jboss.test.jbossmq.perf.JBossMQPerfStressTestCase [junit] TEST org.jboss.test.jbossmq.perf.JBossMQPerfStressTestCase FAILED (timeout) [junit] Running org.jboss.test.jbossmq.perf.OIL2InvocationLayerStressTestCase [junit] TEST org.jboss.test.jbossmq.perf.OIL2InvocationLayerStressTestCase FAILED (timeout) [junit] Running org.jboss.test.jbossmq.perf.OILInvocationLayerStressTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 12.14 sec [junit] Running org.jboss.test.jbossmq.perf.RMIInvocationLayerStressTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 11.428 sec [junit] Running org.jboss.test.jbossmq.perf.SendReplyPerfStressTestCase [junit] TEST org.jboss.test.jbossmq.perf.SendReplyPerfStressTestCase FAILED (timeout) [junit] Running org.jboss.test.jbossmq.perf.UIL2InvocationLayerStressTestCase [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 18.319 sec [junit] Running org.jboss.test.jca.test.BaseConnectionManagerStressTestCase [junit] Tests run: 7, Failures: 1, Errors: 0, Time elapsed: 16.619 sec [junit] TEST org.jboss.test.jca.test.BaseConnectionManagerStressTestCase FAILED [junit] Running org.jboss.test.jca.test.CachedConnectionBankStressTestCase [junit] TEST org.jboss.test.jca.test.CachedConnectionBankStressTestCase FAILED (timeout) [junit] Running org.jboss.test.lock.test.EnterpriseEntityStressTestCase [junit] TEST org.jboss.test.lock.test.EnterpriseEntityStressTestCase FAILED (timeout) [junit] Running org.jboss.test.naming.test.NamingStressTestCase [junit] TEST org.jboss.test.naming.test.NamingStressTestCase FAILED (timeout) [junit] Running org.jboss.test.perf.test.PerfStressTestCase [junit] TEST org.jboss.test.perf.test.PerfStressTestCase FAILED (timeout) [junit] Running org.jboss.test.pooled.test.BeanStressTestCase [junit] TEST org.jboss.test.pooled.test.BeanStressTestCase FAILED (timeout) tests-client-stress: tests-security-basic-stress: [junit] Running org.jboss.test.jmx.test.SecureJMXInvokerUnitTestCase [junit] TEST org.jboss.test.jmx.test.SecureJMXInvokerUnitTestCase FAILED (timeout) [junit] Running org.jboss.test.perf.test.SecurePerfStressTestCase
[JBoss-dev] JBoss Shutdown Failed! JBoss (HEAD/linux1/1.4.1_05) [AUTOMATED]
=== ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS== === === Tue Jan 20 07:10:46 GMT 2004 === HERE ARE THE LAST 100 LINES OF THE LOG: === ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS== === === JBOSS SHUTDOWN FAILED === Tue Jan 20 07:10:46 GMT 2004 === Linux nog.kimptoc.net 2.4.20-28.7 #1 Thu Dec 18 11:31:59 EST 2003 i686 unknown === java -version java version 1.4.1_05 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_05-b01) Java HotSpot(TM) Client VM (build 1.4.1_05-b01, mixed mode) --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBoss Test Results: % ( / ) - . JBoss (HEAD/linux1/1.4.1_05) [AUTOMATED]
=== ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS== === === Tue Jan 20 07:21:34 GMT 2004 === HERE ARE THE LAST 100 LINES OF THE LOG: === ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS== === === === Tue Jan 20 07:21:34 GMT 2004 === Linux nog.kimptoc.net 2.4.20-28.7 #1 Thu Dec 18 11:31:59 EST 2003 i686 unknown === java -version java version 1.4.1_05 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_05-b01) Java HotSpot(TM) Client VM (build 1.4.1_05-b01, mixed mode) --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-880191 ] 3.2.3prod, jboss.xml depends breaks undeployment
Bugs item #880191, was opened at 2004-01-19 22:48 Message generated for change (Comment added) made by cazzius You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=880191group_id=22866 Category: JBossMX Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Ivan Parra (ioparra) Assigned to: Claudio Vesco (cazzius) Summary: 3.2.3prod, jboss.xml depends breaks undeployment Initial Comment: I had this problem when migrating to JBoss3.2.3 (prod). I then recreated from CVS tag JBoss_3_2_3. Here is how to set up the scenario: 1) compile JBoss_3_2_3 2) compile testsuite 3) modify the unpacked/eardeployment.ear/sessionb.jar/META- INF/jboss.xml Note: that sessiona.jar deploys Session B a) add dependsjboss.j2ee:jndiName=eardeployment/Sessi onB,service=EJB/depends to the SessionA. 4) deploy the application You can either 5) undeploy the application and look at the JMX-Console a)after undeployment, the mbean for sessionA will still exist OR 5) redeploy and get an InstanceAlreadyExistsException from the JMX layer. This did work in JBoss3.2.1. I also noticed from the MainDeployer.listDeployed()(via JMXConsole) that not all jars are in the STARTED state. Some are in START_DEPLOYER state. Check this first before testing. I saw random things in this state(jms-ds.xml, hsqldb-ds.xml, jbossmq- service.xml, etc.) Is that intentional? When I added mbean dependencies for the session, I noticed the status changes from STARTED to START_DEPLOYER. That may be the reason. If I find anything else out, I'll post. Good Luck! -Ivan -- Comment By: Claudio Vesco (cazzius) Date: 2004-01-20 08:23 Message: Logged In: YES user_id=211618 Can you try this test with current 3.2 Branch? I think that the current 3.2 branch does not have this problem. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=880191group_id=22866 --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-849786 ] ejb - sar depends
Bugs item #849786, was opened at 2003-11-26 18:10
Message generated for change (Comment added) made by cazzius
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=849786group_id=22866
Category: JBossServer
Group: v3.2
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Claudio Vesco (cazzius)
Assigned to: Claudio Vesco (cazzius)
Summary: ejb - sar depends
Initial Comment:
When there are complex dependencies between ejbs and
sar, the Container services are not properly destroyed.
Tested on jboss 3.2 branch but I think this problem is in
jboss head branch.
Description:
ear/
__eardependsaejb.jar -- 2 ejb which depends on sar
eardependsmbean.sar
__eardependsbejb.jar -- 1 ejb independent
__eardependsmbean.sar -- a service which depends on
eardependsbejb.jar
when the ear is undeployed can happen:
1. destruction of independent ejb module
1.1. destruction of independent ejb container (by
EjbModule)
1.2. destruction of service (by ServiceController,
dependency)
1.3. destruction of dependent ejb containers (by
ServiceController, dependency)
2. destruction of dependent ejb module
the containers are already destroyed
the containers stay registered recording dependencies
3. destruction of service
the service is already destroyed
The problem cannot be easily tracked because if the
destroy order is [dependent ejb module, independent ejb
module, service] the EjbModule can destroy the
containers.
I think there is another little problem: the order of
deployment/undeployment of ear modules is not the
same between different redeploys. This because
DeploymentInfo.subDeployments is a HashSet.
I have the testcase in my cvs repository ready for the
commit but for better tracking this bug (and I think
others) I need the deploy order to be fixed with a little
patch in DeploymentSorter, for example:
public int compare(Object o1, Object o2)
{
URL url1 = (URL) o1;
URL url2 = (URL) o2;
int result = getExtensionIndex(url1) -
getExtensionIndex(url2);
if (result == 0)
{
result = url1.getPath().compareTo(url2.getPath());
}
return result;
}
--
Comment By: Claudio Vesco (cazzius)
Date: 2004-01-20 08:42
Message:
Logged In: YES
user_id=211618
Fixed.
--
Comment By: Claudio Vesco (cazzius)
Date: 2003-11-28 13:59
Message:
Logged In: YES
user_id=211618
it is also in jboss head
--
Comment By: Claudio Vesco (cazzius)
Date: 2003-11-26 18:48
Message:
Logged In: YES
user_id=211618
see test
org.jboss.test.jmx.test.EarDeploymentUnitTestCase.testEarDep
ends
The test can not fail. It fail always if the DeploymentSorter is
patched.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=849786group_id=22866
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-880447 ] Tomcat doesn't call contextDestroyed() on JBoss shutdown
Bugs item #880447, was opened at 2004-01-20 09:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=880447group_id=22866 Category: JBossServer Group: v4.0 Status: Open Resolution: None Priority: 5 Submitted By: Sean Clarke (seanclarke04) Assigned to: Nobody/Anonymous (nobody) Summary: Tomcat doesn't call contextDestroyed() on JBoss shutdown Initial Comment: Hi, For some reason when I shut JBoss down (either ^C or shutdown script) Tomcat doesn't get a chance to call contextDestroyed on my application. I have tried Tomcat (standalone) 4.1.24 and 5.x and it works fine. contextInitialised is called on startup, but contextDestroyed remains uncalled. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=880447group_id=22866 --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CMP / CMR problems.
Hi people. I'm new to the list, and new to CMP/CMR ejbs (I used Jboss 2.4 until now, mostly with BMPs). I try to to have a 1:N relationship between two beans, (SupportPackCMP and PeripheralCMP), using Xdoclet tags. I'd like tables to be created by the app. server When I deploy under JBoss 3.2.3, I have the following exception : org.jboss.deployment.DeploymentException: Role 'supportpackToPeripheral' on Entity Bean 'SupportPackCMP' : CMP field for key not found: field name='SP_ID' I searched the web for a piece of answer, but didn't find anything. The two beans are attached. Thanks for your help Frédéric SupportPackCMPBean.java Description: Binary data PeripheralCMPBean.java Description: Binary data
Re: [JBoss-dev] CMP / CMR problems.
Hi, JBoss-User list is the right place to ask user questions. This list is reserved for development discussions. -- juha On Tue, 20 Jan 2004 [EMAIL PROTECTED] wrote: Hi people. I'm new to the list, and new to CMP/CMR ejbs (I used Jboss 2.4 until now, mostly with BMPs). I try to to have a 1:N relationship between two beans, (SupportPackCMP and --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Web integration (clustering) updates
Scott M Stark wrote: This has been fixed by only unregistering the deployment UCL if the deployment actually created the UCL as opposed to inherit the UCL from its containing deployment. The current NPE behavior is an artifact of class loading that is ocurring now, not any specific behavior changes. Cool :) Should I remove the nested deployment for the root webapp in the TC 5 SAR, and move the .war to deploy ? -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jmx unit tests
the jmx module unit tests are the ones we run against, the ones in testsuite were never maintained. At least 3 of the 4 failures on compliance are known issues (and reported as such), I don't know about the JMX 1.2 notification emitter one. The two errors are both related to classloading, at least at some point the loader repository impl. in 3.2 worked correctly with these, whatever the diffs in classloading were were not ported back to head. The error in head implementation tests is new, and looks like is related to classloading again. The failure is a known issue and reported as such. I haven't run the serialization tests, Adrian will know about those. I haven't run these against 3.2 for a long while, the number of failures seems high. Serialization-1.0 full failure seems to indicate it's not running against JMX 1.0 -- Juha On Tue, 20 Jan 2004, Scott M Stark wrote: What is the status of the unit tests in the jmx module as opposed to the unit tests in testsuite/.../jbossmx? There are more tests in the jmx module, but there are a fair number of errors. The 3.2 branch tests for serialization are totally broken. Are the jmx modules tests being maintained, and what is in the testsuite module vs the jmx module? The serialization tests in the 3.2 branch are totally broken. HEAD: [EMAIL PROTECTED] jmx]$ ant test-compliance-full-JBossMX ... [java] Tests run: 926, Failures: 4, Errors: 2 [EMAIL PROTECTED] jmx]$ ant test-implementation ... [java] Tests run: 67, Failures: 1, Errors: 1 [EMAIL PROTECTED] jmx]$ ant test-serialization-1.0 [java] Serialization Tests: jmx.serial.form=1.0 ... [java] Tests run: 93, Failures: 3, Errors: 16 Branch_3_2: [EMAIL PROTECTED] jmx]$ ant test-compliance-full-JBossMX ... [java] Tests run: 926, Failures: 10, Errors: 2 [EMAIL PROTECTED] jmx]$ ant test-implementation ... [java] Tests run: 67, Failures: 1, Errors: 1 [EMAIL PROTECTED] jmx]$ ant test-serialization-1.0 ... [java] Tests run: 93, Failures: 0, Errors: 73 Scott Stark Chief Technology Officer JBoss Group, LLC --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-880191 ] 3.2.3prod, jboss.xml depends breaks undeployment
Bugs item #880191, was opened at 2004-01-19 14:48 Message generated for change (Comment added) made by ioparra You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=880191group_id=22866 Category: JBossMX Group: v3.2 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Ivan Parra (ioparra) Assigned to: Claudio Vesco (cazzius) Summary: 3.2.3prod, jboss.xml depends breaks undeployment Initial Comment: I had this problem when migrating to JBoss3.2.3 (prod). I then recreated from CVS tag JBoss_3_2_3. Here is how to set up the scenario: 1) compile JBoss_3_2_3 2) compile testsuite 3) modify the unpacked/eardeployment.ear/sessionb.jar/META- INF/jboss.xml Note: that sessiona.jar deploys Session B a) add dependsjboss.j2ee:jndiName=eardeployment/Sessi onB,service=EJB/depends to the SessionA. 4) deploy the application You can either 5) undeploy the application and look at the JMX-Console a)after undeployment, the mbean for sessionA will still exist OR 5) redeploy and get an InstanceAlreadyExistsException from the JMX layer. This did work in JBoss3.2.1. I also noticed from the MainDeployer.listDeployed()(via JMXConsole) that not all jars are in the STARTED state. Some are in START_DEPLOYER state. Check this first before testing. I saw random things in this state(jms-ds.xml, hsqldb-ds.xml, jbossmq- service.xml, etc.) Is that intentional? When I added mbean dependencies for the session, I noticed the status changes from STARTED to START_DEPLOYER. That may be the reason. If I find anything else out, I'll post. Good Luck! -Ivan -- Comment By: Ivan Parra (ioparra) Date: 2004-01-20 12:02 Message: Logged In: YES user_id=812998 Tested with Branch3_2 head. Had a few problems compiling the testsuite, but figured it shouldn't matter. It's not like I'm actually RUNNING the code, I'm just deploying it. Sure enough, this issue doesn't exist on the Branch. Good to close. I still noticed that STARTED - START_DEPLOYER after adding dependency. Is this on purpose? -- Comment By: Claudio Vesco (cazzius) Date: 2004-01-20 00:23 Message: Logged In: YES user_id=211618 Can you try this test with current 3.2 Branch? I think that the current 3.2 branch does not have this problem. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=880191group_id=22866 --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-877172 ] NullPointerException in LoadMgr3
Bugs item #877172, was opened at 2004-01-14 16:59 Message generated for change (Comment added) made by javajedi You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=877172group_id=22866 Category: JBossMX Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Tim McCune (javajedi) Assigned to: Scott M Stark (starksm) Summary: NullPointerException in LoadMgr3 Initial Comment: I get this error out of JBoss 3.2.2 on a fairly regular basis. I'm still not sure exactly how to reproduce it, but since it's an NPE, I'm hoping that someone can track down what would cause it to happen fairly easily. Once it occurs for a particular class, the only fix is to restart JBoss. I never had this problem on 3.2.0. java.lang.NullPointerException at org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:119) at org.jboss.mx.loading.UnifiedClassLoader3.loadClassImpl(UnifiedClassLoader3.java:169) at org.jboss.mx.loading.UnifiedClassLoader3.loadClass(UnifiedClassLoader3.java:123) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302) Looking at the code, the UnifiedLoaderRepository3 that is passed into beginLoadTask as the 2nd parameter must be null. UnifiedClassLoader3, line 118 does a null check for repository just a few lines before calling loadClassImpl, so I'm assuming that this is a valid state for the class loader to be in. That would mean that beginLoadTask in LoadMgr3 needs to handle the situation where repository is null. -- Comment By: Tim McCune (javajedi) Date: 2004-01-20 15:22 Message: Logged In: YES user_id=62441 Ok, stack trace attached. -- Comment By: Scott M Stark (starksm) Date: 2004-01-15 07:54 Message: Logged In: YES user_id=175228 Add the full stack trace as an attachment so I can see where the load attempt is originating from. An NPE in LoadMgr indicates that the UnifiedClassLoader3 has been removed from the repository in between the loadClass class and the delegation to LoadMgr. The only cause of this would be destruction of the associated deployment due to a redeploy. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=877172group_id=22866 --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Too many copies of model mbean info objects
I'm looking into the testcase failure related to ModelMBean persistence
and the problem as stated earlier is that the attribute
interceptor/context
ModelAttributeInfo and descriptor are copies that are detached from the
ModelMBean. Hence, changes to the attribute do not result in changes in
the ModelAttributeInfo descriptor fields like value, and
lastupdatedtimestamp.
This info is required by the current persistence impl, and also should
be availble through the MBeanInfo available from the MBeanServer. A
simple
testcase illustrates the different behavior between the 1.2.1 JMX RI and
the JBossMX 1.2 impl:
The current JBossMX impl:
X Descriptor Fields:
currencytimelimit: 1
descriptortype: attribute
name: X
The JMX 1.2RI:
X Descriptor Fields:
value: 10
currencytimelimit: 1
descriptortype: attribute
lastupdatedtimestamp: 1074629742102
displayname: X
name: X
Testcase method:
public void testLastModified() throws Exception
{
System.out.println(+++ testLastModified);
MBeanServer server =
MBeanServerFactory.createMBeanServer(ModelMBeanTest);
System.out.println(server: +server);
DescriptorSupport cacheInfo = new DescriptorSupport();
cacheInfo.setField(name, X);
cacheInfo.setField(descriptorType, attribute);
cacheInfo.setField(currencyTimeLimit, new Integer(1));
ModelMBeanAttributeInfo[] attrInfo = {new
ModelMBeanAttributeInfo(X, java.lang.Integer,
The X attribute, true, true, false, cacheInfo)
};
ModelMBeanConstructorInfo[] ctorInfo = null;
ModelMBeanOperationInfo[] opInfo = null;
ModelMBeanInfoSupport mbi = new
ModelMBeanInfoSupport(test.Resource, Resource POJO,
attrInfo, ctorInfo, opInfo, null);
RequiredModelMBean rmm = new RequiredModelMBean(mbi);
rmm.setManagedResource(new Resource(), ObjectReference);
ObjectName name = new ObjectName(:test=testLastModified);
server.registerMBean(rmm, name);
Attribute x = new Attribute(X, new Integer(10));
server.setAttribute(name, x);
ModelMBeanInfo info = (ModelMBeanInfo) server.getMBeanInfo(name);
System.out.println(ModelMBeanInfo: +info);
// Display the attribute info descriptors after the set
ModelMBeanAttributeInfo xinfo = info.getAttribute(X);
System.out.println(X info: +xinfo);
Descriptor xd = xinfo.getDescriptor();
String[] fields = xd.getFieldNames();
System.out.println(X Descriptor Fields:);
for(int f = 0; f fields.length; f ++)
{
String fname = fields[f];
System.out.println( +fname+: +xd.getFieldValue(fname));
}
MBeanServerFactory.releaseMBeanServer(server);
}
The source of this behavior is the use of a copy of the
ModelMBeanAttributeInfo
and its descriptors to the ModelMBeanInvoker.initAttributeContexts. The
only
way I can see to restore the expected behavior is to use JBoss specific
subclasses of the javax.management.modelmbean.*Info classes that allow
for
accessing their state by reference rather than by copy.
This has to be done for the 3.2 branch usage, I don't know if this is
what
we want in head.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Too many copies of model mbean info objects
If I follow what you're trying to do correctly, the reason for the bug is
that the context map descriptors are updated but the info reference we
return from getMBeanInfo is not,
in AbstractMBeanInvoker, for setters there's a finally block at the end
that updates the context maps on the return of the invocation:
// TODO: should be fixed by adding invocation return value object
finally
{
ctx.setDescriptor(invocation.getDescriptor());
TCLStack.pop();
}
getMBeanInfo() returns the metadata through invoker.getMetaData() call
which returns the 'info' reference from AbstractMBeanInvoker
/**
* The metadata describing this MBean.
*/
protected MBeanInfo info= null;
Which has not been updated with the change.
So, is this what needs to be done:
finally
{
ctx.setDescriptor(invocation.getDescriptor());
info.setDescriptor(invocation.getDescriptor(), attribute);
TCLStack.pop();
}
Or did I lose track of what you're trying to do?
-- Juha
On Tue, 20 Jan 2004, Scott M Stark wrote:
I'm looking into the testcase failure related to ModelMBean persistence
and the problem as stated earlier is that the attribute
interceptor/context
ModelAttributeInfo and descriptor are copies that are detached from the
ModelMBean. Hence, changes to the attribute do not result in changes in
the ModelAttributeInfo descriptor fields like value, and
lastupdatedtimestamp.
This info is required by the current persistence impl, and also should
be availble through the MBeanInfo available from the MBeanServer. A
simple
testcase illustrates the different behavior between the 1.2.1 JMX RI and
the JBossMX 1.2 impl:
The current JBossMX impl:
X Descriptor Fields:
currencytimelimit: 1
descriptortype: attribute
name: X
The JMX 1.2RI:
X Descriptor Fields:
value: 10
currencytimelimit: 1
descriptortype: attribute
lastupdatedtimestamp: 1074629742102
displayname: X
name: X
Testcase method:
public void testLastModified() throws Exception
{
System.out.println(+++ testLastModified);
MBeanServer server =
MBeanServerFactory.createMBeanServer(ModelMBeanTest);
System.out.println(server: +server);
DescriptorSupport cacheInfo = new DescriptorSupport();
cacheInfo.setField(name, X);
cacheInfo.setField(descriptorType, attribute);
cacheInfo.setField(currencyTimeLimit, new Integer(1));
ModelMBeanAttributeInfo[] attrInfo = {new
ModelMBeanAttributeInfo(X, java.lang.Integer,
The X attribute, true, true, false, cacheInfo)
};
ModelMBeanConstructorInfo[] ctorInfo = null;
ModelMBeanOperationInfo[] opInfo = null;
ModelMBeanInfoSupport mbi = new
ModelMBeanInfoSupport(test.Resource, Resource POJO,
attrInfo, ctorInfo, opInfo, null);
RequiredModelMBean rmm = new RequiredModelMBean(mbi);
rmm.setManagedResource(new Resource(), ObjectReference);
ObjectName name = new ObjectName(:test=testLastModified);
server.registerMBean(rmm, name);
Attribute x = new Attribute(X, new Integer(10));
server.setAttribute(name, x);
ModelMBeanInfo info = (ModelMBeanInfo) server.getMBeanInfo(name);
System.out.println(ModelMBeanInfo: +info);
// Display the attribute info descriptors after the set
ModelMBeanAttributeInfo xinfo = info.getAttribute(X);
System.out.println(X info: +xinfo);
Descriptor xd = xinfo.getDescriptor();
String[] fields = xd.getFieldNames();
System.out.println(X Descriptor Fields:);
for(int f = 0; f fields.length; f ++)
{
String fname = fields[f];
System.out.println( +fname+: +xd.getFieldValue(fname));
}
MBeanServerFactory.releaseMBeanServer(server);
}
The source of this behavior is the use of a copy of the
ModelMBeanAttributeInfo
and its descriptors to the ModelMBeanInvoker.initAttributeContexts. The
only
way I can see to restore the expected behavior is to use JBoss specific
subclasses of the javax.management.modelmbean.*Info classes that allow
for
accessing their state by reference rather than by copy.
This has to be done for the 3.2 branch usage, I don't know if this is
what
we want in head.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
The SF.Net email is
RE: [JBoss-dev] Automated JBoss(Branch_3_2 WonderLand) Testsuite Results: 18-January-2004
Out of these failures, the following need to be resolved before the 3.2.4RC1 release: Suite: org.jboss.test.cts.test.StatefulSessionUnitTestCase Test:testStrictPooling Suite: org.jboss.test.jmx.test.DeployXMBeanUnitTestCase Test:testUserXMBeanPersistentValues Suite: org.jboss.test.security.test.EJBSpecUnitTestCase Test:testMDBRunAs Suite: org.jboss.test.deadlock.test.BeanStressTestCase Test:testDeadLock Suite: org.jboss.test.deadlock.test.BeanStressTestCase Test:testAllCompleteOrFail Suite: org.jboss.test.deadlock.test.BeanStressTestCase Test:testAllCompleteOrFailNotSupportedReentrant Suite: org.jboss.test.deadlock.test.BeanStressTestCase Test:testAllCompleteOrFailCMR Suite: org.jboss.test.jca.test.CachedConnectionBankStressTestCase Test:testCachedConnectionBank Suite: org.jboss.test.lock.test.EnterpriseEntityStressTestCase Test:unknown The remainder are known issues. I'm working on the DeployXMBeanUnitTestCase and EJBSpecUnitTestCase failures. I need to know who is looking into the others. Scott Stark Chief Technology Officer JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, January 18, 2004 12:50 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] Automated JBoss(Branch_3_2 WonderLand) Testsuite Results: 18-January-2004 Automated JBoss(Branch_3_2 WonderLand) Testsuite Results: 18-January-2004 JBoss daily test results SUMMARY Number of tests run: 1639 Successful tests: 1620 Errors:9 Failures: 10 [time of test: 2004-01-18.20-08 GMT] [java.version: 1.4.2_03] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.4.2_03-b02] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.20-9smp] Useful resources: - http://jboss.sourceforge.net//junit-results/32/2004-01-18.20-08 for the junit report of this test. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Too many copies of model mbean info objects
Is this enough as there are several places copies are being introduced:
- AbstractMBeanInvoker.preRegister
+ This calls initAttributeContexts(info.getAttributes());, which
makes a copy of
the MBeanAttributeInfo[]
- ModelMBeanInvoker.initAttributeContexts
+ This calls ctx.setDescriptor(info.getDescriptor()); which passes in
a copy of
Descriptor from the copy of the MBeanAttributeInfo obtained from the
MBeanInfo.
Therefore, all attribute sets are operating on copies of the
MBeanAttributeInfo. Is
adding info.setDescriptor(...) to the
AbstractMBeanInvoker.setAttribute(Attribute)
finally going to be enough? It looks like this might, I'll test it out.
There seem to be an excessive number of copies being made tough, and the
same
descriptor synchronization is also required on operations. Is there a
way to
reduce the number of copies being created?
Scott Stark
Chief Technology Officer
JBoss Group, LLC
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Juha
Lindfors
Sent: Tuesday, January 20, 2004 1:25 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Too many copies of model mbean info objects
If I follow what you're trying to do correctly, the reason for the bug
is that the context map descriptors are updated but the info reference
we return from getMBeanInfo is not,
in AbstractMBeanInvoker, for setters there's a finally block at the end
that updates the context maps on the return of the invocation:
// TODO: should be fixed by adding invocation return value object
finally
{
ctx.setDescriptor(invocation.getDescriptor());
TCLStack.pop();
}
getMBeanInfo() returns the metadata through invoker.getMetaData() call
which returns the 'info' reference from AbstractMBeanInvoker
/**
* The metadata describing this MBean.
*/
protected MBeanInfo info= null;
Which has not been updated with the change.
So, is this what needs to be done:
finally
{
ctx.setDescriptor(invocation.getDescriptor());
info.setDescriptor(invocation.getDescriptor(), attribute);
TCLStack.pop();
}
Or did I lose track of what you're trying to do?
-- Juha
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Automated JBoss(Branch_3_2 WonderLand) Testsuite Results: 18-January-2004
I am looking into deadlock. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott M Stark Sent: Tuesday, January 20, 2004 11:34 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Automated JBoss(Branch_3_2 WonderLand) Testsuite Results: 18-January-2004 Out of these failures, the following need to be resolved before the 3.2.4RC1 release: Suite: org.jboss.test.cts.test.StatefulSessionUnitTestCase Test:testStrictPooling Suite: org.jboss.test.jmx.test.DeployXMBeanUnitTestCase Test:testUserXMBeanPersistentValues Suite: org.jboss.test.security.test.EJBSpecUnitTestCase Test:testMDBRunAs Suite: org.jboss.test.deadlock.test.BeanStressTestCase Test:testDeadLock Suite: org.jboss.test.deadlock.test.BeanStressTestCase Test:testAllCompleteOrFail Suite: org.jboss.test.deadlock.test.BeanStressTestCase Test:testAllCompleteOrFailNotSupportedReentrant Suite: org.jboss.test.deadlock.test.BeanStressTestCase Test:testAllCompleteOrFailCMR Suite: org.jboss.test.jca.test.CachedConnectionBankStressTestCase Test:testCachedConnectionBank Suite: org.jboss.test.lock.test.EnterpriseEntityStressTestCase Test:unknown The remainder are known issues. I'm working on the DeployXMBeanUnitTestCase and EJBSpecUnitTestCase failures. I need to know who is looking into the others. Scott Stark Chief Technology Officer JBoss Group, LLC --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Too many copies of model mbean info objects
Since the spec requires a copy to be returned I think the only way to
avoid it is to create a JBoss specific impl. as you suggested in the
previous post.
-- Juha
On Tue, 20 Jan 2004, Scott M Stark wrote:
Is this enough as there are several places copies are being introduced:
- AbstractMBeanInvoker.preRegister
+ This calls initAttributeContexts(info.getAttributes());, which
makes a copy of
the MBeanAttributeInfo[]
- ModelMBeanInvoker.initAttributeContexts
+ This calls ctx.setDescriptor(info.getDescriptor()); which passes in
a copy of
Descriptor from the copy of the MBeanAttributeInfo obtained from the
MBeanInfo.
Therefore, all attribute sets are operating on copies of the
MBeanAttributeInfo. Is
adding info.setDescriptor(...) to the
AbstractMBeanInvoker.setAttribute(Attribute)
finally going to be enough? It looks like this might, I'll test it out.
There seem to be an excessive number of copies being made tough, and the
same
descriptor synchronization is also required on operations. Is there a
way to
reduce the number of copies being created?
Scott Stark
Chief Technology Officer
JBoss Group, LLC
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Juha
Lindfors
Sent: Tuesday, January 20, 2004 1:25 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Too many copies of model mbean info objects
If I follow what you're trying to do correctly, the reason for the bug
is that the context map descriptors are updated but the info reference
we return from getMBeanInfo is not,
in AbstractMBeanInvoker, for setters there's a finally block at the end
that updates the context maps on the return of the invocation:
// TODO: should be fixed by adding invocation return value object
finally
{
ctx.setDescriptor(invocation.getDescriptor());
TCLStack.pop();
}
getMBeanInfo() returns the metadata through invoker.getMetaData() call
which returns the 'info' reference from AbstractMBeanInvoker
/**
* The metadata describing this MBean.
*/
protected MBeanInfo info= null;
Which has not been updated with the change.
So, is this what needs to be done:
finally
{
ctx.setDescriptor(invocation.getDescriptor());
info.setDescriptor(invocation.getDescriptor(), attribute);
TCLStack.pop();
}
Or did I lose track of what you're trying to do?
-- Juha
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] jmx unit tests
What are the other 3 known compliance issues? 3.2 and head should be in synch on class loaders and I need to merge some of the changes made to the jmx layer so I want to get these test working before doing the merge. Scott Stark Chief Technology Officer JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Juha Lindfors Sent: Tuesday, January 20, 2004 10:49 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] jmx unit tests the jmx module unit tests are the ones we run against, the ones in testsuite were never maintained. At least 3 of the 4 failures on compliance are known issues (and reported as such), I don't know about the JMX 1.2 notification emitter one. The two errors are both related to classloading, at least at some point the loader repository impl. in 3.2 worked correctly with these, whatever the diffs in classloading were were not ported back to head. The error in head implementation tests is new, and looks like is related to classloading again. The failure is a known issue and reported as such. I haven't run the serialization tests, Adrian will know about those. I haven't run these against 3.2 for a long while, the number of failures seems high. Serialization-1.0 full failure seems to indicate it's not running against JMX 1.0 -- Juha --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Another ModelMBean comp issue?
In doing some testing of the RequiredModelMBean in the jmx 1.2.1RI and our codebase, I see that we require a resource while the RI does not. We allow the resource to simply be a new Object(), but its not clear whether this is too strict. Scott Stark Chief Technology Officer JBoss Group, LLC --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] jmx unit tests
JBOSS-HEAD: /cygdrive/d/jboss-head/jmx $ sh build.sh test-compliance-JBossMX Searching for build.xml ... Buildfile: d:\jboss-head\jmx\build.xml ... [java] 1) testNotificationEmitterRemoveTripletFailsOnBroadcaster (test.compliance.server.MBeanServerInvocationHandlerTestCase) junit.framework.AssertionFailedError: removeNotificationListener (NotificationListener, NotificationFilter, Object)should not work for a broadcaster * This is JMX1.2 API, so Adrian will know the details [java] 2) testGetDescriptor(test.compliance.modelmbean.ModelMBeanInfoSupportTEST) junit.framework.AssertionFailedError: FAILS IN JBOSSMX: We incorrectly return descriptor type 'constructor' here -- should be 'operation' * Incorrect metadata value for a model mbean constructor, I vaguely remember 1.2 spec has a different semantic specified here compared to 1.0 [java] 4) testPathological(test.compliance.query.QueryTestCase) junit.framework.AssertionFailedError: FAILS IN JBossMX: expected Hello(?:.) to match Hello(?:.) * IIRC, spec ambiguity, Adrian might remember more on this. I don't think any of the above needs fixing to port changes to jmx layer. The two errors on classloading and one error on classloading in implementation suite however might be worth looking at. -- Juha On Tue, 20 Jan 2004, Scott M Stark wrote: What are the other 3 known compliance issues? 3.2 and head should be in synch on class loaders and I need to merge some of the changes made to the jmx layer so I want to get these test working before doing the merge. Scott Stark Chief Technology Officer JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Juha Lindfors Sent: Tuesday, January 20, 2004 10:49 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] jmx unit tests the jmx module unit tests are the ones we run against, the ones in testsuite were never maintained. At least 3 of the 4 failures on compliance are known issues (and reported as such), I don't know about the JMX 1.2 notification emitter one. The two errors are both related to classloading, at least at some point the loader repository impl. in 3.2 worked correctly with these, whatever the diffs in classloading were were not ported back to head. The error in head implementation tests is new, and looks like is related to classloading again. The failure is a known issue and reported as such. I haven't run the serialization tests, Adrian will know about those. I haven't run these against 3.2 for a long while, the number of failures seems high. Serialization-1.0 full failure seems to indicate it's not running against JMX 1.0 -- Juha --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-877172 ] NullPointerException in LoadMgr3
Bugs item #877172, was opened at 2004-01-14 13:59 Message generated for change (Comment added) made by starksm You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=877172group_id=22866 Category: JBossMX Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Tim McCune (javajedi) Assigned to: Scott M Stark (starksm) Summary: NullPointerException in LoadMgr3 Initial Comment: I get this error out of JBoss 3.2.2 on a fairly regular basis. I'm still not sure exactly how to reproduce it, but since it's an NPE, I'm hoping that someone can track down what would cause it to happen fairly easily. Once it occurs for a particular class, the only fix is to restart JBoss. I never had this problem on 3.2.0. java.lang.NullPointerException at org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:119) at org.jboss.mx.loading.UnifiedClassLoader3.loadClassImpl(UnifiedClassLoader3.java:169) at org.jboss.mx.loading.UnifiedClassLoader3.loadClass(UnifiedClassLoader3.java:123) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302) Looking at the code, the UnifiedLoaderRepository3 that is passed into beginLoadTask as the 2nd parameter must be null. UnifiedClassLoader3, line 118 does a null check for repository just a few lines before calling loadClassImpl, so I'm assuming that this is a valid state for the class loader to be in. That would mean that beginLoadTask in LoadMgr3 needs to handle the situation where repository is null. -- Comment By: Scott M Stark (starksm) Date: 2004-01-20 14:45 Message: Logged In: YES user_id=175228 So where is the com.mysql.jdbc.Connection class coming from in the deployment, and has there been a redeployment of anything in the encompassing deployment? The current 3.2 codebase has additional debug level logging to track when a class loader is removed from the repository as well as a fix for delaying the removal of a class loader from its repository until the top level deployment have been destroyed. -- Comment By: Tim McCune (javajedi) Date: 2004-01-20 12:22 Message: Logged In: YES user_id=62441 Ok, stack trace attached. -- Comment By: Scott M Stark (starksm) Date: 2004-01-15 04:54 Message: Logged In: YES user_id=175228 Add the full stack trace as an attachment so I can see where the load attempt is originating from. An NPE in LoadMgr indicates that the UnifiedClassLoader3 has been removed from the repository in between the loadClass class and the delegation to LoadMgr. The only cause of this would be destruction of the associated deployment due to a redeploy. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=877172group_id=22866 --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Too many copies of model mbean info objects
This does seem to be sufficient and the persistent attribute testcase in the failing DeployXMBeanUnitTestCase is now working. Scott Stark Chief Technology Officer JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott M Stark Sent: Tuesday, January 20, 2004 1:56 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Too many copies of model mbean info objects Is this enough as there are several places copies are being introduced: - AbstractMBeanInvoker.preRegister + This calls initAttributeContexts(info.getAttributes());, which makes a copy of the MBeanAttributeInfo[] - ModelMBeanInvoker.initAttributeContexts + This calls ctx.setDescriptor(info.getDescriptor()); which passes in a copy of Descriptor from the copy of the MBeanAttributeInfo obtained from the MBeanInfo. Therefore, all attribute sets are operating on copies of the MBeanAttributeInfo. Is adding info.setDescriptor(...) to the AbstractMBeanInvoker.setAttribute(Attribute) finally going to be enough? It looks like this might, I'll test it out. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] jmx unit tests
There's a difference in running the JMX compliance suite between 3.2.3-RC2 checkout and the current 3.2.4-RC1 checkout (with JMX 1.2 head backport) 3.2.3-RC2 = [EMAIL PROTECTED] /cygdrive/d/jboss-323-RC2/jboss-3.2/jmx $ sh build.sh test-compliance-JBossMX Searching for build.xml ... Buildfile: d:\jboss-323-RC2\jboss-3.2\jmx\build.xml ... [java] There were 3 failures: [java] 1) testInstantiateWithDefaultLoaderRepository(test.compliance.server.MBeanServerTEST)junit.framework.Asserti onFailedError: FAILS IN JBOSSMX: ULR3 loads from TCL, should be DLR [java] at test.compliance.server.MBeanServerTEST.testInstantiateWithDefaultLoaderRepository(MBeanServerTEST.jav a:1014) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [java] at test.compliance.ComplianceSUITE.main(ComplianceSUITE.java:37) [java] 2) testGetDescriptor(test.compliance.modelmbean.ModelMBeanInfoSupportTEST)junit.framework.AssertionFailedErr or: FAILS IN JBOSSMX: We incorrectly return descriptor type 'constructor' here -- should be 'operation' [java] at test.compliance.modelmbean.ModelMBeanInfoSupportTEST.testGetDescriptor(ModelMBeanInfoSupportTEST.java :177) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [java] at test.compliance.ComplianceSUITE.main(ComplianceSUITE.java:37) [java] 3) testPathological(test.compliance.query.QueryTestCase)junit.framework.AssertionFailedError: FAILS IN JBoss MX: expected Hello(?:.) to match Hello(?:.) [java] at test.compliance.query.QueryTestCase.testPathological(QueryTestCase.java:1056) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [java] at test.compliance.ComplianceSUITE.main(ComplianceSUITE.java:37) [java] FAILURES!!! [java] Tests run: 628, Failures: 3, Errors: 0 BUILD SUCCESSFUL Total time: 15 seconds 3.2.4-RC1 = /cygdrive/d/jboss-324-RC1/jmx $ ./build.bat test-compliance-JBossMX Calling ..\tools\bin\ant.bat -logger org.apache.tools.ant.NoBannerLogger test-compliance-JBossMX Buildfile: build.xml ... [java] There were 2 errors: [java] 1) testInstantiateWithDefaultLoaderRepository(test.compliance.server.MBeanServerTEST)ReflectionException: Cl ass not found: test.compliance.server.support.AClass [java] Cause: java.lang.ClassNotFoundException: test.compliance.server.support.AClass [java] at org.jboss.mx.server.MBeanServerImpl.handleInstantiateExceptions(MBeanServerImpl.java:872) [java] at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:853) [java] at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:264) [java] at test.compliance.server.MBeanServerTEST.testInstantiateWithDefaultLoaderRepository(MBeanServerTEST.jav a:833) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [java] at test.compliance.ComplianceSUITE.main(ComplianceSUITE.java:48) [java] Caused by: java.lang.ClassNotFoundException: test.compliance.server.support.AClass [java] at java.net.URLClassLoader$1.run(URLClassLoader.java:199) [java] at java.security.AccessController.doPrivileged(Native Method) [java] at java.net.URLClassLoader.findClass(URLClassLoader.java:187) [java] at java.lang.ClassLoader.loadClass(ClassLoader.java:289) [java] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274) [java] at java.lang.ClassLoader.loadClass(ClassLoader.java:235) [java] at org.jboss.mx.loading.UnifiedLoaderRepository3.loadClass(UnifiedLoaderRepository3.java:574) [java] at javax.management.loading.DefaultLoaderRepository.loadClass(DefaultLoaderRepository.java:74) [java] at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:830) [java] ... 22 more [java] 2) testMLetLoadClassFromURLInConstructor(test.compliance.loading.MLetTEST)java.lang.ClassNotFoundException: test.compliance.loading.support.Trivial [java] at java.net.URLClassLoader$1.run(URLClassLoader.java:199) [java] at
RE: [JBoss-dev] Too many copies of model mbean info objects
Great, I can still read Java code then ;-) -- Juha On Tue, 20 Jan 2004, Scott M Stark wrote: This does seem to be sufficient and the persistent attribute testcase in the failing DeployXMBeanUnitTestCase is now working. Scott Stark Chief Technology Officer JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott M Stark Sent: Tuesday, January 20, 2004 1:56 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Too many copies of model mbean info objects Is this enough as there are several places copies are being introduced: - AbstractMBeanInvoker.preRegister + This calls initAttributeContexts(info.getAttributes());, which makes a copy of the MBeanAttributeInfo[] - ModelMBeanInvoker.initAttributeContexts + This calls ctx.setDescriptor(info.getDescriptor()); which passes in a copy of Descriptor from the copy of the MBeanAttributeInfo obtained from the MBeanInfo. Therefore, all attribute sets are operating on copies of the MBeanAttributeInfo. Is adding info.setDescriptor(...) to the AbstractMBeanInvoker.setAttribute(Attribute) finally going to be enough? It looks like this might, I'll test it out. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-860175 ] NotSerializableException when using twiddle for a XMBean
Bugs item #860175, was opened at 2003-12-14 22:35 Message generated for change (Comment added) made by starksm You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=860175group_id=22866 Category: JBossMX Group: v3.2 Status: Open Resolution: Remind Priority: 5 Submitted By: Srivatsan (srivatsanp) Assigned to: Scott M Stark (starksm) Summary: NotSerializableException when using twiddle for a XMBean Initial Comment: When a XMBean has an attribute of type Element, invoking that MBean through twiddle results in NotSerializableException. Please find attached the zip containing the source, descriptors and the sar used for testing. sh twiddle.sh invoke jboss.test:service=TestXMBean create twiddle.sh: RuntimeMBeanException: null Cause: org.jboss.util.NestedRuntimeException: error unmarshalling return; nested exception is: java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: org.apache.crimson.tree.ElementNode; - nested throwable: (java.rmi.UnmarshalException: error unmarshalling return; nested exception is: java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: org.apache.crimson.tree.ElementNode) I am using JBoss 3.2.1 -- Comment By: Scott M Stark (starksm) Date: 2004-01-20 15:01 Message: Logged In: YES user_id=175228 twiddle obtains the MBeanInfo for the target to determine what the operation signature is. The MBeanInfo contains the attribute info and their descriptors including the current value, and the Element based attribute descriptor fails to serialize. The jmx-invoker-adaptor-server needs to filter out the attribute info for types that are not serializable. -- Comment By: Srivatsan (srivatsanp) Date: 2004-01-18 21:13 Message: Logged In: YES user_id=687037 I have already attached the zip containing the sar and sources when submitting the bug. The twiddle command is: sh twiddle.sh invoke jboss.test:service=TestXMBean create Thanks, Srivatsan -- Comment By: Scott M Stark (starksm) Date: 2004-01-15 05:05 Message: Logged In: YES user_id=175228 Submit the mbean as an attachment along with the twiddle command that produces the error. -- Comment By: Srivatsan (srivatsanp) Date: 2004-01-05 20:52 Message: Logged In: YES user_id=687037 I am not accessing the non serializable attribute from twiddle. I am just invoking some other operation on the MBean. It fails even in that case. Thanks, Srivatsan -- Comment By: Scott M Stark (starksm) Date: 2004-01-05 09:10 Message: Logged In: YES user_id=175228 Accessing JMX over a remote channel as twiddle requires, will only work with types that are serializable. Until the JMX1.2 with remoting you are restricted to accessing serializable attributes. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=860175group_id=22866 --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-881012 ] Cannot change partition name
Bugs item #881012, was opened at 2004-01-20 20:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=881012group_id=22866 Category: Clustering Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Vinh Nguyen (macronetics) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot change partition name Initial Comment: When I tried to change DefaultPartition to MyPartition under the all configuation, I got the following error: 19:59:38,848 ERROR [HAILSharedState] Starting failed java.lang.NullPointerException at org.jboss.ha.jmx.HAServiceMBeanSupport.registerRPCHan dler(HAServiceMB eanSupport.java:173) at org.jboss.ha.jmx.HAServiceMBeanSupport.startService (HAServiceMBeanSup port.java:142) at org.jboss.system.ServiceMBeanSupport.start (ServiceMBeanSupport.java:1 92) at sun.reflect.GeneratedMethodAccessor31.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.system.ServiceController$ServiceProxy.invoke (ServiceControl ler.java:976) at $Proxy14.start(Unknown Source) at org.jboss.system.ServiceController.start (ServiceController.java:394) at org.jboss.system.ServiceController.start (ServiceController.java:411) at sun.reflect.GeneratedMethodAccessor6.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.mx.util.MBeanProxyExt.invoke (MBeanProxyExt.java:177) at $Proxy4.start(Unknown Source) at org.jboss.deployment.SARDeployer.start (SARDeployer.java:226) at org.jboss.deployment.MainDeployer.start (MainDeployer.java:832) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:642) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:605) at sun.reflect.GeneratedMethodAccessor26.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.mx.util.MBeanProxyExt.invoke (MBeanProxyExt.java:177) at $Proxy6.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.de ploy(URLDeploymen tScanner.java:302) at org.jboss.deployment.scanner.URLDeploymentScanner.sc an(URLDeploymentS canner.java:476) at org.jboss.deployment.scanner.AbstractDeploymentScann er$ScannerThread. doScan(AbstractDeploymentScanner.java:201) at org.jboss.deployment.scanner.AbstractDeploymentScann er.startService(A bstractDeploymentScanner.java:274) at org.jboss.system.ServiceMBeanSupport.start (ServiceMBeanSupport.java:1 92) at sun.reflect.GeneratedMethodAccessor5.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.system.ServiceController$ServiceProxy.invoke (ServiceControl ler.java:976) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start (ServiceController.java:394) at sun.reflect.GeneratedMethodAccessor6.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.mx.util.MBeanProxyExt.invoke (MBeanProxyExt.java:177) at $Proxy4.start(Unknown Source) at org.jboss.deployment.SARDeployer.start (SARDeployer.java:226) at org.jboss.deployment.MainDeployer.start (MainDeployer.java:832) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:642) at
[JBoss-dev] JBoss Test Results: 94 % ( 1490 / 1570 ) - come on - pull your finger out. JBoss (HEAD/winxp/1.4.1_06) [AUTOMATED]
=== ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS== === === Wed Jan 21 01:19:18 GMTST 2004 === HERE ARE THE LAST 100 LINES OF THE LOG: === ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS== === === JBoss daily test results SUMMARY Number of tests run: 1570 Successful tests: 1490 Errors:61 Failures: 19 [time of test: 2004-01-21.00-32 GMT] [java.version: 1.4.1_06] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.4.1_06-b01] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Windows XP] [os.arch: x86] [os.version: 5.1] Useful resources: - http://jboss.kimptoc.net/winxp/1.4.1_06/logtests/testresults/reports/html//2004-01-21.00-32 for the junit report of this test. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS Suite: org.jboss.test.aop.test.RemotingUnitTestCase Test:testRemoting Type:error Exception: java.rmi.UnmarshalException Message: error unmarshalling return; nested exception is: java.lang.ClassNotFoundException: org.jboss.aop.proxy$org.jboss.test.aop.bean.POJO - Suite: org.jboss.test.aop.test.RemotingUnitTestCase Test:testNonadvisedRemoting Type:error Exception: java.rmi.UnmarshalException Message: error unmarshalling return; nested exception is: java.lang.ClassNotFoundException: org.jboss.aop.proxy$org.jboss.test.aop.bean.NonadvisedPOJO - Suite: org.jboss.test.aop.test.RemotingUnitTestCase Test:testClusteredRemoting Type:error Exception: java.rmi.UnmarshalException Message: error unmarshalling return; nested exception is: java.lang.ClassNotFoundException: org.jboss.aop.proxy$org.jboss.test.aop.bean.POJO - Suite: org.jboss.test.aop.test.RemotingUnitTestCase Test:testClusteredNonadvisedRemoting Type:error Exception: java.rmi.UnmarshalException Message: error unmarshalling return; nested exception is: java.lang.ClassNotFoundException: org.jboss.aop.proxy$org.jboss.test.aop.bean.NonadvisedPOJO - Suite: org.jboss.test.classloader.test.ScopingUnitTestCase Test:testWarXmlOverrides Type:error Exception: java.net.MalformedURLException Message: unknown protocol: d - Suite: org.jboss.test.cmp2.readonly.ReadonlyUnitTestCase Test:testSetUp Type:error Exception: net.sourceforge.junitejb.RemoteTestException Message: Column not found: ID in statement [INSERT INTO Publisher (id, name) VALUES (1,'O''Reilly Associates')] === Wed Jan 21 01:19:18 GMTST 2004 === CYGWIN_NT-5.1 quarks2 1.5.4(0.94/3/2) 2003-09-12 23:08 i686 unknown unknown Cygwin === java -version java version 1.4.1_06 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_06-b01) Java HotSpot(TM) Client VM (build 1.4.1_06-b01, mixed mode) --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Automated JBoss(Branch_3_2 WonderLand) Testsuite Results: 18-January-2004
Sometimes, running deadlock test I see java.lang.ArrayIndexOutOfBoundsException at java.lang.System.arraycopy(Native Method) at java.util.ArrayList.ensureCapacity(ArrayList.java:170) at java.util.ArrayList.add(ArrayList.java:354) at org.jboss.tm.TransactionImpl.associateCurrentThread(TransactionImpl.java :760) isn't it a bug in ArrayList impl? [EMAIL PROTECTED] testsuite]$ java -version java version 1.4.2_03 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-b02) Java HotSpot(TM) Client VM (build 1.4.2_03-b02, mixed mode) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott M Stark Sent: Tuesday, January 20, 2004 11:34 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Automated JBoss(Branch_3_2 WonderLand) Testsuite Results: 18-January-2004 Out of these failures, the following need to be resolved before the 3.2.4RC1 release: Suite: org.jboss.test.cts.test.StatefulSessionUnitTestCase Test:testStrictPooling Suite: org.jboss.test.jmx.test.DeployXMBeanUnitTestCase Test:testUserXMBeanPersistentValues Suite: org.jboss.test.security.test.EJBSpecUnitTestCase Test:testMDBRunAs Suite: org.jboss.test.deadlock.test.BeanStressTestCase Test:testDeadLock Suite: org.jboss.test.deadlock.test.BeanStressTestCase Test:testAllCompleteOrFail Suite: org.jboss.test.deadlock.test.BeanStressTestCase Test:testAllCompleteOrFailNotSupportedReentrant Suite: org.jboss.test.deadlock.test.BeanStressTestCase Test:testAllCompleteOrFailCMR Suite: org.jboss.test.jca.test.CachedConnectionBankStressTestCase Test:testCachedConnectionBank Suite: org.jboss.test.lock.test.EnterpriseEntityStressTestCase Test:unknown The remainder are known issues. I'm working on the DeployXMBeanUnitTestCase and EJBSpecUnitTestCase failures. I need to know who is looking into the others. Scott Stark Chief Technology Officer JBoss Group, LLC --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Automated JBoss(Branch_3_2 WonderLand) Testsuite Results: 18-January-2004
In java.lang.System.arraycopy... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alexey Loubyansky Sent: Wednesday, January 21, 2004 3:44 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Automated JBoss(Branch_3_2 WonderLand) Testsuite Results: 18-January-2004 Sometimes, running deadlock test I see java.lang.ArrayIndexOutOfBoundsException at java.lang.System.arraycopy(Native Method) at java.util.ArrayList.ensureCapacity(ArrayList.java:170) at java.util.ArrayList.add(ArrayList.java:354) at org.jboss.tm.TransactionImpl.associateCurrentThread(Transactio nImpl.java :760) isn't it a bug in ArrayList impl? [EMAIL PROTECTED] testsuite]$ java -version java version 1.4.2_03 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-b02) Java HotSpot(TM) Client VM (build 1.4.2_03-b02, mixed mode) --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBoss Test Results: 94 % ( 1450 / 1533 ) - come on - pull your finger out. JBoss (HEAD/linux1/1.4.1_06) [AUTOMATED]
=== ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS== === === Wed Jan 21 02:32:39 GMT 2004 === HERE ARE THE LAST 100 LINES OF THE LOG: === ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS== === === JBoss daily test results SUMMARY Number of tests run: 1533 Successful tests: 1450 Errors:64 Failures: 19 [time of test: 2004-01-21.00-43 GMT] [java.version: 1.4.1_06] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.4.1_06-b01] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.20-28.7] Useful resources: - http://jboss.kimptoc.net/linux1/1.4.1_06/logtests/testresults/reports/html//2004-01-21.00-43 for the junit report of this test. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS Suite: org.jboss.test.aop.test.RemotingUnitTestCase Test:testRemoting Type:error Exception: java.rmi.UnmarshalException Message: error unmarshalling return; nested exception is: java.lang.ClassNotFoundException: org.jboss.aop.proxy$org.jboss.test.aop.bean.POJO - Suite: org.jboss.test.aop.test.RemotingUnitTestCase Test:testNonadvisedRemoting Type:error Exception: java.rmi.UnmarshalException Message: error unmarshalling return; nested exception is: java.lang.ClassNotFoundException: org.jboss.aop.proxy$org.jboss.test.aop.bean.NonadvisedPOJO - Suite: org.jboss.test.aop.test.RemotingUnitTestCase Test:testClusteredRemoting Type:error Exception: java.rmi.UnmarshalException Message: error unmarshalling return; nested exception is: java.lang.ClassNotFoundException: org.jboss.aop.proxy$org.jboss.test.aop.bean.POJO - Suite: org.jboss.test.aop.test.RemotingUnitTestCase Test:testClusteredNonadvisedRemoting Type:error Exception: java.rmi.UnmarshalException Message: error unmarshalling return; nested exception is: java.lang.ClassNotFoundException: org.jboss.aop.proxy$org.jboss.test.aop.bean.NonadvisedPOJO - Suite: org.jboss.test.cache.test.local.TxConcurrentUnitTestCase Test:unknown Type:error Exception: junit.framework.AssertionFailedError Message: Timeout occurred - Suite: org.jboss.test.classloader.test.ScopingUnitTestCase Test:testWarXmlOverrides Type:error Exception: java.net.MalformedURLException Message: no protocol: /home/jbossci/jbossci2/jboss-head-test/testsuite/output/lib/oldxerces.war === Wed Jan 21 02:32:39 GMT 2004 === Linux nog.kimptoc.net 2.4.20-28.7 #1 Thu Dec 18 11:31:59 EST 2003 i686 unknown === java -version java version 1.4.1_06 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_06-b01) Java HotSpot(TM) Client VM (build 1.4.1_06-b01, mixed mode) --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Automated JBoss(Branch_3_2 WonderLand) Testsuite Results: 18-January-2004
Not likely. I would guess this is due to concurrent access to the unsynchronized threads ArrayList. What is the full stack that producing this error? Scott Stark Chief Technology Officer JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alexey Loubyansky Sent: Tuesday, January 20, 2004 5:44 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Automated JBoss(Branch_3_2 WonderLand) Testsuite Results: 18-January-2004 Sometimes, running deadlock test I see java.lang.ArrayIndexOutOfBoundsException at java.lang.System.arraycopy(Native Method) at java.util.ArrayList.ensureCapacity(ArrayList.java:170) at java.util.ArrayList.add(ArrayList.java:354) at org.jboss.tm.TransactionImpl.associateCurrentThread(TransactionImpl.java :760) isn't it a bug in ArrayList impl? [EMAIL PROTECTED] testsuite]$ java -version java version 1.4.2_03 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-b02) Java HotSpot(TM) Client VM (build 1.4.2_03-b02, mixed mode) --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-881012 ] Cannot change partition name
Bugs item #881012, was opened at 2004-01-20 17:10 Message generated for change (Comment added) made by starksm You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=881012group_id=22866 Category: Clustering Group: v3.2 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Vinh Nguyen (macronetics) Assigned to: Scott M Stark (starksm) Summary: Cannot change partition name Initial Comment: When I tried to change DefaultPartition to MyPartition under the all configuation, I got the following error: 19:59:38,848 ERROR [HAILSharedState] Starting failed java.lang.NullPointerException at org.jboss.ha.jmx.HAServiceMBeanSupport.registerRPCHan dler(HAServiceMB eanSupport.java:173) at org.jboss.ha.jmx.HAServiceMBeanSupport.startService (HAServiceMBeanSup port.java:142) at org.jboss.system.ServiceMBeanSupport.start (ServiceMBeanSupport.java:1 92) at sun.reflect.GeneratedMethodAccessor31.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.system.ServiceController$ServiceProxy.invoke (ServiceControl ler.java:976) at $Proxy14.start(Unknown Source) at org.jboss.system.ServiceController.start (ServiceController.java:394) at org.jboss.system.ServiceController.start (ServiceController.java:411) at sun.reflect.GeneratedMethodAccessor6.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.mx.util.MBeanProxyExt.invoke (MBeanProxyExt.java:177) at $Proxy4.start(Unknown Source) at org.jboss.deployment.SARDeployer.start (SARDeployer.java:226) at org.jboss.deployment.MainDeployer.start (MainDeployer.java:832) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:642) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:605) at sun.reflect.GeneratedMethodAccessor26.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.mx.util.MBeanProxyExt.invoke (MBeanProxyExt.java:177) at $Proxy6.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.de ploy(URLDeploymen tScanner.java:302) at org.jboss.deployment.scanner.URLDeploymentScanner.sc an(URLDeploymentS canner.java:476) at org.jboss.deployment.scanner.AbstractDeploymentScann er$ScannerThread. doScan(AbstractDeploymentScanner.java:201) at org.jboss.deployment.scanner.AbstractDeploymentScann er.startService(A bstractDeploymentScanner.java:274) at org.jboss.system.ServiceMBeanSupport.start (ServiceMBeanSupport.java:1 92) at sun.reflect.GeneratedMethodAccessor5.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.system.ServiceController$ServiceProxy.invoke (ServiceControl ler.java:976) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start (ServiceController.java:394) at sun.reflect.GeneratedMethodAccessor6.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.mx.util.MBeanProxyExt.invoke (MBeanProxyExt.java:177) at $Proxy4.start(Unknown Source) at org.jboss.deployment.SARDeployer.start (SARDeployer.java:226) at org.jboss.deployment.MainDeployer.start (MainDeployer.java:832) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:642) at org.jboss.deployment.MainDeployer.deploy
[JBoss-dev] [ jboss-Bugs-881012 ] Cannot change partition name
Bugs item #881012, was opened at 2004-01-20 20:10 Message generated for change (Settings changed) made by macronetics You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=881012group_id=22866 Category: Clustering Group: v3.2 Status: Open Resolution: Invalid Priority: 5 Submitted By: Vinh Nguyen (macronetics) Assigned to: Scott M Stark (starksm) Summary: Cannot change partition name Initial Comment: When I tried to change DefaultPartition to MyPartition under the all configuation, I got the following error: 19:59:38,848 ERROR [HAILSharedState] Starting failed java.lang.NullPointerException at org.jboss.ha.jmx.HAServiceMBeanSupport.registerRPCHan dler(HAServiceMB eanSupport.java:173) at org.jboss.ha.jmx.HAServiceMBeanSupport.startService (HAServiceMBeanSup port.java:142) at org.jboss.system.ServiceMBeanSupport.start (ServiceMBeanSupport.java:1 92) at sun.reflect.GeneratedMethodAccessor31.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.system.ServiceController$ServiceProxy.invoke (ServiceControl ler.java:976) at $Proxy14.start(Unknown Source) at org.jboss.system.ServiceController.start (ServiceController.java:394) at org.jboss.system.ServiceController.start (ServiceController.java:411) at sun.reflect.GeneratedMethodAccessor6.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.mx.util.MBeanProxyExt.invoke (MBeanProxyExt.java:177) at $Proxy4.start(Unknown Source) at org.jboss.deployment.SARDeployer.start (SARDeployer.java:226) at org.jboss.deployment.MainDeployer.start (MainDeployer.java:832) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:642) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:605) at sun.reflect.GeneratedMethodAccessor26.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.mx.util.MBeanProxyExt.invoke (MBeanProxyExt.java:177) at $Proxy6.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.de ploy(URLDeploymen tScanner.java:302) at org.jboss.deployment.scanner.URLDeploymentScanner.sc an(URLDeploymentS canner.java:476) at org.jboss.deployment.scanner.AbstractDeploymentScann er$ScannerThread. doScan(AbstractDeploymentScanner.java:201) at org.jboss.deployment.scanner.AbstractDeploymentScann er.startService(A bstractDeploymentScanner.java:274) at org.jboss.system.ServiceMBeanSupport.start (ServiceMBeanSupport.java:1 92) at sun.reflect.GeneratedMethodAccessor5.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.system.ServiceController$ServiceProxy.invoke (ServiceControl ler.java:976) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start (ServiceController.java:394) at sun.reflect.GeneratedMethodAccessor6.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.mx.util.MBeanProxyExt.invoke (MBeanProxyExt.java:177) at $Proxy4.start(Unknown Source) at org.jboss.deployment.SARDeployer.start (SARDeployer.java:226) at org.jboss.deployment.MainDeployer.start (MainDeployer.java:832) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:642) at org.jboss.deployment.MainDeployer.deploy
[JBoss-dev] [ jboss-Bugs-881012 ] Cannot change partition name
Bugs item #881012, was opened at 2004-01-20 20:10 Message generated for change (Comment added) made by macronetics You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=881012group_id=22866 Category: Clustering Group: v3.2 Status: Open Resolution: Invalid Priority: 5 Submitted By: Vinh Nguyen (macronetics) Assigned to: Scott M Stark (starksm) Summary: Cannot change partition name Initial Comment: When I tried to change DefaultPartition to MyPartition under the all configuation, I got the following error: 19:59:38,848 ERROR [HAILSharedState] Starting failed java.lang.NullPointerException at org.jboss.ha.jmx.HAServiceMBeanSupport.registerRPCHan dler(HAServiceMB eanSupport.java:173) at org.jboss.ha.jmx.HAServiceMBeanSupport.startService (HAServiceMBeanSup port.java:142) at org.jboss.system.ServiceMBeanSupport.start (ServiceMBeanSupport.java:1 92) at sun.reflect.GeneratedMethodAccessor31.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.system.ServiceController$ServiceProxy.invoke (ServiceControl ler.java:976) at $Proxy14.start(Unknown Source) at org.jboss.system.ServiceController.start (ServiceController.java:394) at org.jboss.system.ServiceController.start (ServiceController.java:411) at sun.reflect.GeneratedMethodAccessor6.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.mx.util.MBeanProxyExt.invoke (MBeanProxyExt.java:177) at $Proxy4.start(Unknown Source) at org.jboss.deployment.SARDeployer.start (SARDeployer.java:226) at org.jboss.deployment.MainDeployer.start (MainDeployer.java:832) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:642) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:605) at sun.reflect.GeneratedMethodAccessor26.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.mx.util.MBeanProxyExt.invoke (MBeanProxyExt.java:177) at $Proxy6.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.de ploy(URLDeploymen tScanner.java:302) at org.jboss.deployment.scanner.URLDeploymentScanner.sc an(URLDeploymentS canner.java:476) at org.jboss.deployment.scanner.AbstractDeploymentScann er$ScannerThread. doScan(AbstractDeploymentScanner.java:201) at org.jboss.deployment.scanner.AbstractDeploymentScann er.startService(A bstractDeploymentScanner.java:274) at org.jboss.system.ServiceMBeanSupport.start (ServiceMBeanSupport.java:1 92) at sun.reflect.GeneratedMethodAccessor5.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.system.ServiceController$ServiceProxy.invoke (ServiceControl ler.java:976) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start (ServiceController.java:394) at sun.reflect.GeneratedMethodAccessor6.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.mx.util.MBeanProxyExt.invoke (MBeanProxyExt.java:177) at $Proxy4.start(Unknown Source) at org.jboss.deployment.SARDeployer.start (SARDeployer.java:226) at org.jboss.deployment.MainDeployer.start (MainDeployer.java:832) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:642) at org.jboss.deployment.MainDeployer.deploy
[JBoss-dev] JBoss Test Results: 82 % ( 1063 / 1292 ) - come on - pull your finger out. JBoss (HEAD/winxp/1.4.2_03) [AUTOMATED]
=== ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS== === === Wed Jan 21 04:06:39 GMTST 2004 === HERE ARE THE LAST 100 LINES OF THE LOG: === ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS== === === JBoss daily test results SUMMARY Number of tests run: 1292 Successful tests: 1063 Errors:209 Failures: 20 [time of test: 2004-01-21.01-39 GMT] [java.version: 1.4.2_03] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.4.2_03-b02] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Windows XP] [os.arch: x86] [os.version: 5.1] Useful resources: - http://jboss.kimptoc.net/winxp/1.4.2_03/logtests/testresults/reports/html//2004-01-21.01-39 for the junit report of this test. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS Suite: org.jboss.test.aop.test.RemotingUnitTestCase Test:testRemoting Type:error Exception: java.rmi.UnmarshalException Message: error unmarshalling return; nested exception is: java.lang.ClassNotFoundException: org.jboss.aop.proxy$org.jboss.test.aop.bean.POJO - Suite: org.jboss.test.aop.test.RemotingUnitTestCase Test:testNonadvisedRemoting Type:error Exception: java.rmi.UnmarshalException Message: error unmarshalling return; nested exception is: java.lang.ClassNotFoundException: org.jboss.aop.proxy$org.jboss.test.aop.bean.NonadvisedPOJO - Suite: org.jboss.test.aop.test.RemotingUnitTestCase Test:testClusteredRemoting Type:error Exception: java.rmi.UnmarshalException Message: error unmarshalling return; nested exception is: java.lang.ClassNotFoundException: org.jboss.aop.proxy$org.jboss.test.aop.bean.POJO - Suite: org.jboss.test.aop.test.RemotingUnitTestCase Test:testClusteredNonadvisedRemoting Type:error Exception: java.rmi.UnmarshalException Message: error unmarshalling return; nested exception is: java.lang.ClassNotFoundException: org.jboss.aop.proxy$org.jboss.test.aop.bean.NonadvisedPOJO - Suite: org.jboss.test.cache.test.local.TxConcurrentUnitTestCase Test:unknown Type:error Exception: junit.framework.AssertionFailedError Message: Timeout occurred - Suite: org.jboss.test.classloader.test.ScopingUnitTestCase Test:testWarXmlOverrides Type:error Exception: java.net.MalformedURLException Message: unknown protocol: d === Wed Jan 21 04:06:40 GMTST 2004 === CYGWIN_NT-5.1 quarks2 1.5.4(0.94/3/2) 2003-09-12 23:08 i686 unknown unknown Cygwin === java -version java version 1.4.2_03 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-b02) Java HotSpot(TM) Client VM (build 1.4.2_03-b02, mixed mode) --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-881012 ] Cannot change partition name
Bugs item #881012, was opened at 2004-01-20 17:10 Message generated for change (Comment added) made by starksm You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=881012group_id=22866 Category: Clustering Group: v3.2 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Vinh Nguyen (macronetics) Assigned to: Scott M Stark (starksm) Summary: Cannot change partition name Initial Comment: When I tried to change DefaultPartition to MyPartition under the all configuation, I got the following error: 19:59:38,848 ERROR [HAILSharedState] Starting failed java.lang.NullPointerException at org.jboss.ha.jmx.HAServiceMBeanSupport.registerRPCHan dler(HAServiceMB eanSupport.java:173) at org.jboss.ha.jmx.HAServiceMBeanSupport.startService (HAServiceMBeanSup port.java:142) at org.jboss.system.ServiceMBeanSupport.start (ServiceMBeanSupport.java:1 92) at sun.reflect.GeneratedMethodAccessor31.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.system.ServiceController$ServiceProxy.invoke (ServiceControl ler.java:976) at $Proxy14.start(Unknown Source) at org.jboss.system.ServiceController.start (ServiceController.java:394) at org.jboss.system.ServiceController.start (ServiceController.java:411) at sun.reflect.GeneratedMethodAccessor6.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.mx.util.MBeanProxyExt.invoke (MBeanProxyExt.java:177) at $Proxy4.start(Unknown Source) at org.jboss.deployment.SARDeployer.start (SARDeployer.java:226) at org.jboss.deployment.MainDeployer.start (MainDeployer.java:832) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:642) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:605) at sun.reflect.GeneratedMethodAccessor26.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.mx.util.MBeanProxyExt.invoke (MBeanProxyExt.java:177) at $Proxy6.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.de ploy(URLDeploymen tScanner.java:302) at org.jboss.deployment.scanner.URLDeploymentScanner.sc an(URLDeploymentS canner.java:476) at org.jboss.deployment.scanner.AbstractDeploymentScann er$ScannerThread. doScan(AbstractDeploymentScanner.java:201) at org.jboss.deployment.scanner.AbstractDeploymentScann er.startService(A bstractDeploymentScanner.java:274) at org.jboss.system.ServiceMBeanSupport.start (ServiceMBeanSupport.java:1 92) at sun.reflect.GeneratedMethodAccessor5.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.system.ServiceController$ServiceProxy.invoke (ServiceControl ler.java:976) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start (ServiceController.java:394) at sun.reflect.GeneratedMethodAccessor6.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.mx.util.MBeanProxyExt.invoke (MBeanProxyExt.java:177) at $Proxy4.start(Unknown Source) at org.jboss.deployment.SARDeployer.start (SARDeployer.java:226) at org.jboss.deployment.MainDeployer.start (MainDeployer.java:832) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:642) at org.jboss.deployment.MainDeployer.deploy
