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

Hi
1/ Yes, we are using serialization. I don't know other way.

2/ This allows to define a class without having it in a concrete file in the
given classloader classpath. That is define an "on the fly" generated class,
generated from nothing (like a dynamic proxy somehow, or an ejb stub
sometimes etc).

3a/ JITCompiler is used in 1.0 and allows JustInTime join point compilation.
AW 1.0 is using this to have only a single point of reflection in the
system: when the JIT generated join point is called from the join point
location in the weaved class. This means that advice methods etc are not
called thru reflection.

3b/ JoinPointCompiler is a work in progress and enhance further this idea.
It won't be used in 1.0 but in the next one.

4/ Not at all. If I am correct, AspectJ is not using a dedicated class to
embed the join point logic but is inlining that in the weaved class(es).
There inlining is more agressive somehow, but makes all dynamic AOP features
very hard - if not impossible - to achieve at the framework level. We plan
that our new architecture (after 1.0) will f.e.
- really remove all reflection
- allow us to do on the fly replacement of join point when a new advice is
added, a new aspect is added
- better on the fly weaving of user classes, when a new join point is
defined
- improved startup time with offline compilation since it will be possible
to "package" the JIT join point as well to avoid to have them generated at
target class <clinit> time
- etc
The AJ way is more or less the code that you will wrote by hand if you were
not using AOP. We will keep some minimal layering.

Question: why do you need to dig that much in AW. Are you driving some sort
of comparison ? 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 ?

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.

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