2016-01-19 4 views
3

Нарушает ли следующий код EJB 3 следующий код? Если да, то что я могу сделать, чтобы сохранить желаемую функциональность?Создание экземпляра класса внутри EJB

Причина, почему я спрашиваю, что IntelliJ 14 производит эти предупреждения:

  • Использование «java.lang.reflect.Constructor» не допускается в EJB
  • Использование «java.lang .reflect.InvocationTargetException»не допускается в EJB

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

@Stateless 
public class MyBean { 
    public SomeInterface createSomeClass(final Class<? extends AbstractSomeClass> someClass, final MyArgument argument) { 
     try { 
      final Constructor constructor = someClass.getDeclaredConstructor(argument.getClass()); 
      constructor.setAccessible(true); 
      return (SomeInterface) constructor.newInstance(state); 
     } catch (InvocationTargetException | NoSuchMethodException | InstantiationException | IllegalAccessException e) { 
      // TODO fix exception handling 
      throw new RuntimeException(e); 
     } 
    } 
} 

Благодарим за помощь.

С уважением,

Simon

Редактировать

Мне кажется, что есть раздел в спецификации EJB 3, который отвечает на первую часть моего вопроса:

Компонент предприятия не должен пытаться запрашивать класс для получения информации об объявленных членах, которые в противном случае доступ к корпоративному компоненту не был бы доступен из-за правил безопасности языка Java. Компонент предприятия не должен пытаться использовать API Reflection для доступа к информации о том, что правила безопасности на языке программирования Java недоступны.

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

+0

Вы смотрите на CDI? Кажется, он идеально подходит для того, что вы пытаетесь достичь (производители, инъекции в конструкторах и т. Д.). – BalusC

+0

Я думаю, что это сработало бы, но в настоящее время я не могу представить CDI из-за ограничений проекта. – saimonsez

ответ

2

Этот абзац - это действительно просто перевыполнение минимальной политики безопасности Java 2 для EJB (раздел 16.3 спецификации EJB 3.2). Спецификация не гарантирует, что ваш EJB будет иметь разрешение делать то, что он делает. Если у вас нет безопасности Java 2 на вашем сервере приложений или вы предоставили разрешение EJB для этого, тогда вам все будет в порядке. (. Конечно, нормальные предостережения для проверки/изменений состояния объектов вы не владеете еще применяется)

Если вы хотите, чтобы избежать предупреждений в любом случае, то альтернатива может быть создание интерфейса фабрики:

interface AbstractSomeClassFactory<T> { T create(MyArgument a); } 

... и передать это вместо EJB. У меня нет других замечательных идей.

+0

Очень полезно, спасибо. Конечно, фабрика не обязательно должна быть EJB! – saimonsez

Смежные вопросы