Есть ли лучшая альтернатива расширению SlingPostServlet? - PullRequest
Новая
       13

Есть ли лучшая альтернатива расширению SlingPostServlet?

1 голос
/ 22 апреля 2019

В приложении Sling я хочу убедиться, что узлы, созданные с определенным sling:resourceType, всегда имеют дочерний узел, созданный с определенными свойствами.Какой способ достижения этого соответствует передовому опыту?

  1. Расширение класса SlingPostServlet и добавление функциональности для добавления дочернего узла в методе doPost().Это было бы неплохо, поскольку на первый взгляд можно связать сервлет с конкретным типом ресурса и вызвать super.doPost(), чтобы использовать обработку по умолчанию SlingPostServlet.Однако при установке пакета org.apache.sling.servlets.post.impl не может быть решена ( аналогичная проблема возникла у другого пользователя ), что препятствует запуску пакета вообще.

  2. Создание SlingPostProcessor и добавление функциональности в метод process().Это кажется менее желательным, поскольку оно не привязано к одному конкретному типу ресурса.

  3. Использование Sling Eventing .

Iхотел бы избежать расширения SlingAllMethodsServlet, так как было бы полезно сохранить доступ ко всем функциям по умолчанию в SlingPostServlet.Однако возможно ли продлить SlingPostServlet вместо SlingAllMethodsServlet?

1 Ответ

2 голосов
/ 24 апреля 2019

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

Наблюдение за ресурсами позволяет вам «прослушивать» изменения в ресурсах и выполнять любые операции, которые вы считаете подходящими.

Реализация также довольно проста. Создайте новый сервис OSGi, который реализует интерфейс ResourceChangeListener, и добавьте некоторые свойства, чтобы отфильтровать, какие изменения вас интересуют. Это похоже на использование событий JCR и задания, но гораздо более простое.

Преимущество этого заключается в том, что это не зависит от любого почтового запроса. недостаток в том, что вам нужно использовать новый сеанс для внесения изменений. (Вы можете использовать ResourceResolverFactory.getServiceResourceResolver)

Например. 

@Component(property = {
    ResourceChangeListener.CHANGES + "=ADDED",
    ResourceChangeListener.PATHS + "=glob:/content/*",
})
public class ResourceObserver implements ResourceChangeListener {

  @Override
  public void onChange(@Nonnull List<ResourceChange> changes) {
      //go through the list of changes and do what you need to do.
  }
}
...