JNDI / Проблема Classpath у стеклянной рыбы - PullRequest
Новая
       15

JNDI / Проблема Classpath у стеклянной рыбы

1 голос
/ 06 мая 2010

Я нахожусь в процессе преобразования большого J2EE-приложения (называемого AeApp ниже) из EJB 2 в EJB 3 (все сессионные компоненты без сохранения состояния, используя glassfish 2.1.1), и у меня заканчиваются идеи.

Первый преобразованный мной EJB (назовем его Foo) работал без особых проблем (он был единственным в его ejb-модуле, и я мог полностью заменить дескриптор развертывания аннотациями), и приложение работало нормально. Но после преобразования второго (назовем его Bar, один из нескольких в другом ejb-модуле) возникает странная комбинация проблем:

  • AeApp разворачивается без ошибок (в логах тоже ничего). В журнале я получаю сообщения об инициализации для Foo и Bar, но дополнительные сообщения о разрешениях метода и имени JNDI только для Foo: 

    [#|2010-05-10T12:26:13.234+0200|FINE|sun-appserver2.1|javax.enterprise.system.core.security|_ThreadID=25;_ThreadName=Thread-2821;ClassName=com.sun.enterprise.security.application.EJBSecurityManager;MethodName=initialize;_RequestID=1801c4ff-90fe-4406-aaac-219c669be8c1;|Codebase (module id for ejb Foo) = null|#]
[#|2010-05-10T12:26:11.625+0200|FINE|sun-appserver2.1|javax.enterprise.system.core.security|_ThreadID=25;_ThreadName=Thread-2821;ClassName=com.sun.enterprise.security.application.EJBSecurityManager;MethodName=initialize;_RequestID=1801c4ff-90fe-4406-aaac-219c669be8c1;|Codebase (module id for ejb Bar) = null|#]
[#|2010-05-10T12:26:13.234+0200|FINE|sun-appserver2.1|javax.enterprise.system.core.security|_ThreadID=25;_ThreadName=Thread-2821;ClassName=com.sun.enterprise.security.application.EJBSecurityManager;MethodName=fooMethod;_RequestID=1801c4ff-90fe-4406-aaac-219c669be8c1;|JACC DD conversion: EJBMethodPermission ->(Foo fooMethod,Remote,java.lang.Long,java.util.Locale)protected by role -> FOOUSER|#]
[#|2010-05-10T12:26:19.312+0200|INFO|sun-appserver2.1|javax.enterprise.system.container.ejb|_ThreadID=17;_ThreadName=httpWorkerThread-14848-1;|**RemoteBusinessJndiName: com.example.Foo; remoteBusIntf: com.example.Foo|#]

  • Ошибка при поиске бара через JNDI

  • При просмотре дерева JNDI в консоли администратора Glassfish, Бар вообще не отображается.
  • Появляются другие EJB-модули в том же модуле, как и Foo.
  • В логах есть исключения, касающиеся Foo, но они уже появились, когда он все еще работал.

Есть идеи, что может вызвать это или как его диагностировать? Бобы довольно просты: 

@Stateless(name = "Foo")
@RolesAllowed("FOOUSER")
@TransactionAttribute(TransactionAttributeType.SUPPORTS)
public class FooImpl extends BaseBean implements Foo {

У меня также есть некоторые проблемы с дескриптором развертывания для Bar: я хотел бы устранить его, но Glassfish, похоже, не нравится, когда бин появляется только в файле sun-ejb-jar.xml или имеет некоторые bean-компоненты в модуле, объявленном в дескрипторе, а другие используют только аннотации.

Редактировать: Структура EAR выглядит следующим образом: 

AeApp.ear
    AeApp.war
    Foo.jar (Foo.class and FooImpl.class present here)
    Bar.jar (Bar.class and BarImpl.class present here, also BaseBean.class)
    (some more EJB module JARs)
    (lots of library JARs)

AeApp.ear не имеет (и AFAIK никогда не имел, даже когда он работал) META-INF / MANIFEST.MF. Его application.xml выглядит так: 

<application>
  <description>AE EAR</description>
  <display-name>AE EAR</display-name>
  <module><ejb>Foo.jar</ejb></module>
  <module><ejb>Bar.jar</ejb></module>
  <module><ejb>Baz.jar</ejb></module>
  <module><ejb>Doh.jar</ejb></module>
  <module><web>
      <web-uri>AeApp.war</web-uri>
      <context-root>/</context-root>
  </web></module>
</application>

Ответы [ 2 ]

2 голосов
/ 10 мая 2010

После некоторых проб и ошибок я сузил проблему, и коллега привел меня на правильный путь. Проблема была не в классовых путях или самих EJB. Это было намного тупее.

У моего ejb-jar.xml был DOCTYPE EJBv2. Это заставило Glassfish молча игнорировать EJB-компоненты с использованием только аннотаций и не помещать их в дерево JNDI, когда они были объявлены в дескрипторе развертывания. Все, что мне нужно было сделать, это заменить это: 

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN" "http://java.sun.com/dtd/ejb-jar_2_0.dtd">
     <ejb-jar>

С этим: 

<?xml version="1.0" encoding="UTF-8"?>
     <ejb-jar xmlns="http://java.sun.com/xml/ns/javaee" 
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="3.0" 
              xsi:schemaLocation="http://java.sun.com/xml/ns/javaee 
                                  http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd">
1 голос
/ 09 мая 2010

Я не видел точных сообщений об ошибках, которые вы публиковали ранее, но они выглядят так, словно в атрибуте бара META-INF / MANIFEST.MF Class-Path отсутствует "foo-ejb.jar". Можно скомпилировать bar с помощью других средств, чтобы поместить Foo в путь к классам, но это не сработает при запуске приложения.

Но я согласен с Паскалем, нам действительно может понадобиться больше информации о структуре вашего проекта. Действительно краткое описание (или, может быть, диаграмма) о том, какие у вас есть jar-файлы, какие из соответствующих классов (Foo / Bar / FooImpl / BaseBean / ..) в каком jar-файле, как они связаны + их аннотаций, вероятно, будет достаточно.

...