7 Replies Latest reply on Mar 31, 2012 2:50 PM by alesj

    Unproxyable class: superclasses also need no-arg constructor?

    rcd

      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?

        • 1. Re: Unproxyable class: superclasses also need no-arg constructor?
          alesj

          I guess it considers X a bean as well.

          Try vetoing the X bean.

          • 2. Re: Unproxyable class: superclasses also need no-arg constructor?
            rcd

            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.as.weld.services.WeldService.start(WeldService.java:83)

                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

                at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:111)

                at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:127)

                at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:346)

                at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:331)

                at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:366)

                at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:83)

                at org.jboss.as.weld.services.WeldService.start(WeldService.java:76)

                ... 5 more

            • 3. Re: Unproxyable class: superclasses also need no-arg constructor?
              alesj

              What exactly did you try? As NPE is always a bug.

               

              For the veto, either you use Extension and veto the X explicitly,

              or you use JBoss Solder which has this impled under @Veto.

              • 4. Re: Unproxyable class: superclasses also need no-arg constructor?
                rcd

                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...

                • 5. Re: Unproxyable class: superclasses also need no-arg constructor?
                  alesj

                  Is there a way you could provide us with an Arquillian test case for both things?

                  • 6. Re: Unproxyable class: superclasses also need no-arg constructor?
                    rcd

                    I should be able to make some simple test cases that expose the problems. Should I just upload them here?

                    • 7. Re: Unproxyable class: superclasses also need no-arg constructor?
                      alesj

                      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.