You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by David Jencks <da...@yahoo.com> on 2013/04/07 22:29:11 UTC
Config Admin problem and working around it or fixing it
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
Re: Config Admin problem and working around it or fixing it
Posted by Bram de Kruijff <bd...@gmail.com>.
On Tue, Apr 9, 2013 at 7:32 AM, Felix Meschberger <fm...@adobe.com> 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
>
>
>
>
>
>
>
Re: Config Admin problem and working around it or fixing it
Posted by David Jencks <da...@yahoo.com>.
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 <fm...@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
>
>
>
>
>
>
>
Re: Config Admin problem and working around it or fixing it
Posted by Felix Meschberger <fm...@adobe.com>.
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