Thanks Eugene...either the set() or get() style pointcut expression is what I needed. I'm just using the AW matcher to determine if a given field matches a root expression, so it doesn't really matter which one I use it seems. If I was implementing roots with a real aspect then I definitely would need to care :-)
Some other notes about this feature (feedback welcome): 1) In some ways this isn't a new problem, but allowing root selection by pattern introduces the possibility of having more than one matching root declaration in tc-config. The only I see this is a problem is if one was trying to assign differing <root-name>'s. I'm inclined to not touch this issue at the moment (using <root-name> is a bit esoteric anyway) 2) I'm almost certain I'll add a new <field-expression> element in tc-config that can be used in place of a <field-name> element within a <root>. You specify either <field-name> or a <field-expression> but not both. It seems like the cleanest evolution and is forward compatible. 3) It will take a little work, but I will preserve the semantic that a root can be defined in class that is not <include>'d. The behavior will be the same: the root will be injected, but the containing class will not be portable. > -----Original Message----- > From: Eugene Kuleshov [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 12, 2007 5:54 PM > To: Tim Eck > Cc: [email protected] > Subject: matching root fields based on annotations > > Tim Eck wrote: > > Moving this to tc-dev as per Steve's suggestion... > > I think have part of this working now (bunch of things to clean up, and > > still have to deal with config)... > > > > I'm using an AW expression like this: > > > > hasfield(@com.tctest.AnnotationTestApp$Root * *) > > > > which seems to work, but I just tried something at random. Any idea if > > that is the right thing to use? :-) > > > Oh I already started to forget how it works. :-) > hasfield(<field pattern>) is an expression for the class level, so not > quite what we need here. > > Field access is matching on pointcuts get(<field pattern>) and > set(<field pattern>) > See > http://aspectwerkz.codehaus.org/definition_issues.html#Pointcut_definition > > You probably will have to use the FieldInfo and pass it trough access > get(@com.tctest.AnnotationTestApp$Root * *..*.*) or set(..) pointcuts, > depends if it is a GETFIELD or PUTFIELD opcode. > > regards, > Eugene > > >> -----Original Message----- > >> From: Eugene Kuleshov [mailto:[EMAIL PROTECTED] > >> Sent: Thursday, July 12, 2007 4:11 PM > >> To: Tim Eck > >> Subject: matching root fields based on annotations > >> > >> > >> You'll need something like this: > >> > >> @Retention(RetentionPolicy.RUNTIME) > >> @Target(ElementType.FIELD) > >> public @interface Root { > >> } > >> > >> public class Timmy { > >> @Root > >> private Object root; > >> } > >> > >> You could extend the com.tctest.AnnotationTestApp and add test case > >> for roots. > >> > >> AW's expression for matching fields by annotations would look > >> something like this: > >> > >> @full.packagename.Root * *..*.* > >> > >> "*" in the middle stands for field type (I think modifier is > optional, > >> but you may have to confirm that). See > >> > >> > > > http://docs.terracotta.org/confluence/display/docs1/AspectWerkz+Pattern+La > > > >> nguage#AspectWerkzPatternLanguage-Fieldselections > >> > >> We have some difference with the current DSO declaration for roots, > >> which only has <full_field_name> part of the expression. I am not sure > >> what would be the best option, but maybe you will have to introduce new > >> element like field-expression in addition to the current field-name > >> element: > >> > >> <root> > >> <!-- <field-name>...</field-name> --> > >> <field-expression>@full.packagename.Root * > >> *..*.*</field-expression> > >> </root> > >> > >> unless you could handle the content of the current field-name element > >> directly to the expression matcher... > >> > >> regards, > >> Eugene > >> > >> _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
