RE: [JBoss-dev] org.jboss.aop.MethodMetaData
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of David
Jencks
Sent: Saturday, February 22, 2003 1:43 PM
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] org.jboss.aop.MethodMetaData
public Object resolve(Invocation invocation, String group, String attr)
{
Method method = MethodInvocation.getMethod(invocation);
return getMethodMetaData(method.getName(), group, attr);
}
Am I missing something or is this code making the assumption that a
method's name provides sufficient discrimination amongst all possible
method metadata? If so, what is the architectural rationale behind that
usage?
EJB metadata does not take into account method arguments either.
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
RE: [JBoss-dev] org.jboss.aop.MethodMetaData
On 2003.02.24 09:14 Bill Burke wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
David
Jencks
Sent: Saturday, February 22, 2003 1:43 PM
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] org.jboss.aop.MethodMetaData
public Object resolve(Invocation invocation, String group, String
attr)
{
Method method = MethodInvocation.getMethod(invocation);
return getMethodMetaData(method.getName(), group, attr);
}
Am I missing something or is this code making the assumption that a
method's name provides sufficient discrimination amongst all possible
method metadata? If so, what is the architectural rationale behind
that
usage?
EJB metadata does not take into account method arguments either.
???
Some ejb metadata appears to:
from ejb_jar_2_1.xsd, inside methodType, around line 1639
3.
method
ejb-nameEJBNAME/ejb-name
method-nameMETHOD/method-name
method-params
method-paramPARAM-1/method-param
method-paramPARAM-2/method-param
...
method-paramPARAM-n/method-param
/method-params
/method
This style is used to refer to a single method within a
set of methods with an overloaded name. PARAM-1 through
PARAM-n are the fully-qualified Java types of the
method's input parameters (if the method has no input
arguments, the method-params element contains no
method-param elements). Arrays are specified by the
array element's type, followed by one or more pair of
square brackets (e.g. int[][]).
[david-- there appears to be a mistake in the xsd, copying the last
sentence of style 2 at this point]
Whidh ejb metadata are you referring to?
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
RE: [JBoss-dev] org.jboss.aop.MethodMetaData
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of David
Jencks
Sent: Monday, February 24, 2003 9:48 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] org.jboss.aop.MethodMetaData
On 2003.02.24 09:14 Bill Burke wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
David
Jencks
Sent: Saturday, February 22, 2003 1:43 PM
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] org.jboss.aop.MethodMetaData
public Object resolve(Invocation invocation, String group, String
attr)
{
Method method = MethodInvocation.getMethod(invocation);
return getMethodMetaData(method.getName(), group, attr);
}
Am I missing something or is this code making the assumption that a
method's name provides sufficient discrimination amongst all possible
method metadata? If so, what is the architectural rationale behind
that
usage?
EJB metadata does not take into account method arguments either.
???
Some ejb metadata appears to:
from ejb_jar_2_1.xsd, inside methodType, around line 1639
3.
method
ejb-nameEJBNAME/ejb-name
method-nameMETHOD/method-name
method-params
method-paramPARAM-1/method-param
method-paramPARAM-2/method-param
...
method-paramPARAM-n/method-param
/method-params
/method
This style is used to refer to a single method within a
set of methods with an overloaded name. PARAM-1 through
PARAM-n are the fully-qualified Java types of the
method's input parameters (if the method has no input
arguments, the method-params element contains no
method-param elements). Arrays are specified by the
array element's type, followed by one or more pair of
square brackets (e.g. int[][]).
[david-- there appears to be a mistake in the xsd, copying the last
sentence of style 2 at this point]
Whidh ejb metadata are you referring to?
Didn't know. Sorry. *blush* Is this an EJB 2.1 thing? (hence
ejb_jar_2_1.xsd).
I can add this to MethodMetaData eventually. Iteration... But the whole
point of the metadata is that Metadata repositories are chained. When an
Interceptor wants metadata, it walks the chain. Each repository decides
whether or not it can resolve the metadata, or how to resolve the metadata
reference based on the context of the Invocation. For example, for
MethodMetaData, the context of the Invocation is the method name. My main
goal here it to:
1) Allow metadata to be programmitcally overriden generically at runtime
2) Allow default metadata to be defined within an application, JVM, and also
cluster-wide.
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
RE: [JBoss-dev] org.jboss.aop.MethodMetaData
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Bill
Burke
Sent: Monday, February 24, 2003 10:06 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] org.jboss.aop.MethodMetaData
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of David
Jencks
Sent: Monday, February 24, 2003 9:48 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] org.jboss.aop.MethodMetaData
On 2003.02.24 09:14 Bill Burke wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
David
Jencks
Sent: Saturday, February 22, 2003 1:43 PM
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] org.jboss.aop.MethodMetaData
public Object resolve(Invocation invocation, String group, String
attr)
{
Method method = MethodInvocation.getMethod(invocation);
return getMethodMetaData(method.getName(), group, attr);
}
Am I missing something or is this code making the assumption that a
method's name provides sufficient discrimination amongst
all possible
method metadata? If so, what is the architectural rationale behind
that
usage?
EJB metadata does not take into account method arguments either.
???
Some ejb metadata appears to:
from ejb_jar_2_1.xsd, inside methodType, around line 1639
3.
method
ejb-nameEJBNAME/ejb-name
method-nameMETHOD/method-name
method-params
method-paramPARAM-1/method-param
method-paramPARAM-2/method-param
...
method-paramPARAM-n/method-param
/method-params
/method
This style is used to refer to a single method within a
set of methods with an overloaded name. PARAM-1 through
PARAM-n are the fully-qualified Java types of the
method's input parameters (if the method has no input
arguments, the method-params element contains no
method-param elements). Arrays are specified by the
array element's type, followed by one or more pair of
square brackets (e.g. int[][]).
[david-- there appears to be a mistake in the xsd, copying the last
sentence of style 2 at this point]
Whidh ejb metadata are you referring to?
Didn't know. Sorry. *blush* Is this an EJB 2.1 thing? (hence
ejb_jar_2_1.xsd).
I can add this to MethodMetaData eventually. Iteration... But the whole
point of the metadata is that Metadata repositories are chained. When an
Interceptor wants metadata, it walks the chain. Each repository decides
whether or not it can resolve the metadata, or how to resolve the metadata
reference based on the context of the Invocation. For example, for
MethodMetaData, the context of the Invocation is the method name. My main
goal here it to:
1) Allow metadata to be programmitcally overriden generically at runtime
2) Allow default metadata to be defined within an application,
JVM, and also
cluster-wide.
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.
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
RE: [JBoss-dev] org.jboss.aop.MethodMetaData
When an Interceptor wants metadata, it walks the chain. Each repository decides whether or not it can resolve the metadata, or how to resolve the metadata reference based on the context of the Invocation. For example, for MethodMetaData, the context of the Invocation is the method name. My main goal here it to: 1) Allow metadata to be programmitcally overriden generically at runtime 2) Allow default metadata to be defined within an application, JVM, and also cluster-wide. And I really love that. Though I don't think it is the role of the interceptor to iterate over the Repositories but instead to some other component (such as the repository itself) to delegate the resolution down to the chain. It makes me think to the exact opposite of the Clasloader mechanism: try to load locally and if not present, ask parent (i.e. Servlet mode) --- 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
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? 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. I have some code with these ideas, I'll try to commit it or send it to you later today. I think it will take some experimentation to get something that works really well. 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
RE: [JBoss-dev] org.jboss.aop.MethodMetaData
-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. The Invocation object does not have amashed down, merged set of metadata. The Invocation only has a reference to the repositories not a copy of each metadata element. I don't know if this is a good analogy, but I think of it as polymorphic data. I have some code with these ideas, I'll try to commit it or send it to you later today. I think it will take some experimentation to get something that works really well. I agree. I want this chaining, but am open to the implementation. 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
RE: [JBoss-dev] org.jboss.aop.MethodMetaData
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Sacha Labourey Sent: Monday, February 24, 2003 10:33 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] org.jboss.aop.MethodMetaData When an Interceptor wants metadata, it walks the chain. Each repository decides whether or not it can resolve the metadata, or how to resolve the metadata reference based on the context of the Invocation. For example, for MethodMetaData, the context of the Invocation is the method name. My main goal here it to: 1) Allow metadata to be programmitcally overriden generically at runtime 2) Allow default metadata to be defined within an application, JVM, and also cluster-wide. And I really love that. Though I don't think it is the role of the interceptor to iterate over the Repositories but instead to some other component (such as the repository itself) to delegate the resolution down to the chain. It makes me think to the exact opposite of the Clasloader mechanism: try to load locally and if not present, ask parent (i.e. Servlet mode) I disagree. The MetadataRepository should not have a concept of a parent. Think of it this way. You hava Class metadata that applies to multiple classes. One Class is configured to belong to one Cluster partition, a different class belongs to another. Is that a good enough use case? The invocation object receives the chain of references to the repositories as an Arraylist. The interceptor asks the invocation object to resolve the metadata for it. 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
RE: [JBoss-dev] org.jboss.aop.MethodMetaData
One more thing We really need a way to generically define metadata and a generic way for an interceptor to obtain class/ejb metadata. Currently, if somebody wants to define a custom interceptor, the only way define class/ejb metadata is to modify and recompile JBoss code. Interceptors should be deployable components. The way I have currently designed the AOP framework, this is possible. It may need some tweaking here and there, but I think the design fits. Bill -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? 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. I have some code with these ideas, I'll try to commit it or send it to you later today. I think it will take some experimentation to get something that works really well. 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 --- 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
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? 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. My impression is that your Advisor object is the top of the interceptor chain. Is thie correct or wrong? 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. The Invocation only has a reference to the repositories not a copy of each metadata element. I don't know if this is a good analogy, but I think of it as polymorphic data. I have some code with these ideas, I'll try to commit it or send it to you later today. I think it will take some experimentation to get something that works really well. I agree. I want this chaining, but am open to the implementation. fine 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
RE: [JBoss-dev] org.jboss.aop.MethodMetaData
-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
RE: [JBoss-dev] org.jboss.aop.MethodMetaData
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
RE: [JBoss-dev] org.jboss.aop.MethodMetaData
Aha! At least there's something we can agree on! I may be too dense in my understanding of the TX stuff right now so have patience. I may/may not have a point. 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. SimpleMetaData does have this capability. Its supposed to encapsulate all the different kinds of payloads that are in the old Invocation object. 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
