Re: AlRe: [Fwd: Re: [aspectwerkz-dev] Creating AOPified javadocs]

Hi!

Jonas can you please check the Creating AOPified javadocs thread and let me know about your 
opinions. I want to get started with this and I have waited for you and Mik to come back and tell me 
your insights.


./the_mindstorm

Quote [the_mindstorm]:

> First of all thank you very much for the answers and for the time put in 
> answering.
> 
> Quote Alex::
> 
>> Question: why do you need to dig that much in AW. Are you driving some 
>> sort
>> of comparison ?
> 
> 
> I try to understand the full power behind the scenes. For the moment, 
> even if the AspectJ seems to me to be the most used I guess that the 
> full adoption will come from a pure java solution (my 2cent about 
> management heads - and some experience behind this ;-) )
> 
> Another reason would be the lack of technical insights on AOP (a few 
> papers - in fact, I have just one, and some discussions on mail lists). 
> I have almost always considered the code as the best documentation.
> 
>> Are you planning to build an add-on product on it that
>> requires deep knowledge on it ? Do you plan to write a paper at AOSD 
>> 05 on
>> the weaver architecture of AJ/AW/JBoss ?
> 
> 
> Not for the moment, as I do not consider myself an enough knower of AJ 
> and AW.
> However, the 1st AOP contact was with JBoss and I didn't agree with 
> their interception - aop confusion (I am not sure if they move along this).
> 
>>
>> PS: I don't like to give architecture insight since it is a moving 
>> target,
>> so all that things may change within 2 months if some new good idea 
>> emerge
>> ;-) AW architecture is probably in its 5th or 6th iteration - at least.
> 
> 
> Here you almost touched another reason I love to dig into AW (maybe some 
> good idea will emerge ;-) ).
> I will try to restrict/reduce my questions in the future :-(.
> 
> ::the_mindstorm
> 
>>
>> Alex
>>
>>
>> ----- Original Message -----
>> From: "the_mindstorm" <[email protected]>
>> To: <[email protected]>
>> Sent: Saturday, August 28, 2004 3:29 AM
>> Subject: Re: AlRe: [Fwd: Re: [aspectwerkz-dev] Creating AOPified 
>> javadocs]
>>
>>
>>
>>> Quote Alex::
>>>
>>>
>>>> In Tiger, annotations are not in javadoc and are strong typed thru the
>>
>>
>> help
>>
>>>> of an interface.
>>>>
>>>> @Before(myPointcut)
>>>> public void myBeforeAdvice(...)
>>>>
>>>> java sources with javadoc + javac compiled + AW AnnotationC tool
>>
>>
>> generates
>>
>>>> new class files (offline)
>>>> just as
>>>> java sources with annotations + javac Tiger compiled class files
>>>>
>>>> produce class files where annotations are represented in the bytecode.
>>>
>>>
>>> I went to code to better understand this. As far as i get it, 
>>> AdviceInfo-s
>>
>>
>> are added as attributes
>>
>>> at allowed/interesting points. What I am not sure I understood is the
>>
>>
>> following:
>>
>>> according to JVM spec the attribute struct is
>>>
>>> attribute_info {
>>>     u2 attribute_name_index;
>>>     u4 attribute_length;
>>>     u1 info[attribute_length];
>>> }
>>>
>>> it seems to me that info is just a byte array and you use this for
>>
>>
>> serializing AdviceInfo?
>>
>>>
>>> 2. This is a separate question. In AsmHelper.loadClass(ClassLoader,
>>
>>
>> byte[], String) you are using a
>>
>>> loader to load ClassLoader and than invoke its defineClass method. 
>>> Why are
>>
>>
>> you using this mechanism?
>>
>>> (In order to simulate the CL hierarchy?)
>>>
>>> 3. I saw the above method is used in 2 different compilers 
>>> JitCompiler and
>>
>>
>> JoinPointCompiler?
>>
>>> Where are these used? (I guess they are used at classloading for 
>>> weaving,
>>
>>
>> ain't it?). What is the
>>
>>> difference between 'em and in which of the situation are used?
>>>
>>> 4. I am reading now the Advice Weaving in AspectJ (Hilsdale & Hugunin).
>>
>>
>> The inline weaving you are
>>
>>> working on will look like the described solution used by AspectJ?
>>>
>>> ::the_mindstorm
>>>
>>> PS: I hope that I am not bothering too much with this kind of questions
>>
>>
>> (but I am trying to get an
>>
>>> inside view
>>>
>>>> Alex
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>> From: "Jack Tang" <[email protected]>
>>>> To: <[email protected]>
>>>> Sent: Friday, August 27, 2004 6:09 PM
>>>> Subject: Re: [Fwd: Re: [aspectwerkz-dev] Creating AOPified javadocs]
>>>>
>>>>
>>>>
>>>>
>>>>> <Quote>
>>>>>
>>>>>>> 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
>>>>
>>>>
>>>>> </Quote>
>>>>> How about Tiger's javadoc? How does he solve *annotation* in javadoc?
>>>>>
>>>>> P.S: I am a stranger to Tiger
>>>>>
>>>>> /Jack
>>>>>
>>>>>
>>>>>
>>>>> On Fri, 27 Aug 2004 18:59:40 +0300, the_mindstorm
>>>>> <[email protected]> wrote:
>>>>>
>>>>>
>>>>>> 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.
>>
>>>>>>
>>>>> c
>>>>>
>>>>>
>>>>>> 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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>
>>
>>
> 
>