OSGi - ServiceTracker - ServiceTrackerCustomizer

Question

Конструктор трекера службы является, например: ServiceTracker(BundleContext,Filter,ServiceTrackerCustomizer)

где ServiceTrackerCustomizer реализует следующий интерфейс:

public interface ServiceTrackerCustomizer { 
public Object addingService(ServiceReference reference); 
public void modifiedService(ServiceReference reference, Object service); 
public void removedService(ServiceReference reference, Object service); 

}

Я понимаю, настройщик быть если вы хотите, например, добавить пользовательские действия, когда регистрируется отслеживаемая служба и т. д.

Но я изо всех сил пытаюсь понять, какова ссылка, которая передается в «addService», а также как возвращается объект, который возвращается.

Скажите, что вы хотите отслеживать сервис, ссылка на который является REF, и вы хотите распечатывать сообщение всякий раз, когда добавляется сервис. Настройщиком было бы что-то вроде:

public class MyServiceTrackerCustomizer implements ServiceTrackerCustomizer { 
    // Is REF the ref provided "behind the scene"? 
    public Object addingService(ServiceReference reference) { 
     // TODO Auto-generated method stub 
     System.out.println("In tracker customizer -> service added"); 

     // What is the object returned? 
     return Object; 
    } 
} 

Заранее благодарим за любые разъяснения, которые вы можете предоставить. Christian

Answer 1

Вы рассмотрели стандартную реализацию addingService в классе ServiceTracker?

public T addingService(ServiceReference<S> reference) { 
     @SuppressWarnings("unchecked") 
     T result = (T) context.getService(reference); 
     return result; 
    } 

Конечно, вы можете захотеть вернуть другой объект для отслеживания. Например, вы можете обернуть фактический объект службы в какой-либо обертке, теперь вы не можете получить объект службы и просто вернуть ссылку, или вы можете изучить ссылку и решить, что не хотите отслеживать ее, возвращая null.

Answer 2

ServiceTracker позволяет создавать и хранить любые объекты, которые вам нравятся в методе addService, а затем повторно использовать этот объект в modifiedService и removeService.

Поведение по умолчанию - это получить объект службы в addService и отключить его в удаленном сервисе. Поэтому, когда вы можете делать то, что вам нравится, вы должны убедиться, что если вы получите объект службы, вы также должны его отключить позже.

С поведением по умолчанию вы можете использовать метод getService() службы tracker для работы с найденной в данный момент службой, но это означает, что ваш код зависит от API OSGi, который не идеален.

Итак, еще один пример использования - создать ваше pojo и ввести его в службу addService. Затем вы можете сохранить свое pojo, вернув его. Затем в modifiedService и removedService вы можете работать с вашим pojo. Например, вы можете вызвать метод destroy на нем при удалении.

Один расширенный вариант использования для создания и хранения другого ServiceTracker. Таким образом, с внешним ServiceTracker вы можете отслеживать ServiceA и с внутренним ServiceB. Внутри внутреннего вы могли бы создать свое pojo и ввести его обеими службами. Таким образом, это позволяет вам решить случай, когда ваше pojo должно быть активным только тогда, когда доступны обе службы. Например, см. TransactionManagerTracker. Он отслеживает сервис TransactionManager. Если он найден, он создает другой трекер, который затем отслеживает службу DataSourceFactory. Если оба доступны, то pojo PooledDataSourceFactory создается с обоими. Если одна из служб уходит, то она снова уничтожается.

Нейл написал превосходную статью, которая также охватывает некоторые дополнительные случаи. См. When ServiceTracker Trumps Declarative Services.На самом деле эта статья заставила меня понять, что я могу покрыть свой вышеприведенный случай ServiceTracker.