3 Replies Latest reply on Nov 27, 2007 10:35 AM by adrian.brock

    MetaData based annotations in EJB3 container

      I've committed this change. It's not really the full thing.

      Instead of using metadata directly, I've had to hack a subclass of AOP's
      AnnotationRepository.

      This is because
      1) There are many places in EJB3 using the annotation repository directly
      instead of advisor(container).resolveAnnotation or invocation.resolveAnnotation.
      These just need fixing
      2) The use of metadata rather than AnnotationRepository is not complete
      in aop advisor's.

      Both of these need fixing.

      I also don't register the metadata in the metadata repository yet.
      This is because I couldn't locate a reliable place to do the (un)register
      where it wouldn't leak.
      The ejb3 container lifecyle handling needs tidying up (defining properly?).

      Anyway, what this gives is a simple hierarchy of metadata contexts.
      There is the class context which just loads annotations from the bean class.

      Above this is a more complicated instance context which has two retrievals
      A normal MemoryMetaDataLoader which works like the old AnnotationRepository
      and an EJBMetaDataLoader which loads from the metadata dynamically.

      There is a test in the ejb3 project "changexml" which changes the SecurityDomain
      in the xml metadata dynamically and shows you get a security exception
      when you define one on an ejb that didn't previously have one.

      Improvements to come:

      Besides what is mentioned above, the the EJBMetaDataLoader could do with
      some using the cache version of the MetaDataContext. I didn't do this
      because there's no easy way in the current unified metadata to get a notification
      when it changes so you can invalidate the cache.

      There should also be other contexts like "application" and 'deployment"
      where metadata can come from the ear or ejb.jar level.
      e.g. There should also be a loader that loads the security domain annotation
      from JBossMetaData.getSecurityDomain() which is a deployment level
      rather than ejb level (which overrides it) config.

      And potentially things like thread/transaction local contexts
      so you could override certain metadata for just one invocation.
      But before implementing that, things like the security annotations,
      need meta annotating with
      @org.jboss.metadata.spi.Restricted
      such that you can't override security config this way. ;-)

        • 1. Re: MetaData based annotations in EJB3 container
          wolfc

           

          "adrian@jboss.org" wrote:
          I've committed this change. It's not really the full thing.

          Instead of using metadata directly, I've had to hack a subclass of AOP's
          AnnotationRepository.

          This is because
          1) There are many places in EJB3 using the annotation repository directly
          instead of advisor(container).resolveAnnotation or invocation.resolveAnnotation.
          These just need fixing

          I'm thinking to make the Advisor an association of the EJBContainer instead of a super class. What do you think about that?

          For annotation (/metadata) resolving there everybody must use the getAnnotation methods on the EJBContainer. ResolveAnnotation is also not allowed.
          "adrian@jboss.org" wrote:

          2) The use of metadata rather than AnnotationRepository is not complete
          in aop advisor's.

          Both of these need fixing.

          I also don't register the metadata in the metadata repository yet.
          This is because I couldn't locate a reliable place to do the (un)register
          where it wouldn't leak.
          The ejb3 container lifecyle handling needs tidying up (defining properly?).

          This is where the trouble of aop.xml starts. If it's augmenting we must have it before we process metadata. If it's using then it must run after processing of metadata. We keep pushing this forward to see how far we can get.

          The lifecycle itself should be according to http://wiki.jboss.org/wiki/Wiki.jsp?page=EJB3Q32007

          • 2. Re: MetaData based annotations in EJB3 container

             

            "wolfc" wrote:

            I'm thinking to make the Advisor an association of the EJBContainer instead of a super class. What do you think about that?

            For annotation (/metadata) resolving there everybody must use the getAnnotation methods on the EJBContainer. ResolveAnnotation is also not allowed.


            Better would be to make it implement the MetaData interface
            then people can retrieve other hierarchical context, not just annotations.
            You could also expose a getMutableMetaData() to allow people to put
            things there, including non-annotations.

            But this is more important where people need to retrieve things
            in the interceptors. i.e. they don't directly have access to the EJBContainer api,
            just the aop subset.


            This is where the trouble of aop.xml starts. If it's augmenting we must have it before we process metadata. If it's using then it must run after processing of metadata. We keep pushing this forward to see how far we can get.

            The lifecycle itself should be according to http://wiki.jboss.org/wiki/Wiki.jsp?page=EJB3Q32007


            I was actually talking the invocations of instantiated/create/destroy/etc.

            But this needs resolving generically. e.g. when we do the aop/jca
            implementation, this will have similar requirements
            i.e. xml metadata, annotations on the resource adapter and overrides
            in jca specific aop domains.

            JBossMessaging has nearly the same requirements already
            but they've solved the problem in their own way, which is not good -
            same problem, different bugs. ;-)

            • 3. Re: MetaData based annotations in EJB3 container

              Ooops!!

              I didn't implement a couple of methods in the AnnotationsRepository,
              specifically, the ones used for method annotation retrieveal.

              This caused some of the tests to fail, should be fixed now.

              +1 Guinness for me :-)