MetadataContext and advisor

[kabirkhan]

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

[adrian.brock]

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
annotations.

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.