Поиск для подкласса EJB по имени EJB суперкласса - PullRequest
Новая
       104

Поиск для подкласса EJB по имени EJB суперкласса

0 голосов
/ 30 апреля 2018

У меня есть родитель и ребенок EJB 

@Stateless
@Local(MyCoreLocal.class)
@Remote(MyCore.class)
public class MyCoreEjb implements MyCoreLocal, MyCore {
...
}
@Stateless
@Local(MyCustomizationLocal.class)
@Remote(MyCustomization.class)
public class MyCustomizationEjb extends MyCoreEjb implements MyCustomizationLocal, MyCustomization{
...
}

по архитектурным причинам в моей компании, я не могу изменить проект MyCore. Но оба они упакованы в одну банку и развернуты на JBOSS 4.2.3.

Проблема в том, что я должен использовать MyCustomizationEjb всякий раз, когда кто-то вызывает MyCoreEjb. Как я могу переопределить запись JNDI для MyCoreEjb, чтобы она указала на MyCustomizationEjb, чтобы прозрачно перенаправить все вызовы для MyCoreEjb на MyCustomizationEjb?

ps: у меня есть полный контроль над ejb-jar.xml проекта, но я не могу изменять аннотации.

1 Ответ

0 голосов
/ 02 мая 2018

Я выяснил, как я мог бы преодолеть проблему. В действительности мне не нужно было перенаправлять все вызовы для MyCustomizationEjb. Мне это нужно было только для определенного метода (в настоящее время).

Таким образом, мое решение состояло в том, чтобы создать метод-перехватчик для конкретного метода, который я хотел, и просто «перенаправить» выполнение на MyCustomizationEjb следующим образом: 

public class SpecificMethodInterceptor{

@EJB
MyCustomization myCustomization;

@AroundInvoke
public Object intercept(InvocationContext ctx) throws Exception {

    Object result = myCustomization.specificMethod((Param1Type)ctx.getParameters()[0], (Param2Type) ctx.getParameters()[1]);
    return result;
}

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

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

Примечание: Нет проблем с тем, чтобы не продолжать выполнение (с помощью ctx.proceed ()), потому что этот Interceptor является последним вызванным до того, как выполнение достигает EJB. Единственный путь, по которому это может пойти не так, это если кто-то сделает перехватчик метода на EJB , который будет пропущен при выполнении. Но это не проблема в этом конкретном проекте.

...