Re: classloader issue

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