3 Replies Latest reply on Jul 1, 2008 5:23 AM by wolfc

    Integrating aop.xml information into metadata view

    starksm64

      Moving this dev thread to here.
      http://lists.jboss.org/pipermail/jboss-development/2008-June/012271.html

      The ejb3 layer is looking to aop for some of its metadata and we need inverted to be looking at metadata/metadata repository to have an externalized, authoritative view. Carlo's point on the dev thread was about the default jndi binding policy.

      Kabir had been working on a metadata view of the aop.xml. We are doing some integration with this view metadata repository loaders (I believe). The point of this thread is how to properly integrate the various aop metadata info into the jboss-metadata view.

        • 1. Re: Integrating aop.xml information into metadata view

           

          "scott.stark@jboss.org" wrote:
          Moving this dev thread to here.
          http://lists.jboss.org/pipermail/jboss-development/2008-June/012271.html

          The ejb3 layer is looking to aop for some of its metadata and we need inverted to be looking at metadata/metadata repository to have an externalized, authoritative view. Carlo's point on the dev thread was about the default jndi binding policy.

          Kabir had been working on a metadata view of the aop.xml. We are doing some integration with this view metadata repository loaders (I believe). The point of this thread is how to properly integrate the various aop metadata info into the jboss-metadata view.


          I don't understand why you a reinventing the wheel here?

          The MDR was designed to do this kind of processing.

          For the JNDI example on the mailing list, you just need something
          that deploys that default JNDIBindingPolicy annotation in the "Server" scope.

          I'll bet you'll come up with examples where this is not possible,
          and then I'll have to explain why you're doing it wrong or making
          overly complicated. ;-)

          NOTE: I don't really expect that we can fully take advantage the MDR yet,
          until Kabir has implemented my feature request where AOP domains
          (and their aop config) are associated with the MDR scopes.

          e.g. being able to create an AOP domain in the EJB3 subsystem scope
          that is a parent of all EJB3 deployments and whose AOP config doesn't interfere
          with other subsystems.

          This instead of the current ejb3 or jboss messaging aop config hacks
          (two different solutions) is the more generic solution that can then
          be used by all subsystems.

          It's even more generic than that, because you can override the subsystem
          scope/config with an application level aop domain/config, etc.

          This also shows that the scoped MDR is not just about annotations, but about generic
          configuration, e.g. the AOP domain.

          Have a nice weekend. ;-)

          • 2. Re: Integrating aop.xml information into metadata view
            starksm64

            Not duplicating effort and making sure we are integrating the sources of metadata is the point here, so I don't think we have reinvented the mdr as yet. So for the jndi binding policy, we have:

            - aop.xml providing a bean level/aop domain level default.
            - deployer level defaults.
            - class level annotation, jboss.xml providing deployment level specifications that go into a JBossMetaData.getJndiBindingPolicy

            So the mdr should be the authoritative view of the JndiBindingPolicy with loaders from the various sources?

            • 3. Re: Integrating aop.xml information into metadata view
              wolfc

              Add to this mix the ejb3 metadata bridge which extends mdr with a facility to implement the logic of resolving the right metadata to an annotation.

              So you end up with a BridgedMetaDataLoader which has multiple MetaDataBridges.

              The actual implementations of MetaDataBridges are within the specific components, so for example ejb3-interceptors has all the knowledge of interpreting annotations and metadata. That's how I would like to keep: the functional component dictates that logic.

              Right now the connection between an AOP domain and the EJB is coded in Ejb3Deployment. So on an EJB container (which delegates to a ManagedObjectAdvisor) has the full view of all annotations.