Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Received-SPF: pass (athena.apache.org: domain of bdekruijff@gmail.com
 designates 209.85.128.44 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CB213FFD-BEB9-483F-BD0F-9CEE988E0E04@adobe.com>
References: <006B43FB-D252-4410-A2B0-7423A07BD41D@yahoo.com>
	<CB213FFD-BEB9-483F-BD0F-9CEE988E0E04@adobe.com>
Date: Mon, 22 Apr 2013 15:49:48 +0200
Message-ID: 
 <CAKjo4PM+zib1u1h6mXDxSz_bU_rnwrmKDZgX193_Shph7k_6hw@mail.gmail.com>
Subject: Re: Config Admin problem and working around it or fixing it
From: Bram de Kruijff <bdekruijff@gmail.com>
To: dev@felix.apache.org
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Tue, Apr 9, 2013 at 7:32 AM, Felix Meschberger <fmeschbe@adobe.com> wrot=
e:
> 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 F=
elix config admin.  I've identified the problem more closely and wonder wha=
t 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 ComponentConfigurationP=
ID test to run it)
>>
>>    @Test
>>    public void testConfigAdminClosed() throws Exception
>>    {
>>        Bundle b =3D installBundle();
>>        b.start();
>>        BundleContext bc =3D b.getBundleContext();
>>        ServiceReference<ConfigurationAdmin> ref =3D bc.getServiceReferen=
ce( ConfigurationAdmin.class );
>>        ConfigurationAdmin ca =3D bc.getService( ref );
>>        Configuration conf =3D ca.getConfiguration( "foo.pid" );
>>        bc.ungetService( ref );
>>        String location =3D conf.getBundleLocation();
>>
>>    }
>>
>>    protected Bundle installBundle( ) throws BundleException
>>    {
>>        final InputStream bundleStream =3D bundle()
>>                .set(Constants.BUNDLE_SYMBOLICNAME, "simplecomponent2")
>>                .set(Constants.BUNDLE_VERSION, "0.0.11")
>>            .build(withBnd());
>>
>>        try
>>        {
>>            final String location =3D "test:SimpleComponent/" + System.cu=
rrentTimeMillis();
>>            return bundleContext.installBundle( location, bundleStream );
>>        }
>>        finally
>>        {
>>            try
>>            {
>>                bundleStream.close();
>>            }
>>            catch ( IOException ioe )
>>            {
>>            }
>>        }
>>    }
>>
>>
>> The line
>>        String location =3D conf.getBundleLocation();
>>
>> gives an NPE like this:
>>
>>    <error type=3D"java.lang.NullPointerException">java.lang.NullPointerE=
xception
>>       at org.apache.felix.cm.impl.ConfigurationAdminImpl.hasPermission(C=
onfigurationAdminImpl.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 d=
oes the logging in the Configuration or ConfigurationAdminImpl, so calling =
any method on the configuration that tries to log something will give an NP=
E.
>>
>> 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 t=
he 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 382=
0 fix fairly soon, DS will then not work with any older felix CA's (not sur=
e about anyone else's' CA).
>>
>> 3. backport the 3820 fix to earlier felix CA's and do bug fix releases o=
n them.  I'm not aware of this (back porting) ever happening in felix=85  D=
S users using felix CA  would have to upgrade but not change framework leve=
ls.
>>
>> I've implemented (1) but I'm not very happy about how the code looks.
>>
>> thoughts?
>>
>> thanks
>> david jencks
>>
>>
>>
>>
>
>
> --
> Felix Meschberger | Principal Scientist | Adobe
>
>
>
>
>
>
>