1 2 Previous Next 15 Replies Latest reply on Nov 21, 2007 4:30 PM by starksm64

    Annotation to metadata status

    starksm64

      I'm down to the just the javax.interceptor.AroundInvoke{METHOD},ExcludeClassInterceptors{METHOD},ExcludeDefaultInterceptors{TYPE, METHOD},Interceptors{TYPE, METHOD} needing processors.

      Beyond that validating the Web25MetaDataCreator and creating a ApplicationClient5MetaDataCreator is needed. This should mostly leverage the existing EnvironmentRefsGroupMetaData related processors.

      How I was thinking of creating a merged view of the spec metadata using a proxy that looked to the deployment MetaData for annotation was not really usable. Instead I just created another AnnotationMergedView utility class that creates the combined view. Its used by the AnnotationEjb3UnitTestCase.testXmlMerge. Just a simple case is being validated currently.

        • 1. Re: Annotation to metadata status
          wolfc

          I think I already spotted some bugs. ;-)
          I'll do some test cases.

          Anil's case is invalid, because BusinessBean does not implement an interface. An empty @Remote is however valid (EJB 3 4.6.6 bullet 5.1).

          • 2. Re: Annotation to metadata status
            wolfc

            I've added MultiviewBean as a nice test case and cleaned up MyStateless21Bean.

            What shall we do with MyStatefulBean? It has grown into a little monster. Do we want an EJB 3 view or an EJB 2.1 view.

            • 3. Re: Annotation to metadata status
              anil.saldhana

               

              "wolfc" wrote:
              I think I already spotted some bugs. ;-)
              I'll do some test cases.

              Anil's case is invalid, because BusinessBean does not implement an interface. An empty @Remote is however valid (EJB 3 4.6.6 bullet 5.1).


              Oh! no. I wrote a BusinessInterface interface and forgot BusinessBean to implement BI. :(

              • 4. Re: Annotation to metadata status
                starksm64

                 

                "wolfc" wrote:
                I've added MultiviewBean as a nice test case and cleaned up MyStateless21Bean.

                What shall we do with MyStatefulBean? It has grown into a little monster. Do we want an EJB 3 view or an EJB 2.1 view.

                What is the issue with MyStatefulBean? Its still only using a fraction of the annotations it could. MyStatelessBean is the one with the larger usage.

                We do need to start segmenting the tests as currently the scan for classes make the check for the number of ejbs in the metadata useless. In general the deployers need to provide the classes so the classes that apply for a given test should just be specified. Could even be an annotation on the testcase method.

                What is the question about a 3/2.1 view?

                • 5. Re: Annotation to metadata status
                  wolfc

                  Bugrit, I forgot to commit the MyStateless21Bean fix.

                  MyStatefulBean is not according to spec. It declares an EJB 2.1 remote home with an EBJ 3 remote business interface, but no EJB 2.1 remote interface. (EJB 3 4.6.1 bullet 2 & 3) So unless we're doing a negative test, this should be cleaned up.

                  I've added the ability to load a sub-package to AnnotationEjb3UnitTestCase.
                  I can move this to the common test package and allow for the following:

                  @ScanPackage("org.jboss.test.metadata.ejb3.annotation.multiview")
                  public void testMultiview() {
                   Collection<Class<?>> classes = PackageScanner.loadClasses();
                   ...
                  }


                  • 6. Re: Annotation to metadata status
                    starksm64

                    The interceptor annotation processors have been added. Can you check the InterceptorsProcessor logic.

                    • 7. Re: Annotation to metadata status
                      starksm64

                       

                      "wolfc" wrote:
                      Bugrit, I forgot to commit the MyStateless21Bean fix.

                      MyStatefulBean is not according to spec. It declares an EJB 2.1 remote home with an EBJ 3 remote business interface, but no EJB 2.1 remote interface. (EJB 3 4.6.1 bullet 2 & 3) So unless we're doing a negative test, this should be cleaned up.

                      Ok, I see. This requires validation of the @Remote target class. Is this something we need to be adding to the processor?

                      "wolfc" wrote:

                      I've added the ability to load a sub-package to AnnotationEjb3UnitTestCase.
                      I can move this to the common test package and allow for the following:
                      @ScanPackage("org.jboss.test.metadata.ejb3.annotation.multiview")
                      public void testMultiview() {
                       Collection<Class<?>> classes = PackageScanner.loadClasses();
                       ...
                      }

                      Looks good.


                      • 8. Re: Annotation to metadata status
                        starksm64

                        Note that I changed the InterceptorBindingsMetaData from a map to a list because the ejb-name although required, is not unique. I removed the bean specific accessors as well. It did not seem as though were in use by the ejb3 codebase, but if they are the next snapshot update will require some changes.

                        • 9. Re: Annotation to metadata status
                          wolfc

                           

                          "scott.stark@jboss.org" wrote:
                          Ok, I see. This requires validation of the @Remote target class. Is this something we need to be adding to the processor?

                          I may have made an error somewhere, I need to reconsider the EJB 2.1 view.
                          http://www.jboss.com/index.html?module=bb&op=viewtopic&t=124195
                          "scott.stark@jboss.org" wrote:
                          Looks good.

                          Okay, will do.

                          • 10. Re: Annotation to metadata status
                            starksm64

                            I'm seeing this command line compile error that I don't see in eclipse:

                            [INFO] ------------------------------------------------------------------------
                            [INFO] Compilation failure
                            
                            /home/svn/JBossHead/projects/metadata/trunk/src/test/java/org/jboss/test/metadata/ejb/JBoss50UnitTestCase.java:[32,26] [deprecation] org.jboss.metadata.ApplicationMetaData in org.jboss.metadata has been deprecated
                            
                            ...
                            
                            /home/svn/JBossHead/projects/metadata/trunk/src/test/java/org/jboss/test/metadata/annotation/ejb3/AnnotationEjb3UnitTestCase.java:[533,80] inconvertible types
                            found : java.util.Collection<java.lang.Class<?>>
                            required: java.util.Collection<java.lang.Class>
                            


                            Eclipse must be less strict in its type cast checking. As a side question, why are there still deprecation warnings on the command line when the AbstractJavaEEEverythingTest has a class level @SuppressWarnings("deprecation")?

                            @SuppressWarnings("deprecation")
                            public abstract class AbstractEJBEverythingTest extends AbstractJavaEEEverythingTest
                            {
                            



                            • 11. Re: Annotation to metadata status
                              wolfc

                              I fixed the compiler error.

                              It still is weird that a Collection<Class> is not a Collection<Class<?>>, while Class is a Class<?>.


                              • 12. Re: Annotation to metadata status
                                starksm64

                                See the dev list discussion around this class wildcard issue. If you take

                                Collection<Class<?>>
                                to mean a collection of a specific, although unknown type of class, this is the wrong type to be using in the creator codebase. We need a heterogeneous collection of classes of many types.


                                • 13. Re: Annotation to metadata status
                                  wolfc

                                   

                                  "scott.stark@jboss.org" wrote:
                                  See the dev list discussion around this class wildcard issue. If you take
                                  Collection<Class<?>>
                                  to mean a collection of a specific, although unknown type of class, this is the wrong type to be using in the creator codebase. We need a heterogeneous collection of classes of many types.

                                  Hmm, interesting view. What was the topic of that thread?
                                  I think a collection of a specific, although unknown type of class is specified so:
                                  <T> void myMethod() {
                                   Collection<Class<T>> collection;
                                  }


                                  • 14. Re: Annotation to metadata status
                                    wolfc

                                    Just try the following:

                                    Collection<Class<? extends Collection>> c1 = new ArrayList<Class<? extends Collection>>();
                                    c1.add(ArrayList.class);
                                    c1.add(Collection.class);
                                    c1.add(String.class);

                                    add(java.lang.Class<? extends java.util.Collection>) in java.util.Collection<java.lang.Class<? extends java.util.Collection>> cannot be applied to (java.lang.Class<java.lang.String>)
                                     c1.add(String.class);
                                     ^
                                    1 error

                                    As expected.

                                    And then:
                                    Collection<Class<?>> c1 = new ArrayList<Class<?>>();
                                    c1.add(ArrayList.class);
                                    c1.add(Collection.class);
                                    c1.add(String.class);

                                    The collection of classes of many types.

                                    1 2 Previous Next