Actually it simplifies the code. If you take a look at our interceptor stack most have a ton of code just to load and maintain the metadata, and the worst part is we have no control over it at runtime. It is way simpler. You'll see.
The easiest case for me the read ahead configuration in entity beans. There is no reason for this to be static. In fact it should be manageable at runtime, and if I'm luck I'll be able to pull it off for 4.0. Scott tells me there is a similar need to manage security at runtime. There really is no need to shut down an application in production just to change some configuration data.
Even if there is no real need the code is simpler.
-dain
David Jencks wrote:
Can you please give a fairly detailed use case for this idea and indicate why it is needed rather than a static division of metadata between that which is tied to an interceptor stack (the same for every invocation going through the stack) and that which is specific to a particular invocation (and thus supplied by the client).So far this idea strikes me as needless complexity that doesn't solve any problems, so please enlighten me as to the point. I will understand much better if you have a specific example that won't work with the division of responsibility outlined above. thanks david jencks On 2002.11.13 17:56:17 -0500 Dain Sundstrom wrote: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
-------------------------------------------------------
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
--
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
