Зачем использовать аннотацию @Component с каждой службой в CQ

Я немного смущен следующими вещами. Я понимаю!--0--> и @Component аннотации являются основными аннотациями, когда мы определяем компонент или службу в OSGi. Я имею в виду http://felix.apache.org/documentation/subprojects/apache-felix-maven-scr-plugin/scr-annotations.html и в чем разница между компонентами OSGi и услуги

вопросы:

  1. сервис не может быть создан без @Component аннотация, почему это?

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

  3. как мы используем класс, определенный как @Component, поскольку к сервису можно получить доступ через sling.getService(ServiceName.class)

9
cq5 osgi

2 ответов

  1. сервис can публикуется без @Component аннотаций, но вы должны сделать это программно. Если вы используете аннотацию, вы получаете выгоду от автоматического создания метаданных в инструменте сборки, а также от среды выполнения декларативных служб. Это многое упрощает. Если вы хотите сделать это с низкоуровневым кодом, вам нужно написать реализацию BundleActivator заявить, что с Bundle-Activator заголовок манифеста, вызов context.registerService etc. Дно строка: просто используйте @Component аннотации!

  2. проста: лень. Когда компонент является услугой, он может быть создан лениво "по требованию", т. е. только тогда, когда потребитель сначала пытается использовать услугу. С другой стороны, несервисные компоненты обычно делают другие вещи внутри себя, например, запуск веб-сервера или GUI или потока опроса, что угодно. Они должны работать все время, а не по требованию.

3. Я не понял вопроса.

  1. компонент, который не публикуется как сервис не может доступ извне пакета. Если вы хотите, чтобы он был доступен, он должен быть сервисом. Если вы считаете, что это бесполезно, рассмотрим компонент, который создает HTTP-сервер. Он открывает порт 80 и отвечает на сетевые запросы от внешнего мира. Таким образом, он делает что-то полезное, даже если это не услуга и недоступна из других пакетов. Этот вид компонента подобен мосту между вашим приложением и внешним миром; в то время как службы являются мостом между одной частью вашего приложения и другой частью.
7

  • OSGi - это тот, где пакеты устанавливаются и управляются. Все, что должно быть в OSGi, должно быть компонентом, будь то простой компонент, служба или сервлет. Именно поэтому нам также нужно использовать @Component с сервисом.

  • услуги синглтон. Все, что необходимо для управления Одноэлементным классом и использования ссылки на сервис, выполняется OSGi. С нашей стороны ничего не нужно делать. Так что все происходит автоматически. управляемый.

  • вы не получаете доступ к таким компонентам. Компоненты используются независимо. Цитирование примера из разных сообщений: Предположим, вы хотите написать серверный компонент, который сидит в сокете и отвечает на запросы по TCP/IP. Когда компонент запускается, он открывает сокет и создает потоки, необходимые для обслуживания клиентов. Когда он останавливается, он закрывает поток(Ы) и сокет

2