Tim, 1 and 2 seem reasonable to me.
For 3, I am not sure about all the corner cases if class containing a root isn't included. What if it is loaded and initialized before other portable guys will access that root and this class could also have its own code that could change this root field... BTW, speaking about expressions, there is another option that could be useful in some cases. So, you could use field type as an anchor to define root, and define a marker interface that can be matched on subtypes. So, expression would look something like this: *..IRootable+ *..*.* where IRootable is an interface that root candidates could implement. regards, Eugene Tim Eck wrote: > 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
