[Fwd: Re: [aspectwerkz-dev] Creating AOPified javadocs]
the_mindstorm <[email protected]> Fri, 27 Aug 2004 18:59:40 +0300
| Newsgroups | gmane.comp.java.aspectwerkz.devel |
|---|---|
| Message-ID | <[email protected]> |
Quote Alex:: > Hi > Looks like you forgot the diagram. > How will you handle call pointcut matching at source level (and not bytecode > level) with QDox ? I don't think it is possible, since QDox does not > modelize method bodies. Correct. This is why I am thinking that the 1st solution is more suited. > > phase 1 and 2 are gone with J2SE 5. The solution must not take to much into account this, as i consider that the switch to J5 will take a long time. > phase 3 is wrong may be: we do not parse javadoc tag. We parse annotations > in bytecode (that get there thru AnnotationC or J2SE 5 javac). Interesting. I missed this. Alex can you pls detail a little this mechanism. An interesting point is that the javadoc will use the compiler/weaver in offline mode (or will use the inline weaver ;-) ). > phase 4 is : weave class files as they gets loaded thru classloaders (not > java sources) > Or may be you confused me , since I made the assumption that those phases > were executing one after another. > > Some more ideas: As you may know AspectJ has a declare error construct that > allows to report design error based on pointcuts (ie : do not call new > Stuff() unless within the factory method code etc). The tool design and the > underlying weaver requirements should handle this as well. There are intentions in AW to support all the AspectJ features? Is there a roadmap? ::the_mindstorm > > Alex > > ----- Original Message ----- > From: "Jack Tang" <[email protected]> > To: <[email protected]> > Sent: Friday, August 27, 2004 4:53 PM > Subject: Re: [aspectwerkz-dev] Creating AOPified javadocs > > > >>Hello Alexandru >> >>After reading Alex's comments, I think I got some points. If something >>wrong, please correct me, Alex. >> >>The key of this problem is when to collect aop model information and >>who will supply these information. Two solution list here: >> >>1.javac + weave classes + generate stubs and javadoc [method 1 and >>method with emitted join points] >>2.parse sources + generate stubs and javadoc >> >>And I divide AW engine workflow into five phrase(maybe more,but here >>I think five is enough). >>1.hook phrase : pipe BootClasspathStarter/JDWPStarter after >>java.lang.ClassLoader >>2.preProcess phrase: initialize preProcessor,filter certain CL and modify > > CL > >>3.parse phrase : parse xml and javadoc @tags >>4.compile phrase : compile Java source >>5.transform/weave phrase: weave the cross-cutting info >> >>diagram like this: >>(see attached file) >> >>Let's discuss solution 2 first. We should parse java sources by >>ourself using QDox, then parse xml def, finally we structure aop >>domain model by our hand. This solution is better to me first >>impression, because I dream he can avoid "compile phrase". But maybe >>it's my daydream. >> >>And if we refer to solution 1, "compile phrase" has to be involved, >>but we can access aop domain model easily through weaver context. >> >> >>/Jack >> > > >