11 Replies Latest reply on Dec 5, 2007 8:05 AM by wolfc

    Empty @Remote on bean class

    starksm64

      The following exception is showing up in cts tests. How should this be resolved?

      Caused by: java.lang.IllegalArgumentException: Empty @Remote on bean class com.sun.ts.tests.ejb30.common.equals.TestBean is not allowed
       at org.jboss.metadata.annotation.creator.ejb.RemoteProcessor.process(RemoteProcessor.java:72)
       at org.jboss.metadata.annotation.creator.ejb.RemoteProcessor.process(RemoteProcessor.java:40)
       at org.jboss.metadata.annotation.creator.AbstractComponentProcessor.processClass(AbstractComponentProcessor.java:240)
       at org.jboss.metadata.annotation.creator.AbstractComponentProcessor.processClass(AbstractComponentProcessor.java:208)
       at org.jboss.metadata.annotation.creator.ejb.AbstractEnterpriseBeanProcessor.process(AbstractEnterpriseBeanProcessor.java:98)
       at org.jboss.metadata.annotation.creator.ejb.AbstractEnterpriseBeanProcessor.process(AbstractEnterpriseBeanProcessor.java:50)
       at org.jboss.metadata.annotation.creator.ejb.EjbJar30Creator.create(EjbJar30Creator.java:68)
       at org.jboss.deployment.AnnotationMetaDataDeployer.processJBossMetaData(AnnotationMetaDataDeployer.java:182)
       at org.jboss.deployment.AnnotationMetaDataDeployer.deploy(AnnotationMetaDataDeployer.java:153)
       at org.jboss.deployment.AnnotationMetaDataDeployer.deploy(AnnotationMetaDataDeployer.java:78)
       at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:169)
       ... 64 more
      



        • 1. Re: Empty @Remote on bean class
          alrubinger

          I've taken the related JIRA issue, JBCTS-719, and will make a corresponding issue to address the same problem in the EJB3 Testsuite.

          "EJB3 Core Specification 4.6.6 Bullet 5.6" wrote:
          If bean class implements a single interface, that interface is assumed to be the business interface of the bean. This business interface will be a local interface unless the interface is designated as a remote business interface by use of the Remote annotation on the bean class or interface or by means of the deployment descriptor.


          I believe the code's in place in EJB3 Core to handle this case; we recently had a problem where the default business interface could not be determined due to duplicate occurances of the same interface ( http://jira.jboss.com/jira/browse/EJBTHREE-1124 ). Error there was:

          java.lang.RuntimeException: Use of empty @Remote on bean test-bean-for-stateful with more than one default interface [interface com.whatever.Interface1, interface com.whatever.Interface1] at org.jboss.ejb3.ProxyFactoryHelper.getRemoteAndBusinessRemoteInterfaces(ProxyFactoryHelper.java:591)


          I've not yet seen this error from the annotation processor. Will post back if I can duplicate in EJB3 Unit Tests.

          S,
          ALR

          • 2. Re: Empty @Remote on bean class
            alrubinger

            I'll need some more background on how the CTS test deployments differ from those in the EJB3 testsuite.

            "Metadata trunk, RemoteProcessor Line 71" wrote:
            if(remote.value() == null || remote.value().length == 0)
            throw new IllegalArgumentException("Empty @Remote on bean class " + type.getName() + " is not allowed");


            ...seems to violate EJB3 4.6.6 Bullet 5.6; this doesn't make for an invalid annotation if one business interface is defined by the bean class.

            However, when I make the same case in EJB3 (Empty @Remote with one business interface implemented by the bean class), deployment succeeds; the above code is not even hit.

            Why does the CTS code run through the RemoteProcessor where the EJB3 testsuite does not?

            S,
            ALR



            • 3. Re: Empty @Remote on bean class
              alrubinger

              Oh, if I comment out the lines quoted, the test succeeds.

              S,
              ALR

              • 4. Re: Empty @Remote on bean class
                starksm64

                 

                "ALRubinger" wrote:

                However, when I make the same case in EJB3 (Empty @Remote with one business interface implemented by the bean class), deployment succeeds; the above code is not even hit.

                Why does the CTS code run through the RemoteProcessor where the EJB3 testsuite does not?

                The stateless_equals_annotated.ear has been attached to the case. What is the ejb3 test?


                • 5. Re: Empty @Remote on bean class
                  alrubinger

                  http://jira.jboss.com/jira/browse/EJBTHREE-1146

                  Just committed the test case, which passes. Been running through the TCK locally, which fails exactly as reported.

                  S,
                  ALR

                  • 6. Re: Empty @Remote on bean class
                    alrubinger

                     

                    "ALRubinger" wrote:
                    Oh, if I comment out the lines quoted, the test succeeds.


                    To clarify this, the *TCK* test succeeds when I comment out the lines posted from RemoteProcessor.

                    S,
                    ALR

                    • 7. Re: Empty @Remote on bean class
                      starksm64

                      If we can't unconditionally make that assertion, it should not be in the RemoteProcessor code. I want to understand why this is not being hit in the current ejb3 test though.

                      • 8. Re: Empty @Remote on bean class
                        alrubinger

                        Agreed on all points.

                        We have code within EJB3 ProxyFactoryHelper that checks to ensure @Remote, @RemoteHome, etc data is all defined properly and is complete for either 3.0 or 2.1 views (or both); the RemoteProcessor has logic that violates the spec as it stands.

                        I can remove these lines, but we'll have to do another release (if we haven't already) of the metadata project. You were tagging releases off trunk? Let me know if you'd like for me to handle this.

                        Also bothers me that we're not seeing this in the EJB3 Test; it's a dead simple case.

                        S,
                        ALR

                        • 9. Re: Empty @Remote on bean class
                          starksm64

                          I have been waiting to do a release on this issue. I have at least one change so I'll do the release.

                          • 10. Re: Empty @Remote on bean class
                            starksm64

                            The AnnotationMetaDataDeployer was assuming metadata complete unless there was a jboss metadata that was not marked as complete. Because there was no jboss.xml/ejb-jar.xml the ejb3 test is not being processed.

                            [starksm@succubus ejb3]$ jar -tf output/test-lib/ejbthree1146.jar
                            org/jboss/ejb3/test/ejbthree1146/TestBean.class
                            org/jboss/ejb3/test/ejbthree1146/TestBeanBase.class
                            org/jboss/ejb3/test/ejbthree1146/TestRemoteBusinessInterface.class
                            


                            I added a metaDataCompleteIsDefault property to the AnnotationMetaDataDeployer so that you can set that to false to have a deployment without a JBossMetaData instance to be processed.

                             <bean name="AnnotationMetaDataDeployer"
                             class="org.jboss.deployment.AnnotationMetaDataDeployer">
                             <property name="metaDataCompleteIsDefault">false</property>
                             </bean>
                            



                            • 11. Re: Empty @Remote on bean class
                              wolfc

                              We're not done with metadata on this subject.

                              An @Remote defines a business remote interface, not an EJB 2.1 remote interface.

                              We need to update metadata to comply completely with EJB 3 and EJB 2.1 views.