On 2003.02.24 14:25 Bill Burke wrote: > > > > -----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.
Aha! At least there's something we can agree on! I like this, now I understand, good idea, etc. etc. Thanks. I missed this reading the code. > > 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. At the moment I'd think that having a single level metadata repository and having the items you store in it know how and if to serialize themselves would make sense. Or using non-string keys that indicate if the value is transient is another possibility. > > 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? No, I didn't quite understand what all the Metadata objects were and where they come from. > > > 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. Yes. Thanks david > > 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 > > ------------------------------------------------------- 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
