You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Ulf Dittmer <ud...@yahoo.com> on 2010/02/22 12:07:40 UTC

ServiceListener: Changes between ConfigAdmin 1.0 and 1.2?

Hello everyone-

I have a ServiceListener that stores a service reference to the ConfigAdmin service when that's started, something like this:

public void serviceChanged (ServiceEvent event) {

    String[] objectClass = (String[]) event.getServiceReference().getProperty(Constants.OBJECTCLASS);

    if (event.getType() == ServiceEvent.REGISTERED) {
        if (objectClass[0].equals(ConfigurationAdmin.class.getName())) {
            ServiceReference servRef = context.getServiceReference(objectClass[0]);
            ConfigurationAdmin configAdmin = (ConfigurationAdmin) context.getService(servRef);

etc.

That worked fine using ConfigAdmin 1.0.10, which causes the listener to be called twice, one each for org.apache.felix.cm.PersistenceManager and org.osgi.service.cm.ConfigurationAdmin.

But ConfigAdmin 1.2.4 causes it to be called only once for org.apache.felix.cm.PersistenceManager, thus causing my app not to be aware of the newly installed ConfigAdmin. I'd like the code to be free of references to specific Felix classes, so my questions are: Is this a bug? Can the previous behavior be restored? Or should the code be doing something differently?

Thanks,
Ulf



      


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Re: ServiceListener: Changes between ConfigAdmin 1.0 and 1.2?

Posted by Felix Meschberger <fm...@gmail.com>.
Hi,

On 26.02.2010 12:14, Ulf Dittmer wrote:
> Turns out that the FRAMEWORK_SYSTEMPACKAGES_EXTRA still listed "org.osgi.service.cm;version=1.2", whereas ConfigAdmin 1.2 now implements version=1.3. As soon as I changed that, the service was registering just fine. D'oh!
> 
> Thanks for all your help.

Happy, that it was this "simple" in the end. Thanks for the feedback.

Regards
Felix

> 
> Ulf
> 
> 
> --- On Thu, 2/25/10, Felix Meschberger <fm...@gmail.com> wrote:
> 
>> I just know that the ConfigurationAdmin service registers itself correctly.
> 
> 
> 
>       
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Re: ServiceListener: Changes between ConfigAdmin 1.0 and 1.2?

Posted by Ulf Dittmer <ud...@yahoo.com>.
Turns out that the FRAMEWORK_SYSTEMPACKAGES_EXTRA still listed "org.osgi.service.cm;version=1.2", whereas ConfigAdmin 1.2 now implements version=1.3. As soon as I changed that, the service was registering just fine. D'oh!

Thanks for all your help.

Ulf


--- On Thu, 2/25/10, Felix Meschberger <fm...@gmail.com> wrote:

> I just know that the ConfigurationAdmin service registers itself correctly.



      


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Re: ServiceListener: Changes between ConfigAdmin 1.0 and 1.2?

Posted by Felix Meschberger <fm...@gmail.com>.
Hi,

On 25.02.2010 15:49, Ulf Dittmer wrote:
>> Point is, that you are probably doing the wrong thing:
>> The objectClass is an array possibly containing more than one entry. If
>> the ConfigurationAdmin class name is not the first entry it is missed.
> 
> I had actually checked that that was not the case; the code I posted was slightly simplified. Sorry if that was misleading. Would it then be a bug?
> 

Well, without seeing the actual code, I cannot tell more. I just know
that the ConfigurationAdmin service registers itself correctly.

One issue, that can occurr outside of the code is, if the
ConfigurationAdmin bundle is bound to another export of the
org.osgi.service.cm package than your client bundle.

> 
>> If you are interested in the ConfigurationAdmin service, you should
>> explicitly listen for that service and nothing else:
>>
>>    bundleContext.addServiceListener(listener,  "(objectClass=" + ConfigurationAdmin.class.getName() + ")");
>>
>> Better yet: use the ServiceTracker:
> 
> While I could do either, the app is kind of a generic bundle/service container that acts on ALL installed bundles and services. It obviously does something special for a ConfigAdmin, but other than that I was really hoping to keep it as generic as possible.

Generic is good, but it should not be overdone.

> 
> 
>> Yet, you should not assign the ConfigurationAdmin service to an instance
>> field in this case and instead call the getService() when you need the service.
> 
> Why is that? (Just trying to understand if there's something about OSGi or Felix that I don't have a handle on yet.)

If you assign it to a field and do not reset the field if the service is
unregistered you cause at least two issues: when calling the defunct
service you get unexpected errors and you keep a reference to the
service preventing the garbage collector from doing its work.

This is really mostly a problem if you are using the ServiceTracker. If
your are using your home-grown solution, you just have to make sure to
drop the reference on service unregistration.

Regards
Felix
> 
> Thanks,
> Ulf
> 
> 
> 
>       
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Re: ServiceListener: Changes between ConfigAdmin 1.0 and 1.2?

Posted by Ulf Dittmer <ud...@yahoo.com>.
> Point is, that you are probably doing the wrong thing:
> The objectClass is an array possibly containing more than one entry. If
> the ConfigurationAdmin class name is not the first entry it is missed.

I had actually checked that that was not the case; the code I posted was slightly simplified. Sorry if that was misleading. Would it then be a bug?


> If you are interested in the ConfigurationAdmin service, you should
> explicitly listen for that service and nothing else:
> 
>    bundleContext.addServiceListener(listener,  "(objectClass=" + ConfigurationAdmin.class.getName() + ")");
>
> Better yet: use the ServiceTracker:

While I could do either, the app is kind of a generic bundle/service container that acts on ALL installed bundles and services. It obviously does something special for a ConfigAdmin, but other than that I was really hoping to keep it as generic as possible.


> Yet, you should not assign the ConfigurationAdmin service to an instance
> field in this case and instead call the getService() when you need the service.

Why is that? (Just trying to understand if there's something about OSGi or Felix that I don't have a handle on yet.)

Thanks,
Ulf



      


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Re: ServiceListener: Changes between ConfigAdmin 1.0 and 1.2?

Posted by Felix Meschberger <fm...@gmail.com>.
Hi,

Sorry, missed that ...

Point is, that you are probably doing the wrong thing:

On 22.02.2010 12:07, Ulf Dittmer wrote:
> Hello everyone-
> 
> I have a ServiceListener that stores a service reference to the ConfigAdmin service when that's started, something like this:
> 
> public void serviceChanged (ServiceEvent event) {
> 
>     String[] objectClass = (String[]) event.getServiceReference().getProperty(Constants.OBJECTCLASS);
> 
>     if (event.getType() == ServiceEvent.REGISTERED) {
>         if (objectClass[0].equals(ConfigurationAdmin.class.getName())) {

The objectClass is an array possibly containing more than one entry. If
the ConfigurationAdmin class name is not the first entry it is missed.

>             ServiceReference servRef = context.getServiceReference(objectClass[0]);
>             ConfigurationAdmin configAdmin = (ConfigurationAdmin) context.getService(servRef);
> 
> etc.
> 
> That worked fine using ConfigAdmin 1.0.10, which causes the listener to be called twice, one each for org.apache.felix.cm.PersistenceManager and org.osgi.service.cm.ConfigurationAdmin.

Because you dependended on an implementation detail ;-)
> 
> But ConfigAdmin 1.2.4 causes it to be called only once for org.apache.felix.cm.PersistenceManager, thus causing my app not to be aware of the newly installed ConfigAdmin. I'd like the code to be free of references to specific Felix classes, so my questions are: Is this a bug? Can the previous behavior be restored? Or should the code be doing something differently?

If you are interested in the ConfigurationAdmin service, you should
explicitly listen for that service and nothing else:

   bundleContext.addServiceListener(listener,
         "(objectClass=" + ConfigurationAdmin.class.getName() + ")");

Then the listener is only called for actual ConfigurationAdmin service
instances.

Better yet: use the ServiceTracker:

   ServiceTracker st = new ServiceTracker(bundleContext,
          ConfigurationAdmin.class.getName(), null);
   st.open();
   ConfigurationAdmin ca = (ConfigurationAdmin) st.getService();

Yet, you should not assign the ConfigurationAdmin service to an instance
field in this case and instead call the getService() when you need the
service.

Regards
Felix

> 
> Thanks,
> Ulf
> 
> 
> 
>       
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Re: ServiceListener: Changes between ConfigAdmin 1.0 and 1.2?

Posted by Ulf Dittmer <ud...@yahoo.com>.
Replying to myself here: since this doesn't seem to ring a bell with anyone, should I file a bug?


--- On Mon, 2/22/10, Ulf Dittmer <ud...@yahoo.com> wrote:

> From: Ulf Dittmer <ud...@yahoo.com>
> Subject: ServiceListener: Changes between ConfigAdmin 1.0 and 1.2?
> To: users@felix.apache.org
> Date: Monday, February 22, 2010, 6:07 AM
> Hello everyone-
> 
> I have a ServiceListener that stores a service reference to
> the ConfigAdmin service when that's started, something like this:
> 
> public void serviceChanged (ServiceEvent event) {
> 
>     String[] objectClass = (String[])
> event.getServiceReference().getProperty(Constants.OBJECTCLASS);
> 
>     if (event.getType() ==
> ServiceEvent.REGISTERED) {
>         if
> (objectClass[0].equals(ConfigurationAdmin.class.getName()))
> {
>             ServiceReference
> servRef = context.getServiceReference(objectClass[0]);
>            
> ConfigurationAdmin configAdmin = (ConfigurationAdmin)
> context.getService(servRef);
> 
> etc.
> 
> That worked fine using ConfigAdmin 1.0.10, which causes the
> listener to be called twice, one each for
> org.apache.felix.cm.PersistenceManager and
> org.osgi.service.cm.ConfigurationAdmin.
> 
> But ConfigAdmin 1.2.4 causes it to be called only once for
> org.apache.felix.cm.PersistenceManager, thus causing my app
> not to be aware of the newly installed ConfigAdmin. I'd like
> the code to be free of references to specific Felix classes,
> so my questions are: Is this a bug? Can the previous
> behavior be restored? Or should the code be doing something
> differently?
> 
> Thanks,
> Ulf



      


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org