db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John H. Embretsen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3561) testStartStopManagementFromApplication(org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest)junit.framework.AssertionFailedError: expected:<2> but was:<5>
Date Fri, 28 Mar 2008 14:10:26 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12583039#action_12583039
] 

John H. Embretsen commented on DERBY-3561:
------------------------------------------

Assgned this to myself since I am spending some time looking into the issue.

At first I was pussled by the fact that MBeans from two different Derby systems were available
at the same time in the same JVM. As far as I know neither NSinSameJVMTest nor ServerPropertiesTest
perform any class loading tricks for this to happen.

Multiple trial/error runs eventually led me to the following clue, which I hope might lead
to a solution:

It seems that there is only one Derby system active when the test starts, but three MBeans
from an old Derby system are still present, as they have not been unregistered from the MBeanServer
(I guess the MBeanServer is the same for all test runs in the same JVM). These three MBeans
are: JDBC, Management and Version for derby.jar. This might be because the other mbeans (NetworkServer,
Version for derbynet.jar) were successfully unregistered as part of a NetworkServerControl.shutdown()
call in a previous test.

Then I discovered that if I added an "unregister" MBeanPermission for derby.jar in the special
security policy file for ServerPropertiesTest (java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/ServerPropertiesTest.policy),
the test does not fail anymore (at least in my minimal test runs).

I will do some more testing, but I thought I'd share my progress so far, in case anyone comes
up with any better explanations.
A solution seems to be to add the mentioned MBeanPermission to the special ServerPropertiesTest.policy
file, but other suggestions are welcome.


> testStartStopManagementFromApplication(org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest)junit.framework.AssertionFailedError:
expected:<2> but was:<5>
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-3561
>                 URL: https://issues.apache.org/jira/browse/DERBY-3561
>             Project: Derby
>          Issue Type: Bug
>          Components: Regression Test Failure
>    Affects Versions: 10.5.0.0
>            Reporter: Mike Matrigali
>            Assignee: John H. Embretsen
>
> The following test has been failing consistently in the tinderbox runs since about build
636714, unfortunately the run right before this build  failed so
> it may be from that one. 
> first tinderbox failure I could find:
> http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/testlog/SunOS-5.10_i86pc-i386/636714-org.apache.derbyTesting.functionTests.suites.All_diff.txt
> most recent as of this report:
> http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/testlog/SunOS-5.10_i86pc-i386/639156-org.apache.derbyTesting.functionTests.suites.All_diff.txt
> There was 1 failure:
> 1) testStartStopManagementFromApplication(org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest)junit.framework.AssertionFailedError:
expected:<2> but was:<5>
> 	at org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest.startStopManagement(ManagementMBeanTest.java:86)
> 	at org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest.testStartStopManagementFromApplication(ManagementMBeanTest.java:56)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> 	at junit.extensions.TestSetup.run(TestSetup.java:25)
> 	at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> 	at junit.extensions.TestSetup.run(TestSetup.java:25)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> 	at junit.extensions.TestSetup.run(TestSetup.java:25)
> 	at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message