I'm getting this exception, slightly anonymized:
org.jboss.weld.exceptions.UnproxyableResolutionException: WELD-001435 Normal scoped bean class X is not proxyable because it has no no-args constructor - Managed Bean [class Y] with qualifiers [@Any @Default].
Class Y is under my control, and it extends class X, which I can't modify. I can understand why Weld requires class Y to have a no-arg constructor, and I've provided one accordingly. But why does class X, which class Y extends, need a no-arg constructor?
I've looked around, but nobody seems to have a solution to this problem. The closest I've come to finding one is this forum thread from last year, where someone else had the exact same problem, but there are no helpful replies. I've also looked at the Weld docs and tried the suggestions listed there for fixing the problem, none of which work. Any ideas?
How do I veto X? Using @Typed to specify what I want proxied? Just tried that and I get this:
10:54:49,969 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC00001: Failed to start service jboss.deployment.unit."NMSS.ear".WeldService: org.jboss.msc.service.StartException in service jboss.deployment.unit."NMSS.ear".WeldService: java.lang.NullPointerException
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [rt.jar:1.7.0_02]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [rt.jar:1.7.0_02]
at java.lang.Thread.run(Unknown Source) [rt.jar:1.7.0_02]
Caused by: java.lang.NullPointerException
... 5 more
When I got the NPE, the only thing I did differently was that I annotated the class with @Typed(Y.class) so that class X would not be a bean type.
@Veto does not help because, again, I don't control class X. Similarly, I don't see how Extension helps either.
I have managed to create a workaround that's good enough for this case by injecting a factory that can be used to obtain a new instance of Y instead of injecting Y directly. This works in my case because scope is irrelevant for this object, but I would still like to know why this problem exists in the first place...
I should be able to make some simple test cases that expose the problems. Should I just upload them here?
No, if possible. :-)
What we do now is create an Arquillian test against our Weld Core project - https://github.com/weld/core, tests-arquillian/ directory,
commit, and then do a pull-request in github. It's saves everyone a ton of time.