Re: classloader issue

Great Jonas,

I will test AspectWerkz for the needs I describe very soon and will give you
my feedback. Just to be clear on what I have in mind, I am trying to play
with class intrumentation at load time in app server. If I succeed in that,
I might succeed in class instrumentation at load time in any (almost any)
J2SE app.

I have already a embrionic project on sourceforge which is more an alpha
stage of what I am trying to do for weblogic using the BEA classPreProcessor
hook described by Bob Lee, author of the JAdvise AOP lightweight framework.
This is not AOP (not yet). http://besee.sourceforge.net/

The classPreProcessor hook allows for ANY class you provide to plug in the
weblogic class loading mechanism to insturment bytecode at load time in the
whole class loader hierarchy of deployed applications (ear, war...).
My embrionic stuff uses Javassist (something "like" BCEL to say it shortly),
which has been a research project for years and is now part of JBoss 4
official thrid parties, used in JBoss AOP.
By the way you should have a look how the field interception is made in
javassist reflection module - very elegant. Seems that JBoss teams chooosed
something similar.

What I like in aspectWerkz is the deployment model (perThread ...) and the
elegant xml stuff. It seems easier to integrate than JBoss AOP stuff. I
don't like the BCEL complexity and the JMangler layer - too heavy. JAdvise
is too light to integrate. Yours seems almost complete, or on the right way
!

What I am trying to have is a AOP framework plugged into weblogic. I would
also like to have aspect xml descriptor whether at server level or at
application level (in ear or ejb-jar or war), like a web.xml file (embrionic
idea). I am targetting weblogic just because I am working everyday with it,
but I would like a framework easyly pluggable in a class loading scheme
supporting class pre processing hook.
I would then like to implement aspect for JMX monitoring off some component
response time, log4j or similar monitoring of the call flow to easily detect
slow portions in dev/integration mode, asynchronous/timeout wrapping of some
third parties calls, limited cache feature, live sequence diagram for fun
(see Bob Lee weblog). I am not targetting aspect for TX management or
persistence mapping - too low level, already covered in app servers.

So here is my short term workplan :
- let the ideas florish as you said...
- give a concrete try to weblogic wrapped in aspectWerkz with JMangler
loader
- keep an eye on JBoss implementation since they are now hosting Javassist,
and they are moving fast
- try to figure if I can make aspectwerkz instrumentation using Javassist -
interesting challenge isn't it ?

Anyway I definetly like your aspectWerkz vision.
More feedback soon.

Alex



"Jonas Bonér" <[email protected]> wrote in message
news:[email protected]...
> Hi Alex.
>
> You are right about the the loading of the methods at startup time. It
> is a bad idea.
>
> I have re-implemented the getMethod(..) method to use lazy loading
> instead. Now it retrieves the methods and builds a repository based on
> the class that it gets from the actual target object. Which is then
> already loaded. So this should be on the safe side. (not commited yet
> thought)
>
> I think that your ideas are really interesting. I havn't had the time to
> think through all the scenarios when it comes to running the weaver
> dynamically in an app server. (But I guess that the post processed code
> would work without any major quirks.)
>
> If you have any suggestions how to implement stuff like you are talking
> about in a good way, they are more than welcome.
>
> Best regards.
> Jonas.
>
>
>
> Pam wrote:
> > Hi
> >
> > I am inspecting how AspectWerkz is done in its internal and I am quite
> > surprised with a portion of code. I am trying to keep in mind that I
want
> > the AOP framework works within an app server ie with hierarchical class
> > loaders.
> >
> > While lurking at AspectWerkz.initialize() which calls
> > AspectWerkz.loadMethods() (in 0.4 src) I understood that the XML
definition
> > is loaded, Aspects are registered and the target classes are immediately
> > loaded to create a method repository and some other internal stuff. The
> > following code in loadMethods gives some tips :
> >
> >         for (Iterator it = advisedClassNames.iterator(); it.hasNext();
i++)
> > {
> >             try {
> >                  advisedClasses[i] = Thread.currentThread().
> >
> > getContextClassLoader().loadClass((String)it.next());
> >             }
> >             catch (ClassNotFoundException e) {
> >                 throw new WrappedRuntimeException(e);
> >             }
> >
> > I am wondering why you are agressively trying to load aspected class
with
> > aspects. I am pretty sure (at least as I understood the sources) that if
I
> > plug aspectWerkz in a servlet container (eg), the aspected struts Action
> > class (eg) will have to be on the server classpath and not only in the
> > web-inf/lib of my deployed sample.war (eg).
> >
> > I assume this is not a JMangler issue since JMangler affects the java
system
> > classLoader to plug in it, so it will indeed affect the classloader
> > hierarchy (we already talk a bit about that thru some emails - I have to
> > check JMangler details about this).
> >
> > Jonas, may be you have some tips or design reason behind this. Any way,
I
> > think thinking a AOP framework with app server class loading scheme in
mind
> > complicates the whole so I hope the subject is interesting (think about
> > having struts deployed in two web-app, with two different struts version
you
> > want to advise differently. If its based on the class full qualified
name it
> > will break, but If I want it to be based on some others things I have to
> > deploy my aspects at each level : webapp and system class loader because
the
> > XML descriptor is not enough., and when you reached the deployment
stage,
> > you have to handle redeploy / undeploy without having memory leaks in
aspect
> > / advices / point-cuts repositories).
> >
> > Any way I will defnitely give a try soon to all those points.
> >
> > Alex
> >
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > aspectwerkz-developer mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/aspectwerkz-developer
> >
> >
>
>
> --
> Jonas
> http://freeroller.net/page/jboner
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf