Hi
If the trunk build fixes your problem, we should just relase configadmin. WDYT ?
Regards
Felix
Am 07.04.2013 um 14:29 schrieb David Jencks:
> I mentioned somewhere recently that my implementation of R5 features for DS
> was stalled due to test failures running against released versions of Felix
> config admin. I've identified the problem more closely and wonder what to do.
>
> The config admin problem appears to be solved by FELIX-3820. Here's some test
> code that reproduces it (I put this in the DS ComponentConfigurationPID test
> to run it)
>
> @Test
> public void testConfigAdminClosed() throws Exception
> {
> Bundle b = installBundle();
> b.start();
> BundleContext bc = b.getBundleContext();
> ServiceReference<ConfigurationAdmin> ref = bc.getServiceReference(
> ConfigurationAdmin.class );
> ConfigurationAdmin ca = bc.getService( ref );
> Configuration conf = ca.getConfiguration( "foo.pid" );
> bc.ungetService( ref );
> String location = conf.getBundleLocation();
>
> }
>
> protected Bundle installBundle( ) throws BundleException
> {
> final InputStream bundleStream = bundle()
> .set(Constants.BUNDLE_SYMBOLICNAME, "simplecomponent2")
> .set(Constants.BUNDLE_VERSION, "0.0.11")
> .build(withBnd());
>
> try
> {
> final String location = "test:SimpleComponent/" +
> System.currentTimeMillis();
> return bundleContext.installBundle( location, bundleStream );
> }
> finally
> {
> try
> {
> bundleStream.close();
> }
> catch ( IOException ioe )
> {
> }
> }
> }
>
>
> The line
> String location = conf.getBundleLocation();
>
> gives an NPE like this:
>
> <error type="java.lang.NullPointerException">java.lang.NullPointerException
> at
> org.apache.felix.cm.impl.ConfigurationAdminImpl.hasPermission(ConfigurationAdminImpl.java:156)
> at
> org.apache.felix.cm.impl.ConfigurationAdminImpl.checkPermission(ConfigurationAdminImpl.java:170)
> at
> org.apache.felix.cm.impl.ConfigurationAdapter.getBundleLocation(ConfigurationAdapter.java:73)
> at
> org.apache.felix.scr.integration.ComponentConfigurationPidTest.testConfigAdmingClosed(ComponentConfigurationPidTest.java:137)
>
>
> IIUC the problem is that ungetting the CA ref nulls out the field that does
> the logging in the Configuration or ConfigurationAdminImpl, so calling any
> method on the configuration that tries to log something will give an NPE.
>
> You can call conf.getBundleLocation() successfully as long as you still have
> the CA ref.
>
> I think this is an egregious bug in felix CA. Did I miss something in the
> spec that says this is OK and that configurations are only usable while you
> hold the CA reference?
>
> I can think of 3 courses of action:
>
> 1. make the code structure worse in DS so that DS holds the ref until it is
> done validating the configuration and extracting the properties.
>
> 2. require use of the R5 ca and try to get a CA release out with the 3820 fix
> fairly soon, DS will then not work with any older felix CA's (not sure about
> anyone else's' CA).
>
> 3. backport the 3820 fix to earlier felix CA's and do bug fix releases on
> them. I'm not aware of this (back porting) ever happening in felix… DS
> users using felix CA would have to upgrade but not change framework levels.
>
> I've implemented (1) but I'm not very happy about how the code looks.
>
> thoughts?
>
> thanks
> david jencks
>
>
>
>
--
Felix Meschberger | Principal Scientist | Adobe
