EJB 3: доступ к сессионному компоненту с сохранением состояния из клиента приложения - PullRequest
Новая
       52

EJB 3: доступ к сессионному компоненту с сохранением состояния из клиента приложения

5 голосов
/ 13 мая 2009

У меня возникли проблемы с доступом к сессионному компоненту с состоянием (SFSB) из клиента приложения. Я использую JBoss 5.0.1.GA. Клиент приложения и EJB упакованы в EAR, который развертывается, и у меня есть другие клиенты приложений, которые работают без проблем. До сих пор я использовал только сессионные компоненты без состояния (SLSB), но, насколько я понимаю, различия между SLSB и SFSB не должны влиять на то, как к ним можно получить доступ из клиента приложения.

Структура классов / интерфейсов: 

@Local public interface A {...}

@Stateless public class ABean implements A {...}

@Remote public interface B {...}

@Stateful public class BBean implements B {
    @EJB private A anInstanceOfA;

    @PostConstruct private void init() {
        this.anInstanceOfA.someMethod();
    }
}

Клиент приложения запускается через "appclient-launcher", как описано в "Как использовать клиент приложения в JBoss 5" . Выполнение поиска «BBean» работает нормально до тех пор, пока someMethod () на (локальном) ABean не будет вызван во время выполнения init (). Во время этого вызова контейнер генерирует исключение InvalidStateException («Локальный вызов: контекст безопасности имеет значение null») (как основная причина). Когда я заменяю bean-компонент с состоянием на bean-компонент без состояния, все работает нормально (за исключением, конечно, что состояние не сохраняется). Интересно, что я могу использовать точно такую ​​же SFSB из веб-приложения (в управляемом компоненте JSF).

Я что-то не так делаю? Как я должен использовать SFSB из клиента приложения?

Пока что я не нашел ничего полезного в этой конкретной проблеме. Исключение упоминается в аналогичном контексте в [# JBAS-4317] Контекст безопасности над вызовом , но, учитывая, что оно помечено как выполненное и исправлено в JBoss 5.0.0.Beta3, кажется, что оно не быть той же проблемой.

Ответы [ 2 ]

1 голос
/ 14 мая 2009

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

Веб-приложение, которое также упаковано в EAR, выполняет свою аутентификацию через JAAS. Для этого я настроил домен безопасности в JBoss login-config.xml, который выглядит следующим образом: 

<application-policy name="My-SD">
    <authentication>
        <login-module code="org.jboss.security.auth.spi.DatabaseServerLoginModule" flag="required">
            <module-option name="unauthenticatedIdentity">guest</module-option>
            <module-option name="dsJndiName">java:/myDS</module-option>
            <module-option name="principalsQuery">SELECT PASSWORD FROM LOGIN WHERE LOGIN = ? AND STATUS > 0</module-option>
            <module-option name="rolesQuery">SELECT ROLE, 'Roles' FROM USER_ROLE WHERE LOGIN = ?</module-option>
        </login-module>
    </authentication>
</application-policy>

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

Чтобы решить проблему с доступом к SFSB, мне просто нужно было удалить мой домен безопасности из jboss.xml в EJB-проекте. Это тогда заставляет JBoss использовать домен безопасности по умолчанию, который, кажется, делает правильные вещи, и мой клиент приложения, наконец, может получить доступ и использовать SFSB.

0 голосов
/ 19 июля 2012

Причину можно найти в спецификации ядра EJB 3.0 , раздел 12.4. Там написано

Методы перехватчика обратного вызова жизненного цикла вызываются в неопределенной транзакции и контексте безопасности.

НТН,
- Мартин

...