Thanks Alasdair! I've raised a bug against the CT for this issue too. David
On 30 August 2011 22:29, Alasdair Nottingham <[email protected]> wrote: > Hi, > > I have a prototype fix that allows us to tolerate the mixed case and it > allows me to pass all but 4 of the tests. The 4 that fail have the following > error: > > org.osgi.framework.BundleException: An error occurred trying to read the > bundle at > org.eclipse.osgi.internal.baseadaptor.BundleInstall.begin(BundleInstall.java:94) > at > org.eclipse.osgi.framework.internal.core.Framework.installWorkerPrivileged(Framework.java:922) > at > org.eclipse.osgi.framework.internal.core.Framework$1.run(Framework.java:838) > at java.security.AccessController.doPrivileged(Native Method) at > org.eclipse.osgi.framework.internal.core.Framework.installWorker(Framework.java:889) > at > org.eclipse.osgi.framework.internal.core.Framework.installBundle(Framework.java:833) > at > org.eclipse.osgi.framework.internal.core.BundleContextImpl.installBundle(BundleContextImpl.java:166) > at > org.eclipse.osgi.framework.internal.core.BundleContextImpl.installBundle(BundleContextImpl.java:160) > at > org.osgi.test.cases.jmx.junit.FrameworkMBeanLifecycleTestCase.installFramework(FrameworkMBeanLifecycleTestCase.java:424) > at > org.osgi.test.cases.jmx.junit.FrameworkMBeanLifecycleTestCase.setUp(FrameworkMBeanLifecycleTestCase.java:82) > at junit.framework.TestCase.runBare(TestCase.java:128) at > junit.framework.TestResult$1.protect(TestResult.java:106) at > junit.framework.TestResult.runProtected(TestResult.java:124) at > junit.framework.TestResult.run(TestResult.java:109) at > junit.framework.TestCase.run(TestCase.java:120) at > junit.framework.TestSuite.runTest(TestSuite.java:230) at > junit.framework.TestSuite.run(TestSuite.java:225) at > junit.framework.TestSuite.runTest(TestSuite.java:230) at > junit.framework.TestSuite.run(TestSuite.java:225) at > aQute.junit.runtime.Target.doTesting(Target.java:234) at > aQute.junit.runtime.Target.run(Target.java:57) at > aQute.junit.runtime.Target.main(Target.java:37) Caused by: > java.io.FileNotFoundException: jar/org.osgi.impl.bundle.jmx-4.2.0.jar (No > such file or directory) at java.io.FileInputStream.open(Native Method) at > java.io.FileInputStream.<init>(FileInputStream.java:120) at > java.io.FileInputStream.<init>(FileInputStream.java:79) at > sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:70) > at > sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:161) > at > org.eclipse.osgi.internal.baseadaptor.BundleInstall.begin(BundleInstall.java:56) > ... 21 more > > > which isn't surprising given our bundle isn't called > org.osgi.impl.bundle.jmx-4.2.0.jar. It seems to me the tests are a little > brittle if they will only run against the CT. > > Alasdair > > On 30 August 2011 14:01, Alasdair Nottingham <[email protected]> wrote: > >> Hi, >> >> I've taken a look at the failures and they all seem to stem from an >> inconsistency in the spec. The JmxConstants defines the tabular data type >> for the PROPERTIES_TYPE to be "PROPERTIES". Other bits of the spec indicate >> it should be "Properties". The CT uses "Properties" and our runtime >> validates the type against JmxConstants.PROPERTIES_TYPE and they don't match >> because of the mixture of case. >> >> I'll raise a bug against the spec. >> >> Alasdair >> >> >> On 22 August 2011 06:48, David Bosschaert <[email protected]>wrote: >> >>> Hi all, >>> >>> I'm looking at the possibility of enhancing the Apache Aries >>> implementation so that it could become an implementation of the >>> updated OSGi-JMX spec (RFC 169 in [1]). >>> >>> As a starting point I was running the unmodified implementation >>> against the OSGi JMX TCK to see where we stand :) >>> With that I'm currently getting 14 errors (and 94 passes), where the >>> problems are either 'Invalid CompositeType' or 'Invalid TabularType' >>> ones (see below for two examples). >>> >>> <test name='testAddInformation' >>> class='org.osgi.test.cases.jmx.junit.ProvisioningServiceMBeanTestCase'> >>> <error >>> name='testAddInformation(org.osgi.test.cases.jmx.junit.ProvisioningServiceMBeanTestCase)' >>> type='java.lang.IllegalArgumentException: Invalid CompositeType >>> >>> [javax.management.openmbean.CompositeType(name=Property,items=((itemName=Key,itemType=javax.management.openmbean.SimpleType(name=java.lang.String)),(itemName=Type,itemType=javax.management.openmbean.SimpleType(name=java.lang.String)),(itemName=Value,itemType=javax.management.openmbean.SimpleType(name=java.lang.String))))]'> >>> <test name='testConfigurationGetBundleLocation' >>> class='org.osgi.test.cases.jmx.junit.ConfigurationAdminMBeanTestCase'> >>> <error >>> name='testConfigurationGetBundleLocation(org.osgi.test.cases.jmx.junit.ConfigurationAdminMBeanTestCase)' >>> type='java.io.IOException: Invalid TabularType >>> >>> [javax.management.openmbean.TabularType(name=Properties,rowType=javax.management.openmbean.CompositeType(name=Property,items=((itemName=Key,itemType=javax.management.openmbean.SimpleType(name=java.lang.String)),(itemName=Type,itemType=javax.management.openmbean.SimpleType(name=java.lang.String)),(itemName=Value,itemType=javax.management.openmbean.SimpleType(name=java.lang.String)))),indexNames=(Key))]'> >>> >>> Are these errors known/expected or has anyone been able to run Aries >>> JMX successfully against the OSGi TCK? >>> >>> Thanks, >>> >>> David >>> >>> [1] http://www.osgi.org/download/osgi-early-draft-2011-05.pdf >>> >> >> >> >> -- >> Alasdair Nottingham >> [email protected] >> > > > > -- > Alasdair Nottingham > [email protected] >
