Странное поведение EJB или я что-то упустил ??? - PullRequest
1 голос
/ 22 января 2012

Вот очень странное поведение при использовании EJB-бинов:

@Local
public interface Provider {
    void test();
}

@Local
public interface ExtProvider extends Provider {
   void test2();
}

public abstract class AbstractProvider implements Provider {
   @Override 
   void test(){ System.out.println("Hello strange " + getTech()); }
   protected abstract String getTech();          
}

public abstract class ExtAbstractProvider extends AbstractProvider implements ExtProvider {
   @Override
   void test2() { System.out.println("Hello from " + getName());}
   @Override
   String getTech() { return "extended EJB";}
   protected abstract String getName();
}
@Stateless
public class ProviderBean extends AbstractProvider {
   @Override
   protected String getTech() { return "EJB";}
}

@Stateless
public class ExtProviderBean extends ExtAbstractProvider {
  @Override
  protected String getName() { return "ext provider";}
}

Согласно приведенному выше коду, если я напишу:

@EJB Provider provider; // should inject an instance of ProviderBean
@EJB ExtProvider extProvider; // should inject an instance of ExtProviderBean

, но ни одно из двух не работает !!!Кто-то скажет, что в этом примере EJB не знает, какой экземпляр создавать каждый раз, поскольку есть два экземпляра, которые реализуют Provider.И странно: это работает, только если мы объявляем два bean-компонента как:

public class ExtProviderBean extends ExtAbstractProvider implements ExtProvider
public class ProviderBean extends AbstractProvider implements Provider

В этом случае код работает.Проблема в том, что мы должны явно определить, что компонент реализации реализует интерфейс, даже если он неявно определен из абстрактной реализации.Я что-то упустил или это ограничение?

1 Ответ

0 голосов
/ 17 февраля 2012

Я только что прочитал этот вопрос SO , и я думаю, что предоставленный ответ также применим к вашему делу.

Я просто цитирую часть ответа и, следовательно, спецификацию EE:

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

@Stateless
public class B extends A implements Bar { ... }

Предполагая, что Foo и Bar являются локальными бизнес-интерфейсами, и нет никакого связанного дескриптора развертывания, сессионный компонент A предоставляет локальный бизнес-интерфейс Foo, а сессионный компонент B предоставляет локальный бизнес-интерфейс Bar, но неFoo. Сессионному компоненту B потребуется явно включить Foo в свой набор открытых представлений для применения этого интерфейса.

...