Duplicate of CDI-224

I think that it is worth to remove the requirement on interface in CDI2.

It should be fairly easy to specify additional scenario, where the decorator can extend the decorated class => it would inherit all public methods as if all methods would be exposed by an interface, and would decorate all beans injected by their class instead of by interface.

Currently, the way to work around this is to declare such decorator using @Specialized + @Alternative and delegating to methods in predecessor. This is confusing in the code, as the decorator pattern is implemented using to other patterns. And it is not the same as delegate to another injected delegate, as multiple decorators cannot be chained:

@Specialized
@Alternative
public class MyBeanDecorator extends MyBean {

  @Overrides
  public String hello() {
     return super.hello() + ", world!";   // decorates by adding ", world!" after result of hello()
  }
}

We have a big product with many subproducts and customizations for customers.
In our core libs, we have many default view controllers beans and JSF cc's/includes..
For some subproducts, we @Specialize the view controllers or even create seperate includes.

e.g.

core -> ViewAController
subprojectA -> SpecializedViewAController

Thats work fine with @Specialized/@Alternative.

We also have shared libs for each customer.
There we would like to decorate e.g. ViewAController.
As our controller are currently classes, it would be perfect if it would be possible to apply decorators also on classes.
Currently we have to introduce (senseless!) interfaces for our view controllers, which is actually only a workaround for this feature request because we don't gain any other benefit from it.

It's really an important issue for product development and it would be great to see it in CDI2/JEE8

Interesting point, but a probably too big for a CDI 1.1 MR.