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
