On Tue, Apr 9, 2013 at 7:32 AM, Felix Meschberger <[email protected]> wrote:
> Hi
>
> If the trunk build fixes your problem, we should just relase configadmin.
> WDYT ?
>
+1
As I quite persistently run into FELIX-3762 I would appreciate a release :)
thanks
Bram
> 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
>
>
>
>
>
>
>
