[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
>>
> 
> 
>