Нарушает ли следующий код 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 может быть альтернативой моей проблеме, но это слишком тяжело для моего вкуса.
Вы смотрите на CDI? Кажется, он идеально подходит для того, что вы пытаетесь достичь (производители, инъекции в конструкторах и т. Д.). – BalusC
Я думаю, что это сработало бы, но в настоящее время я не могу представить CDI из-за ограничений проекта. – saimonsez