Accessing application metadata

[starksm64]

We need to get a better notion of how an aspect gains access to application level metadata. Recent examples include PropertyEditors local to the deployment, and a need to know a cluster wide name to ClassLoader mapping in order to properly interact with the jgroups rpc calls initiated by scoped applications.

I know aop has such a notion, but how would these two usecases metadata be integrated as part of the deployment process?

[adrian.brock]

At least for the PropertyEditors we should have our own repository
that understands classloading.

Unfortunately for things like the jdbc DriverManager there is no fix
other than making sure the transitive closure of the reference classes
are all in the same classloader :-(

In hypothetical terms it would be good if this was nearly automagical using an annotation:

public MyRepositoryClass
{
@ApplicationLocal Map repository = new HashMap();
}

With this essentially creating a wrapper

WeakHashMap<classloader, repositoryMap>

and the necessary access code

// The source code
repository.get("Something");
// The enhanced code
Map repository = weakMap.get(Thread.currentThread().getContextClassLoader());
repository.get("Something");

I am assuming that the TCL controls the context of the application?

If the annotation also had an optional name it could register itself with an
ApplicationMetaDataResolver:

@ApplicationLocal(name="MyMetaData") Map repository = new HashMap();

Invocation.getMetaData().getMetaData("MyMetaData", "Something");

[starksm64]

It seems that factories like DriverManager should just not be used. We don't really need to use this right? Other factories like xml parsers need a context aware variation just like the PropertyEditors. Its not clear that the TCL is the only key that can be used for accessing the metadata.

federation
+ cluster
|-+ server
|---+ application
|-----+ session
|-----+ request

The TCL only differentiates between application/deployment contexts. The metadata layer management needs to keep the chain in synch as the various contexts are introduced.

[adrian.brock]

I think chaining belongs at a higher level of abstraction.

i.e. If you are maintaining the metadata you use the application scoped config directly.
If you are using the metadata you use a facade that understands the chain.

I do see your point though that a configuration repository can have multiple levels
and that the following is a bit naive (unless the chaining is "fixed").

public MyMetaDataRepository
{
 @ClusterLocal(name="MyMetaData") MyMetaData clusterData = new MyMetaData();
 @ServerLocal(name="MyMetaData") MyMetaData serverData = new MyMetaData();
 @ApplicationLocal(name="MyMetaData") MyMetaData appData = new MyMetaData();
}

The problem is that without such a separation you have to resort to passing the
level in the api when deploying metadata which could be achieved with an annotation
override?

public MyMetaDataRepository
{
 MyMetaData data = new MyMetaData();
}

<!-- Use ClusterData and add it to the cluster level of the chain under MyMetaData -->
<bean name="ClusterMyMetaData" class="MyMetaDataRepository">
 <property name="data">
 <annotation name="ClusterLocal">
 <attribute name="name">MyMetaData</attribute>
 </annotation>
 <inject bean="ClusterData"/>
 </property>
</bean>

<!-- Use ServerData and add it to the server level of the chain under MyMetaData -->
<bean name="ServerMyMetaData" class="MyMetaDataRepository">
 <property name="data">
 <annotation name="ServerLocal">
 <attribute name="name">MyMetaData</attribute>
 </annotation>
 <inject bean="ServerData"/>
 </property>
</bean>

// then per application:
<bean name="App1MyMetaData" class="MyMetaDataRepository">
 <property name="data">
 <annotation name="ApplicationLocal">
 <attribute name="name">MyMetaData</attribute>
 </annotation>
 <inject bean="App1Data"/>
 </property>
</bean>

[starksm64]

I'm talking about more of a metadata aspect that manages the hiearchical data. I expect that you will specify the initial scope to start searching from, or without such a starting point, the search simply starts from the inner most scope. Having to manage multiple scopes explicitly is clumsy.

I'm still not clear how this is going to be implemented as what is managing the active inner most scope. Interceptors for the various scopes that have to deal with the app TCL, context session and its key, and request level data seem to be required.

[adrian.brock]

I'm talking about more of a metadata aspect that manages the hiearchical data. I expect that you will specify the initial scope to start searching from, or without such a starting point, the search simply starts from the inner most scope. Having to manage multiple scopes explicitly is clumsy.

Something has got to populate the correct scope explicitly.
Given an explicit api, it is possible to implement something more clever.
It is impossible the other way around.

[starksm64]

So one way it could be done is with a service with the various interceptors, but then there is the issue of how the deployers/aspects integrate with it. The aop framework already has a similar notion, what I'm struggling with is that the starting point for accessing an interface like this:

interface ScopedMetaData
{
 Object getData(Scope scope, Object key);
 vois setData(Scope scope, Object key, Object data);
}

or are there other factilities to chain together maps? Think about two invocations, one to access an attribute on an SFSB container and a second SFSB method invocation on a bean in the container. The first has no session scope data context, the second does, but also has a different and overriding request scope data context.

Now back to the original problem of scoped PropertyEditors. One way to implement this is by updating the PropertyEditorsMgr to have aspects which look for registered entries at the various scopes. This is an example where I don't expect any explicit use of the scope during the lookup. Can we explore a prototype of this to make this discussion more concrete?

[adrian.brock]

I'm still not clear how this is going to be implemented as what is managing the active inner most scope. Interceptors for the various scopes that have to deal with the app TCL, context session and its key, and request level data seem to be required.

(This didn't post last night so I sent it to the mailing list)

Correct the "key"s need to be shared between deployment and runtime.

In the past, the metadata has been copied into thread locals to pass
under interfaces (when the request/instance is lost)
and into the request to go over the wire (when the thread/app context is
lost).

[adrian.brock]

The aop framework already has a similar notion

The AOP MetaDataResolver only works at the joinpoint level (i.e. the invocation).
I'd assumed we were generalizing this to any context (with AOP delegating to the more
general approach?)

[adrian.brock]

Now back to the original problem of scoped PropertyEditors. One way to implement this is by updating the PropertyEditorsMgr to have aspects which look for registered entries at the various scopes. This is an example where I don't expect any explicit use of the scope during the lookup. Can we explore a prototype of this to make this discussion more concrete?

The property editors just needs a way of saying
* these are global (VM metadata)
* these are scoped (application metadata)
The rules are the same as the classloading aren't they?

The more difficult issue is things like the JMX console which needs to know
about the scoped editors when dealing with an application scoped MBean.

[starksm64]

The property editors just needs a way of saying
* these are global (VM metadata)
* these are scoped (application metadata)
The rules are the same as the classloading aren't they?

The more difficult issue is things like the JMX console which needs to know
about the scoped editors when dealing with an application scoped MBean.

One way of implementing the PropertyEditors factory/manager is to simply have a class loader aware manager, and this is what we will have to do for 4.0.x.

I want to look at also implementing this usecase using a more general metadata implementation to get to handling of both the SARDeployer/XMBean using property editors for attributes, as well as the jmx-console needing to access a given MBean's PropertyEditors. This latter usecase illustrates the lack of stability/usefulness of the TCL as a metadata key. Yes, the jmx-console does need access to the correct class loader, but it will not be the active TCL for the jmx-console invocations. Rather, its additional metadata associated with the application component. In general I think we want to move away from using the TCL as a key because there are too many context for which its not the right key.

[adrian.brock]

At least in our JMX implementation you can get the context ClassLoader for the MBean
using the registry.

In general, it isn't an easy problem (and shouldn't be for security reasons)
to get the classloader for a deployment externally.
So yes, using the TCL as a key is not a good idea.

[starksm64]

Ease of access is one issue that is somewhat independent of security in my view because the only way to achieve this without using a security manager requires that the access path be collocated in a single package. Its a complication of having a loosely coupled system.