[JBoss-dev] MetaDataRepository Proposal

[Dain Sundstrom]

This is based on some emails I have been trading with Scott. I'm going to start at the invoker and work my way out, because it is the way I know best.

I'm going to add a new MetaDataLoaderInvoker. All this invoker does is populate the invocation object with meta data from the repository. Here is the code for the invoke method:

public Object invoke(Invocation invocation) throw Exception
{
invocationMetaDataLoader.load(invocation, metaDataRepository);
return getNext().invoke();
}

The invocation meta data loader is responsible for getting only the data needed for the interceptor stack from the repository and merging the data into the invocation object. The loader should not blindly overwrite data already in the invocation, so clients can have control over the invocation and the loader should fill in reasonable default if non is available in the repository.

This design is a trade off between blindly stuffing all possible data for an invocation in to the hash table, which could take a very long time, and alternatively having an intelligent loader that "knows" what is needed for the invocation. It is just a trade off of speed for a more static (puggable and runtime replaceable) loader.

Assuming I haven't already confused you, now where does the repository come from? I propose that it is just another service that the container depends on like caching and pooling (when these become real MBeans). I am thinking of an interface like this:

public interface MetaDataRepository {
MetaDataRepository getParent();
void setParent(MetaDataRepository parent);
Object get(Object attributeKey);
void set(Object attributeKey, Object value);
}

Basically this is a plain old map with a possible parent. Exactly how this is implemented, I really don't care; it is a detail. I'm going to write one backed by a HashMap, and we can throw it away later. For attribute keys, I'm thinking of things like MethodTxAttribute that has a method object inside of it. Alternatively, we could lookup by method and get another map back. I don't like that one because it would be too hard to manage with any user interface. There are a million ways to skin this cat. Does anyone have any ideas on how to organize the keys?

If you agree to this point, the next problem is how do we get data into the repository and how do we get updates out. I see two possibilities here: we could go the JCache route where you have a loader associated with the repository that is called when data is not in the cache or we could have an outboard loader that stuffs the cache on container startup. Either way is cool with me.

The final problem is how do we keep this repository in sync with the physical store. For this I would guess we need some sort of listener or notification system. This isn't one of my current problems so I haven't thought about it too much.

-dain

--
xxxxxxxxxxxxxxxxxxxxxxxx
Dain Sundstrom
Chief Architect JBossCMP
JBoss Group, LLC
xxxxxxxxxxxxxxxxxxxxxxxx



-------------------------------------------------------
This sf.net email is sponsored by: Are you worried about your web server security? Click here for a FREE Thawte Apache SSL Guide and answer your Apache SSL security needs: http://www.gothawte.com/rd523.html
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development