Создание пакетов OSGi с различными сервисами

Мы используем Adobe Day CQ для нашего развертывания. В настоящее время мы создаем пакеты OSGi с развертыванием в CQ со всеми сервисами, используя maven-bundle-plugin.

Теперь у нас есть сценарий, в котором мы не хотим, чтобы некоторые службы включались в экземпляре публикации, но должны быть включены в авторе.

Есть ли способ, которым мы можем управлять двумя пакетами: один для автора с услугами, необходимыми для автора, и один для публикации, которые требуются при публикации, используя тот же файл pom.xml?
Или есть какой-то другой способ, которым эта вещь может мне управляться.
Пожалуйста, помогите мне в этом отношении. Мы сейчас используем это для создания пакетов:

<plugin>
            <groupId>org.apache.felix</groupId>
            <artifactId>maven-bundle-plugin</artifactId>
            <version>2.0.1</version>
            <extensions>true</extensions>
            <configuration>
                <instructions>
                    <Import-Package>
                        org.osgi.framework,
                        *;resolution:=optional
                    </Import-Package>
                    <Export-Package>
                          com.abc.platform.enow.aem.core.testing.*,
                        com.abc.platform.enow.aem.core.utils.*,
                    com.abc.platform.enow.aem.core.viewhelper.*,
                        com.abc.platform.enow.aem.core.search.*

                    </Export-Package>
                </instructions>
            </configuration>
</plugin>
Источник

2 ответа

Решение

Мы добились этого, используя свойство runmode для CQ. Мы сделали ниже:

  • Создана полная сборка.
  • На этапе распространения мы поместили файл jar (который нам нужно было установить только для автора) в папку /apps/"project_name"/install.author.
  • Здесь "автор" - режим запуска экземпляра.
  • Этот jar-файл развертывается как для автора, так и для публикации в папке install.author, но в установленном / отраженном только режиме автора.

Спасибо за ответ, но мы нашли это решение более гибким и выполнимым.

С уважением, Вайбхав

Источник

Есть два способа сделать это. Первый подход будет предпочтительнее

Выборочная активация через конфигурацию

Этого можно добиться, используя поддержку конфигурации на основе режима Sling Run и используя декларативные сервисы для управления регистрацией сервисов.

Свяжите свой сервис с конфигурацией

Используйте аннотацию SCR для привязки вашего сервиса к конфигурации

import org.apache.felix.scr.annotations.Activate;
import org.apache.felix.scr.annotations.Component;
import org.apache.felix.scr.annotations.ConfigurationPolicy;
import org.apache.felix.scr.annotations.Deactivate;
import org.apache.felix.scr.annotations.Property;
import org.apache.felix.scr.annotations.Service;


@Component(
    name = FooImpl.SERVICE_PID,
    policy = ConfigurationPolicy.REQUIRE)
@Service
public class FooImpl implements IFoo{
  public static final String SERVICE_PID = "com.foo.example";

В приведенном выше фрагменте кода мы

  • Зарегистрировать сервис, который реализует IFoo интерфейс
  • ConfigurationPolicy для компонента установлено REQUIRE т.е. без какой-либо явной конфигурации компонент и, следовательно, услуга не будут активированы и зарегистрированы
  • PID конфигурации установлен на com.foo.example, Если вы опустите его, то по умолчанию будет указано полное имя класса

Создать конфигурацию в нужной папке Run Mode

В CQ установщик Sling будет развертывать конфигурацию и пакет из репозитория на основе режима запуска. Так что, если вы развертываете свой код через Content Packages, тогда

  • Создайте узел конфигурации под путем /apps/<yourProject>/config.author/com.foo.example
  • Под указанным выше путем просто создайте пустую оду (если вы не хотите предоставлять другие свойства конфигурации) типа sling:OsgiConfig

После внесения вышеуказанных изменений разверните пакет контента на различных экземплярах CQ.

  • Когда пакет развернут на любом экземпляре CQ, тогда конфигурация для PID com.foo.example будет создан только когда режим запуска установлен на Автор
  • И только тогда, когда конфигурация активна, только тогда FooImpl компонент и сервис будут созданы и зарегистрированы

Использование SlingSettingsService

Другой подход может использовать SlingSettingsService.getRunModes, чтобы программно определять режим выполнения, а затем только регистрировать службу.

import org.apache.felix.scr.annotations.Activate;
import org.apache.felix.scr.annotations.Component;
import org.apache.felix.scr.annotations.Deactivate;
import org.apache.felix.scr.annotations.Reference;

@Component
public class FooImpl implements IFoo{

    @Reference
    private SlingSettingsService settingsService;

    private ServiceRegistration reg;

    @Activate
    public void activate(BundleContext context, Map<String, ?> conf){
        if(settingsService.getRunModes().contains("author")){
           reg = context.registerService(IFoo.class.getName(), this, null);
        }
    }

    @Deactivate
    private void deactivate(){
        if (reg != null){
            reg.unregister();
        }
    }
}

Пара моментов, которые нужно отметить для приведенного выше фрагмента

  • FooImpl не аннотируется @Service тег. Таким образом, SCR будет только активировать компонент, но не будет регистрировать какой-либо сервис
  • В activate метод, который мы используем SlingSettingsService проверить требуемый режим работы. В случае, если это author мы программно регистрируем сервис
  • Экземпляр службы удаляется позже в deactivate метод
Источник
Другие вопросы по тегам