> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of David > Jencks > Sent: Monday, February 24, 2003 1:54 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] org.jboss.aop.MethodMetaData > > > On 2003.02.24 13:17 Bill Burke wrote: > > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] Behalf Of > > David > > > Jencks > > > Sent: Monday, February 24, 2003 10:37 AM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [JBoss-dev] org.jboss.aop.MethodMetaData > > > > > > > > > <big snip> > > > > > > > I also want to add that the current interface for Metadata, metadata > > > > chains, > > > > and how you configure metadata is open for debate. It probably is > > not a > > > > complete definition and I'm open for suggestions. I'm > hoping that as > > I > > > > port > > > > some of the current interceptors more requirements will be flushed > > out. > > > > Persistence will be the big test. > > > > > > I don't have any very solid ideas yet, but I think these would be > > > improvements: > > > > > > 1. Single level lookups with Object keys rather than String: Object > > > getMetadata(Object key). Why force the guy storing the > metadata to use > > a > > > concealed hashmap with String keys? > > > > > > > Why? Simplicity. But fair nuff. > > > > > 2. Put the default metadata in the thing that supplies the chain of > > > interceptors (Advisor?), and always add it first to what the > Invocation > > > gets. (rather than putting the default metadata in the Invocation > > > directly. > > > > > > > Advisor does not work the way you describe it. The Advisor creates an > > ArrayList of MetaData repositories(the chain) and passes it as a > > parameter > > to the Invocation object. The Invocation object is itself a > > MetadataResolver and is first in the chain. > > Can you explain why the invocation object has this unique metadata object > rather than always getting it from the advisor? Is this how you want to > support customization of individual invocations? But where does the > invocation come from? How will it get this unique metadata? >
Invocation object has unique metadata for tx and security propagation for example. If there is no txid or security credentials to pass, this object is empty. Think of it as the payload in the old invocation object. The Invocation object has unique metadata so that interceptors can pass on information farther along the chain. This is not how I will support customization of individual invocations. I have a ThreadMetaData object that is second in the chain. ThreadMetaData class simply uses a ThreadLocal to hold SimpleMetaData. So the chain looks like this currently: Invocation, ThreadMetaData, InstanceAdvisor.metadata, ClassAdvisor.MethodMetaData, ClassAdvisor.defaultmetadata. As far as remoting goes. The SimpleMetaData class does have the means now to define whether data should be serialized across the wire. My thought is that when a DP (and later an AOP'ized Class") is serialized, my thoughts are that the the serializer will again walk through the chain and ask each repository for its serializable data. Or another possibility is that the Interceptor knows which metadata should be serialized. This area needs some thought and iteration. Am I making sense? If not, I'll elaborate. > I'd think that giving the "top of the chain" object the default metadata > and then providing some facility for pulling more in from the environment > would make sense. > This is exactly what I do and what I provide. The Class Advisor is responsible for knowing the chain and providing it to the Invocation object. Do you mean something different? > My impression is that your Advisor object is the top of the interceptor > chain. Is thie correct or wrong? > > Yup. ClassAdvisor is currently top and bottom of chain. > The Invocation object does > > not > > have amashed down, merged set of metadata. > > I didn't say it should. But for sure it should conceal how it looks up the > metadata from the guys who are asking for it. > I do this concealing through the MetadataResolver interface. Bill ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
