Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [aspectj-dev] Problem with Load Time Weaving with WebSphere 5.1JasperLoader

Hi Matthew,

 

I initially suspected that too so I had asked the user to turn on verbose weaving info, but there was no warning like this in the log. I will go back and ask the user to double check for this error. I’m also doubtful that it’s a security issue because the inspector is (currently) using the worker object pattern and generating closures, but for all the other class loaders (for Servlets, etc.) it works properly. Surely if the code didn’t have permission to make this call on one loader, it wouldn’t have permission on any loaders. It would be nice if you or someone with access to WAS 5.1 could test whether its JasperLoader chokes on around advice closures, to verify this too (e.g., by installing the Glassbox Inspector beta and hitting a JSP in a sample Web app or just writing a simple around advice with runnable that logs & proceeds).

 

Given that the data suggests it wasn’t a security violation, it sure seems to me like the WAS JasperLoader is performing a check of the on disk bytecodes even though the class was already defined. This is quite unexpected behavior and seems to violate the implied contract that a class loader will check for a class already being defined before redefnining it, but perhaps the jasper loader “knows” the class isn’t in use so it is trying to give the ability to recompile from updated sources. In the case of the JasperLoader, I’m pretty sure from the detailed logs that it is handling JSP code in a special fashion.

 

While extending the classloader with a callback wouldn’t work here, I could definitely imagine having a registered call back in a delegate that receives the classes. E.g., it could do something ugly like write them to disk in the right location … although it wouldn’t surprise me if the same class loader would assume “there’s no generated Java source here any more, so this class file is stale and needs to be removed”

 

I certainly agree that it’s better to avoid generating closures … there are some nice software engineering properties of the worker object pattern, so we have been using it, but it does add some overhead and expose us to some worse integration issues, like this. I am planning to change the architecture of the Glassbox Inspector to not use the worker object pattern, although I’d like to fix this issue without having to make a big change like that…

 


From: aspectj-dev-bounces@xxxxxxxxxxx [mailto:aspectj-dev-bounces@xxxxxxxxxxx] On Behalf Of Matthew Webster
Sent: Wednesday, January 25, 2006 9:35 AM
To: AspectJ developer discussions
Subject: Re: [aspectj-dev] Problem with Load Time Weaving with WebSphere 5.1JasperLoader

 


Ron,

This might be due to the problem we have defining closures classes generated during the weaving process. To try and make the process transparent well call ClassLoader.defineClass() in ClassLoaderWeavingAdaptor but it is a protected method so must be called using reflection. This can fail due to security restrictions: look for warning of the form "define generated class failed ..." in the log. Can you change the security policy or package aspectjweaver.jar with the rest of the server runtime? An alternative approach is for the class loader concerned to register a callback to receive the closure classes which it can define when need. I don't think this will be possible in this case. The final solution is to avoid generating closures: inlining should be the default so you may have to change your around advice or use before/after if possible.

Matthew Webster
AOSD Project
Java Technology Centre, MP146
IBM Hursley Park, Winchester,  SO21 2JN, England
Telephone: +44 196 2816139 (external) 246139 (internal)
Email: Matthew Webster/UK/IBM @ IBMGB, matthew_webster@xxxxxxxxxx

http://w3.hursley.ibm.com/~websterm/

Please respond to AspectJ developer discussions <aspectj-dev@xxxxxxxxxxx>

Sent by:        aspectj-dev-bounces@xxxxxxxxxxx

To:        "'AspectJ developer discussions'" <aspectj-dev@xxxxxxxxxxx>
cc:        
Subject:        [aspectj-dev] Problem with Load Time Weaving with WebSphere 5.1        JasperLoader


Hi There,
 
A couple of Glassbox Inspector users have been running into problems using AspectJ 5 load-time weaving on WebSphere 5.1. This same set of aspects has worked well in Tomcat, oc4j, and the aspects work in BEA (JMX Remote is another question…)
 
In a nutshell, it looks to me like the WebSphere 5.1 JasperLoader for JSP’s is looking for the .class file on disk even after the ClassLoaderWeavingAdaptor has defined the bytes of a generated closure in memory. Does anyone out there have any experience trying to use AspectJ 5 with around advice that generates closures for this system? It seems bizarre that a class loader would look for the .class file for a class that’s already been defined!
 
Unfortunately, I don’t currently have access to WebSphere so I can’t try it out, but I’ve had two users report this same issue. There’s more detail in this thread on our support forum, which shows the evidence so far: http://www.glassbox.com/forum/forum/viewthread?thread=15  For that matter, does it work properly on WebSphere 6?
 
Ron_______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-dev


Back to the top