> -----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-name>EJBNAME</ejb-name> > > <method-name>METHOD</method-name> > > <method-params> > > <method-param>PARAM-1</method-param> > > <method-param>PARAM-2</method-param> > > ... > > <method-param>PARAM-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
