1 Reply Latest reply on Jun 26, 2006 4:58 AM by Adrian Brock

    MetadataContext and advisor

    Kabir Khan Master

      One possible oversight regarding the MetadataContext in how it works at present.

      The current assumption is that we only inject a metadatacontext into the advisor if there is per bean metadata. So, the presence of a metadatacontext is one trigger for creating a per-instance proxy or not.

      Should the metadatacontext always be injected since metadata can come from all the levels above (and below) the instance level? If this is the case, I need a way to determine if the metadatacontext has per instance/bean metadata or not

        • 1. Re: MetadataContext and advisor
          Adrian Brock Master

          That is only half true. It actually revolves around some edge-cases.

          The main use case is if somebody adds some metadata
          at the instance level then you need an instance advisor to store
          the link to the metadata context and apply the instance level

          If somebody adds some metadata (e.g. the security domain annotation)
          at say the server then you don't need an
          instance level advisor but when you create the class advisor
          it needs to include the consequences of that annotation.
          e.g. add the security advice to the class

          If somebody adds the security domain at the deployment level
          then unless you know the class is scoped to that deployment
          you are also going to need an "instance" advisor
          such that the security domain annotation doesn't leak into the
          advisor of other deployments using the same class.

          So there needs to be some interaction between the scope
          (including potentially the classloader scoping if we want to
          avoid unnecessary instance advisor construction)
          and aop's decision on what type of advisor to create.

          For now, I'm only going to differentiate the global (server/domain config)
          from the overrides at the deployment/instance level.
          The above problem can be optimised later.