felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Config Admin problem and working around it or fixing it
Date Tue, 09 Apr 2013 05:50:55 GMT
That would be OK with me, but previously I think you requested that DS continue to work with
older spec versions of config admin.  If we want felix ds to work with older felix ca spec
versions we'd need to fix them too.  Are you OK with either requiring latest felix ca for
latest ds or with releasing several maintenance ca's?

thanks
david jencks

On Apr 8, 2013, at 10:32 PM, Felix Meschberger <fmeschbe@adobe.com> wrote:

> 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
> 
> 
> 
> 
> 
> 
> 


Mime
View raw message