Клиент (Tomcat) вызывает компонент сеанса без состояния (JBoss), как обрабатывать идентификатор клиента - PullRequest
Новая
       25

Клиент (Tomcat) вызывает компонент сеанса без состояния (JBoss), как обрабатывать идентификатор клиента

0 голосов
/ 20 июня 2011

у нас есть следующие настройки:

  • Tomcat (веб-приложение) вызывает службу (Session Bean без сохранения состояния) в EAP JBoss 5.1.0 (EJB 3.0)
  • JBoss имеет два разных контекста персистентности, определенных с использованием двух разных баз данных
  • Службе JBoss необходимо знать, какой клиент вызвал ее службу, что-то вроде идентификатора (многопользовательский режим?)

мы могли бы изменить все методы обслуживания на стороне Jboss, чтобы принимать идентификатор клиента в качестве параметра. тогда нам нужно будет изменить каждый возможный вызов метода внутри службы, чтобы транспортировать этот идентификатор, что для меня кажется слишком сложным.

Сначала я подумал о чем-то похожем на переменную ThreadLocal ... что, по-моему, запрещено в мире Java EE.

Вам, ребята, известно какое-нибудь элегантное решение "транспортировки" идентификатора клиента? Я думаю, что JAAS делает нечто похожее, с помощью которого каждый вызов из «внешнего» мира фильтруется, и учетные данные пользователя применяются к каждому вызову. как только вызов входит в «мир обслуживания Jboss», все последующие вызовы методов имеют идентификацию вызывающего.

Я хочу, чтобы мое приложение было настолько «независимым от клиента», насколько возможно, оно должно просто получать правильную конфигурацию, «внедренную» (например, контекст постоянства), в зависимости от того, какой клиент вызвал службу. логика будет та же самая, просто разные ресурсы, которые она использует (какая-то архитектура перехватчиков).

Я немного растерялся. любая помощь высоко ценится.

веселит Marcel

1 Ответ

0 голосов
/ 21 июня 2011

С помощью перехватчика @AroundInvoke вы должны иметь возможность обнаруживать веб-сервисы, проверяя содержимое InvocationContext.getContextData (), которое используется совместно с контекстом веб-сервиса согласно спецификации JAX-WS. Вам все равно придется распространять его внутри.

ThreadLocal в Java EE не обязательно является плохим, если вы помните, чтобы убирать за собой: 

tl.set(something);
try {
  deepMethodCallHierarchy();
} finally {
  tl.remove();
}

(Конечно, явная передача контекста, вероятно, является самой чистой.)

...