Использование CDI вместо @ManagedBean: UnproxyableResolutionException, потому что суперкласс не имеет конструктора без аргументов

Я пытаюсь использовать CDI для своего приложения JSF / Java EE. У меня следующая иерархия классов:

/**
 * base controller class
 * also contains some final methods and an inner enum class declaration
 */
public abstract class AbstractCrudController<K, E> implements Serializable {
  private Class<E> entityClass;

  public AbstractCrudController(Class<E> entityClass) {
    this.entityClass = entityClass;
  }

  // ...
}


import javax.enterprise.context.SessionScoped;
import javax.inject.Named;

@Named
@SessionScoped
public class CategoryController extends AbstractCrudController<Long, Category> implements Serializable {
  public CategoryController() {
    super(Category.class);
  }
  //...
}

Когда я пытаюсь развернуть приложение на GF 3.1, я получаю следующее исключение CDI / Weld:

SEVERE: исключение при загрузке app: WELD-001435 Бобы с нормальной областью видимости класс com.web.AbstractCrudController не может быть прокси, потому что у него нет конструктор без аргументов. org.jboss.weld.exceptions.UnproxyableResolutionException: WELD-001435 Класс фасоли с нормальным охватом com.web.AbstractCrudController не может быть прокси, потому что у него нет конструктор без аргументов. в org.jboss.weld.util.Proxies.getUnproxyableClassException (Proxies.java:215) в org.jboss.weld.util.Proxies.getUnproxyableTypeException (Proxies.java:166) в org.jboss.weld.util.Proxies.getUnproxyableTypesException (Proxies.java:191) в org.jboss.weld.bootstrap.Validator.validateBean (Validator.java:134) в org.jboss.weld.bootstrap.Validator.validateRIBean (Validator.java:148) в org.jboss.weld.bootstrap.Validator.validateBeans (Validator.java:363) в org.jboss.weld.bootstrap.Validator.validateDeployment (Validator.java:349) в org.jboss.weld.bootstrap.WeldBootstrap.validateBeans (WeldBootstrap.java:416) в org.glassfish.weld.WeldDeployer.event (WeldDeployer.java:178) в org.glassfish.kernel.event.EventsImpl.send (EventsImpl.java:128) в org.glassfish.internal.data.ApplicationInfo.start (ApplicationInfo.java:265) в com.sun.enterprise.v3.server.ApplicationLifecycle.deploy (ApplicationLifecycle.java:402) в com.sun.enterprise.v3.server.ApplicationLifecycle.deploy (ApplicationLifecycle.java:221) в org.glassfish.deployment.admin.DeployCommand.execute (DeployCommand.java:351) в com.sun.enterprise.v3.admin.CommandRunnerImpl $ 1.execute (CommandRunnerImpl.java:360) в com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand (CommandRunnerImpl.java:375) в com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand (CommandRunnerImpl.java:1072) в com.sun.enterprise.v3.admin.CommandRunnerImpl.access $ 1200 (CommandRunnerImpl.java:101) в com.sun.enterprise.v3.admin.CommandRunnerImpl $ ExecutionContext.execute (CommandRunnerImpl.java:1221) в com.sun.enterprise.v3.admin.CommandRunnerImpl $ ExecutionContext.execute (CommandRunnerImpl.java:1210) в com.sun.enterprise.v3.admin.AdminAdapter.doCommand (AdminAdapter.java:375) в com.sun.enterprise.v3.admin.AdminAdapter.service (AdminAdapter.java:209) в com.sun.grizzly.tcp.http11.GrizzlyAdapter.service (GrizzlyAdapter.java:166) в com.sun.enterprise.v3.server.HK2Dispatcher.dispath (HK2Dispatcher.java:117) в com.sun.enterprise.v3.services.impl.ContainerMapper.service (ContainerMapper.java:234) в com.sun.grizzly.http.ProcessorTask.invokeAdapter (ProcessorTask.java:824) в com.sun.grizzly.http.ProcessorTask.doProcess (ProcessorTask.java:721) в com.sun.grizzly.http.ProcessorTask.process (ProcessorTask.java:1014) в com.sun.grizzly.http.DefaultProtocolFilter.execute (DefaultProtocolFilter.java:220) в com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter (DefaultProtocolChain.java:135) в com.sun.grizzly.DefaultProtocolChain.execute (DefaultProtocolChain.java:102) в com.sun.grizzly.DefaultProtocolChain.execute (DefaultProtocolChain.java:88) в com.sun.grizzly.http.HttpProtocolChain.execute (HttpProtocolChain.java:76) в com.sun.grizzly.ProtocolChainContextTask.doCall (ProtocolChainContextTask.java:53) в com.sun.grizzly.SelectionKeyContextTask.call (SelectionKeyContextTask.java:57) в com.sun.grizzly.ContextTask.run (ContextTask.java:69) в com.sun.grizzly.util.AbstractThreadPool $ Worker.doWork (AbstractThreadPool.java:530) в com.sun.grizzly.util.AbstractThreadPool $ Worker.run (AbstractThreadPool.java:511) at java.lang.Thread.run (Thread.java:637)

Даже если я добавлю конструктор без аргументов к базовому классу, Weld по-прежнему жалуется с тем же исключением, что класс не может быть прокси-сервером, потому что у него есть методы final . Почему WELD вынуждает меня изменить дизайн моего класса? Все работало нормально, используя аннотацию JSF @ManagedBean.

Буду признателен за любую помощь. Спасибо, Тео