7 Replies Latest reply on Jul 24, 2007 8:09 AM by Ales Justin

    Annotation features

    Ales Justin Master

      Since there is a really increasing demand for annotation usage with MC configuration, I think we should _finally_ provide a generic MC beans annotations handling.

      There are already some annotations present, but I think their lookup is scattered all over the place.

      I also went through some old posts which just touch on the topic of annotations:
      http://www.jboss.org/index.html?module=bb&op=viewtopic&t=89400
      http://www.jboss.org/index.html?module=bb&op=viewtopic&t=88620&postdays=0&postorder=asc&start=0
      http://www.jboss.org/index.html?module=bb&op=viewtopic&t=88613&postdays=0&postorder=asc&start=0

      There are some pointers to use the ClassInfo/BeanInfo:


      The inspection should come from "reflection abstraction"
      in the container module which is integrated via the
      Configurator/BeanInfo.


      But is looks like this is not yet fully implemented:

      Which AFAIK, (Kabir may know better) isn't properly integrated
      except when AOP is used. i.e. The Bean/ClassInfo is not updated
      with the annotation overrides.


      Regarding the scattering:

      1) I've started with a simple annotation handling with AnnotationDependencyBuilder and DependencyFactory(Lookup), but this is not yet enabled - DependencyBuilder is not pluged in.
      There was a question about using a chain of DependencyBuilders, but that's where it stopped.
      - http://www.jboss.com/index.html?module=bb&op=viewtopic&t=107268

      2) But on the other hand I'm doing a whole annotation lookup through MetaDataRepository in PreInstallAction.

      3) And I do a straight annotation lookup via BeanInfo in LifecycleAction.

      I like the AnnotationDependencyBuilder with DependencyFactory approach - ok, some weak caching is missing and some other features - but if we are able to provide a generic annotation handling that way ...

      I guess some of the actual annotation handling will/is depending on the ControllerState we are in - specially regarding classes being present and actual bean instantiation with beanfactory.
      Perhaps doing DependencyBuilders depending on the state?

      Is changing the BeanMetaData legal when handling annotations?
      Or we need to do the cloning before this?

        • 1. Re: Annotation features
          Adrian Brock Master

           

          "alesj" wrote:

          There are some pointers to use the ClassInfo/BeanInfo:

          The inspection should come from "reflection abstraction"
          in the container module which is integrated via the
          Configurator/BeanInfo.


          But is looks like this is not yet fully implemented:

          Which AFAIK, (Kabir may know better) isn't properly integrated
          except when AOP is used. i.e. The Bean/ClassInfo is not updated
          with the annotation overrides.



          The plan to update the Bean/ClassInfo was dropped (or at least shelved)
          since it was too much work for AOP.

          Instead, you should use the MetaData from the MetaDataRepository for that instance.
          That is where the overridden annotations are stored at the instance level.


          Regarding the scattering:

          1) I've started with a simple annotation handling with AnnotationDependencyBuilder and DependencyFactory(Lookup), but this is not yet enabled - DependencyBuilder is not pluged in.
          There was a question about using a chain of DependencyBuilders, but that's where it stopped.
          - http://www.jboss.com/index.html?module=bb&op=viewtopic&t=107268

          2) But on the other hand I'm doing a whole annotation lookup through MetaDataRepository in PreInstallAction.

          3) And I do a straight annotation lookup via BeanInfo in LifecycleAction.

          I like the AnnotationDependencyBuilder with DependencyFactory approach - ok, some weak caching is missing and some other features - but if we are able to provide a generic annotation handling that way ...

          I guess some of the actual annotation handling will/is depending on the ControllerState we are in - specially regarding classes being present and actual bean instantiation with beanfactory.
          Perhaps doing DependencyBuilders depending on the state?

          Is changing the BeanMetaData legal when handling annotations?
          Or we need to do the cloning before this?


          Don't follow the rest of this, I still haven't had to look at what you and Kabir did
          in this area.

          IMHO, the BeanMetaData should always be cloned, even if it just avoids
          BeanMetaData bmd = ...
          controller.registerContext(bmd);
          bmd.changeIt() // oops - which version of bmd gets used?
          


          • 2. Re: Annotation features
            Ales Justin Master

             

            "adrian@jboss.org" wrote:

            Instead, you should use the MetaData from the MetaDataRepository for that instance.
            That is where the overridden annotations are stored at the instance level.

            Yup, learned that one from PreInstall scoping lookup.

            "adrian@jboss.org" wrote:

            Don't follow the rest of this, I still haven't had to look at what you and Kabir did in this area.

            Any pointers then to follow?
            So that I don't go astray as in name-aware ... :-(


            • 3. Re: Annotation features
              Adrian Brock Master

               

              "alesj" wrote:

              "adrian@jboss.org" wrote:

              Don't follow the rest of this, I still haven't had to look at what you and Kabir did in this area.

              Any pointers then to follow?
              So that I don't go astray as in name-aware ... :-(


              Discuss it with Kabir. He's your partner in crime in this area. :-)

              Like I said before, I'll eventually get around to reviewing
              it all and telling you what is wrong with it. :-)

              In principle it should just be about populating the BeanMetaData from the annotations
              where there it doesn't already exist - i.e. what the user provides overrides
              (either xml or programmatic overrides the annotations).

              The difficult part I can see comes from the factory processing where you don't know
              the implementation class until the factory has instantiated the object.

              • 4. Re: Annotation features
                Ales Justin Master

                 

                "adrian@jboss.org" wrote:

                Instead, you should use the MetaData from the MetaDataRepository for that instance.
                That is where the overridden annotations are stored at the instance level.


                BasicKernelMetaDataRepository.java
                
                 /**
                 * Initialise metadata retrieval
                 *
                 * TODO lots more work
                 * @param context the context
                 * @return the retrieval
                 */
                 protected MetaDataRetrieval initMetaDataRetrieval(KernelControllerContext context)
                 {
                 MutableMetaDataRepository repository = getMetaDataRepository();
                 ScopeKey scopeKey = context.getScope();
                 ArrayList<MetaDataRetrieval> retrievals = new ArrayList<MetaDataRetrieval>();
                 for (Scope scope : scopeKey.getScopes())
                

                This is probably where this should already be stored/done, but the TODO is not that overwhelming ... :-)

                I'm trying to do this:
                 // properties
                 Set<PropertyInfo> properties = info.getProperties();
                 if (properties != null && properties.isEmpty() == false)
                 {
                 for(PropertyInfo pi : properties)
                 {
                 Signature pis = new MethodSignature(pi.getName(), Configurator.getParameterTypes(trace, new TypeInfo[]{pi.getType()}));
                 MetaDataRetrieval cmdr = retrieval.getComponentMetaDataRetrieval(pis);
                 if (cmdr != null)
                 {
                 System.out.println("cmdr = " + cmdr);
                 }
                 }
                 }
                


                Or what's the way to 'join' info from MetaDataRetrieval and [Class|Property|Method]Info, and populate BeanMetaData.

                • 5. Re: Annotation features
                  Ales Justin Master

                   

                  "alesj" wrote:

                  Or what's the way to 'join' info from MetaDataRetrieval and [Class|Property|Method]Info, and populate BeanMetaData.

                  This is already working. ;-)
                  The thing was that PropertyInfo is first split into getter and setter and than added as a component metadata retrieval.

                  • 6. Re: Annotation features
                    Ales Justin Master

                    How to trigger all those checks from MetaDataVisitorNode.[initial|describe]Visit?

                    e.g. when I run into @Inject annotation, I add an AbstractInjectionValueMetaData to BeanMetaData (if that property is not already defined ...), but I'm missing all those checks previously done - from setting the context ref, adding dependencies, ...

                    • 7. Re: Annotation features
                      Ales Justin Master

                       

                      "alesj" wrote:
                      How to trigger all those checks from MetaDataVisitorNode.[initial|describe]Visit?

                      Solved by new wrapper around MetaDataVisitor. ;-)
                      We'll see if the final solution is OK. :-)