Переопределение Sling DefaultGetServlet.java

Я работаю над сервлетом, чтобы выполнить некоторую логику, специфичную для типа ресурса, в sling и установить информацию для запроса, доступную через jsp, а затем передать запрос в jsp аналогично первому решению, представленному в этот ответ.

Вот пример кода, представляющий мою ситуацию:

@SlingServlet(
  resourceTypes="myapp/components/mycomponent",
  methods="GET",
  extensions={"html"}
)
...
  @Reference
  private ServletResolver serlvetResolver;

  protected void doGet(....) {
    setPropertiesToRequest();
    Servlet servlet = servletResolver.resolveServlet(resource, "....jsp");
    servlet.service(slingRequest, slingResponse);
    clearPropertiesFromRequest();
  }

Из-за этого я заметил, что потерял обработку селектора в sling (мне пришлось свернуть свою собственную более простую версию, чтобы определить, какой jsp отображать. Полнофункциональная обработка селекторов слингов более подробно описана здесь). Я хотел обратиться к сообществу переполнения стека и спросить, что еще я могу упустить, лишив обработчик запроса по умолчанию. Я просмотрел исходный код, но я думаю, что может быть что-то еще.

Во-вторых, мне было бы интересно узнать, как и где этот подход может повлиять на производительность разрешения запроса.

Спасибо, Томас


java servlets aem sling
person Thomas    schedule 18.07.2014    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Обработка бизнес-логики на Java и делегирование скриптам для рендеринга звучит как работа для недавно выпущенного Sling Модели. Использование этого должно устранить необходимость реализации вашей собственной обработки селекторов, поскольку они не повлияют на выбор модели, а только на сценарии рендеринга.

person Bertrand Delacretaz    schedule 18.07.2014
comment
Спасибо за ответ Бертран. Слинговые модели выглядят отличным вариантом. Проблема здесь в том, что мы надеялись централизовать нашу логику, включая конкретные действия компонента с запросом, в java (вместо того, чтобы переходить между различными jsp и пользовательскими тегами, которые мы определяем). Мы не слишком озабочены обработкой селекторов, так как можем повторно реализовать известные требуемые варианты использования. Я упомянул это скорее как пример фичи, которую мы потеряли при таком подходе. Нас беспокоит, не упускаем ли мы что-то еще. Спасибо, Томас - person Thomas; 24.07.2014

arrow_upward
1
arrow_downward

Не уверен, чего вы пытаетесь достичь здесь, но мне кажется, что основная проблема заключается в том, что ваш SlingServlet обрабатывает расширение html и сам по себе не имеет селекторов для дополнительной фильтрации. Таким образом, он, конечно же, перехватывает все запросы к вашему компоненту. Затем вам нужно снова позаботиться о селекторах, чтобы иметь возможность выбрать правильный JSP. Вопрос в том, почему вы используете для этого SlingServlet, если вы все равно выполняете рендеринг с помощью JSP? Разве вы не можете реализовать свою логику в JSP или лучше в bean-компоненте, на который есть ссылка в JSP?

В нашей компании мы используем наш собственный тег, который позаботится об этом, но есть общедоступные платформы, доступные от других партнеров Adobe:

https://github.com/Cognifide/Slice

http://neba.io/index.html

person Thomas    schedule 18.07.2014
comment
Спасибо за ответ, Томас. Мы также использовали тег для создания экземпляра класса Java для компонента. Однако мы устанавливали значения непосредственно в pageContext, а не через модель. Часть этого исследования заключалась в том, чтобы полностью передать контроль над запросом в код Java и извлечь логику из нашего jsp для целей отладки. На данном этапе нас не интересует обработка селекторов, потому что мы удовлетворили наши потребности и теперь имеем прямой контроль над тем, что означают селекторы. Однако мы обеспокоены тем, что нам не хватает других функций, поддерживаемых настройкой по умолчанию. Спасибо, Томас - person Thomas; 18.07.2014
comment
Как я прокомментировал в другом вопросе, который вы связали, возможно, фильтр сервлетов был бы решением для управления запросом, не слишком мешая остальной обработке слинга. - person Thomas; 18.07.2014
comment
Я заметил и заглянул в фильтр. Проблема будет заключаться в том, что для предотвращения запуска фильтра при каждом запросе нам придется поддерживать белый список с помощью регулярного выражения в фильтре. И было бы предпочтительнее держать логику запуска или нет в файле с логикой инициализации, а не отдельно. Если бы мы запускали этот код при каждом запросе, фильтр был бы отличным вариантом. - person Thomas; 24.07.2014