Re: Re: classloader issue

Hi
You re right, it is an important issue.

From what I read in JMangler src 3.x, it requires java 1.4 and it patchs the
java.lang.ClassLoader using class hot swaping features of java 1.4. If I
explain that to a customer classloader, I might afraid him and he might
reply I am modifying Sun code which might cause him some trouble.

From what I read in JMangler 2.x, it runs with java 1.3 and makes use of jvm
Xbootclasspath option to provide a kind of parralel class loading scheme:
the target app (customer class loader) is loaded by a wrapper script (a
main), which intercepts the class loading flow (this JMangler class loader
is thus a kind of substitution to the java System class loader). I think
this technique is largely used by debugging products (OptimizeIt, JProbe
like).

Since then the modified class loader will be the parent of the "customer"
class loader, and even will load it, it can add the needed hook.

In both case the class loader hierarchy is interfered with the standard way.
This has nothing to deal with the bytecode instrumentation solution adopted.
The point is Javassist does not provide such a hook, and *I* find JMangler
use too heavy for just this purpose. A light class preprocessor based
solution (on interface) with JMangler like class loading scheme (caution
about security issue - don't know if have to deal with or if bootsrap class
loader will) would be a good starting point to provide a ligthweight
universal low level way of pluging AOP.
Other option: make the customer add the 50 lines needed to plug class
preprocessing hook in its own home made class loader. Could be for open
source stuff.

Hope this helps to understand how the magic is done.
On a similar topic look on the JBoss dev AOP forum for post about how
instrumenting java.* class can be done / should be done / is worth to be
done.

Alex

"é?涓€å¦?" <[email protected]> wrote in message
news:[email protected]...
> Hi Pam:
> In order to modify bytecode dynamicly,Javassist seems must use customer
> classloader .
> If we use classloader mechanism provided by application server vendor
> ,JavaAssist should be sufficient.So AOP Framework for WebLogic would be OK
> and AOP Framework for JBOSS would be OK.
> But for a general purpose AOP framework, How can JavaAssist customer
> classloader(provided by AOP framework) deal with other customer
classloader
> provided by app server(and other applications which provide their own
> classloader)?
> Regards
> Shiyiying
>
>
>
> >From: "Pam" <[email protected]>
> >To: [email protected]
> >Subject: [aspectwerkz-developer] Re: classloader issue
> >Date: Wed, 23 Apr 2003 22:04:12 +0200
> >
> >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
> >_______________________________________________
> >aspectwerkz-developer mailing list
> >[email protected]
> >https://lists.sourceforge.net/lists/listinfo/aspectwerkz-developer
>
>
> _________________________________________________________________
> ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger:  http://messenger.msn.com/cn
>
>
>
> -------------------------------------------------------
> 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