Re: Re: Re: Online mode architecture

AspectWerkz won't be port to other bytecode kit until Q1 2004, even if we
always take care to keep the architecture independant from bytecode kit
(FYI we have a hook for Javassist already).

AspectWerkz has already many dependancies and I don't think its worse to
add a "useless" dependancy for AspectWerkz user (as a whole).

What you can then do is the following:
1/ use aspectwerkz-core.jar as distributed in AspectWerkz
2/ have myImplementation.jar containing ASM ClassLoaderPreProcessorImpl
and related (pbly a ClassPreProcessor Impl)
3/ have myImplementation.jar referencing ASM.jar thru a Manifest
Class-Path entry to ease classpath handling (this will ease the
integration effort if you plan to use a aspectwerkz.(bat|sh) script
(modified one for your needs).

Pros: no "useless" ASM jar in the AspectWerkz tree for AspectWerkz users
(AspectWerkz as a whole AOP framework and not just the hook part).

Cons: less transparent for ASM usage (though in all cases you will have to
adapt wrapper scripts to use the -Daspectwerkz.classloader...=... option
you requires.

I hope you understand that we have to think first to AspectWerkz as a
whole AOP framework and not just as a pluggable and open hook.
Alex



> Alex wrote:
>
>> We don't plan yet to have bytecode kit independance for AspectWerkz as a
>> whole so we won't add asm.jar to the project for now.
>
> So this means I should keep AsmClassLoaderPreProcessorImpl in my own tree?
> FWIW the extra class files would add 5 or 6K to aspectwerkz-core.jar.
>
>> I would rather have this kind of things as separate jars.
>
> I'm not sure what you mean by this.
>
>> Having asm.jar in the project will be the way to go if all the
>> AspectWerkz
>> transformer stack (currently implemented with BCEL) would be ported to
>> ASM
>> (or other bytecode kit as well). But unless someone wish to hack it, it
>> won't be in the todo list until some stage.
>
> I don't think having multiple bytecode implementations will be useful for
> the project as a whole, it would be too hard to keep things in sync
> (perhaps for just the hook it is ok). But I think you may want to think
> about switching from BCEL to ASM entirely, for size and speed reasons. For
> example, my ASM preprocessor is noticeably faster at startup.
>
>> Tips: notice that there is a specific snip to support IBM WSDK in the
>> BCEL..Impl. Could be good to have it as well in ASM implementation
>> (defineClass0 has extra args compared to standard SUN JDK).
>
> I've copied the IBM logic, thanks.
>
> Chris
>
>
> _______________________________________________
> aspectwerkz-devel mailing list
> aspectwerkz-devel-81qHHgoATdGxIXFVlbCvtR2eb7JE58TQ@public.gmane.org
> http://lists.codehaus.org/mailman/listinfo/aspectwerkz-devel
>