Config Admin problem and working around it or fixing it

[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