[
https://issues.apache.org/jira/browse/OWB-873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13682836#comment-13682836
]
Christian Schlichtherle commented on OWB-873:
---------------------------------------------
Ok, I've read section 3.15 of CDI 1.1 now (had just read CDI 1.0 spec so far).
Conceptually, I still don't understand why a managed bean class with the
default @Dependent scope needs to be proxy-able in order to be decoratable,
too. To me, this appears to be too constrained.
{rant}
I think CDI is relying too much on Proxies. Consider Guice for comparison: If
you want to put a narrower-scoped object into a wider-scoped object, then you
have to use a javax.inject.Provider or com.google.inject.Provider. This is a
simple, straightforward requirement which results in easily comprehensible,
fast code (because no reflection is required). In contrast, CDI is plagued with
a lot of special rules a'la "If it's friday and raining outside, then you have
to comply to the following constraint (but only if your managed bean class is
proxy-able!): ...". +1 for Guice if you ask me.
{rant}
Anyway, I accept that I need to have a non-private constructor with no
parameters if I want my managed bean class to get decorated, too.
> NoSuchMethodException if no constructor with an empty parameter list is
> present AND the bean has @Decorator beans
> -----------------------------------------------------------------------------------------------------------------
>
> Key: OWB-873
> URL: https://issues.apache.org/jira/browse/OWB-873
> Project: OpenWebBeans
> Issue Type: Bug
> Components: Core, Interceptor and Decorators
> Affects Versions: 1.2.0
> Reporter: Christian Schlichtherle
> Attachments: mavenproject1.zip
>
>
> In my test project, I have a {{StandardPrinter}} bean which takes a
> {{PrintStream}} as its sole constructor parameter. The bean archive
> descriptor also configures three {{@Decorator}} classes which decorate the
> output of the {{StandardPrinter}} bean.
> Now, as a side effect of the decorator configuration, the container requires
> an empty-parameter list constructor for the {{StandardPrinter}} class,
> although this constructor is never actually called.
> To reproduce the issue, build and run the attached standalone project. When
> run unchanged, the program succeeds and prints the decorated output:
> {code}
> ---------- BEGIN PRINT ----------
> Hello world!
> ---------- END PRINT ----------
> {code}
> However, after removing the constructor {{ private StandardPrinter.<init>() {
> ... } }}, I get the following exception when running the program:
> {code}
> Exception in thread "main"
> org.apache.webbeans.proxy.ProxyGenerationException:
> java.lang.NoSuchMethodException:
> com.company.mavenproject1.StandardPrinter.<init>()
> at
> org.apache.webbeans.proxy.InterceptorDecoratorProxyFactory.createConstructor(InterceptorDecoratorProxyFactory.java:288)
> at
> org.apache.webbeans.proxy.AbstractProxyFactory.generateProxy(AbstractProxyFactory.java:211)
> at
> org.apache.webbeans.proxy.AbstractProxyFactory.createProxyClass(AbstractProxyFactory.java:175)
> at
> org.apache.webbeans.proxy.InterceptorDecoratorProxyFactory.createProxyClass(InterceptorDecoratorProxyFactory.java:186)
> at
> org.apache.webbeans.component.InjectionTargetBean.defineBeanInterceptorStack(InjectionTargetBean.java:172)
> at
> org.apache.webbeans.config.BeansDeployer.validate(BeansDeployer.java:426)
> at
> org.apache.webbeans.config.BeansDeployer.validateInjectionPoints(BeansDeployer.java:392)
> at
> org.apache.webbeans.config.BeansDeployer.deploy(BeansDeployer.java:195)
> at
> org.apache.webbeans.lifecycle.AbstractLifeCycle.startApplication(AbstractLifeCycle.java:129)
> at
> com.company.mavenproject1.boot.BootWebBeans.startApplication(BootWebBeans.java:36)
> at com.company.mavenproject1.boot.BootWebBeans.run(BootWebBeans.java:27)
> at
> com.company.mavenproject1.boot.BootWebBeans.main(BootWebBeans.java:22)
> Caused by: java.lang.NoSuchMethodException:
> com.company.mavenproject1.StandardPrinter.<init>()
> at java.lang.Class.getConstructor0(Class.java:2715)
> at java.lang.Class.getDeclaredConstructor(Class.java:1987)
> at
> org.apache.webbeans.proxy.InterceptorDecoratorProxyFactory.createConstructor(InterceptorDecoratorProxyFactory.java:266)
> ... 11 more
> {code}
> As you can see from the constructor code, it's never actually called because
> it would throw a {{new AssertionError()}}.
> For comparison, I get similar results from Weld, the RI implementation,
> except that Weld actually calls the constructor (it uses Class.newInstance()
> to instantiate it).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
