[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

Another question might be the difference between creating the bytecode and actually resolving/defining the class,
esp. with cycles.  Given class C and aspect A advising C with a closure, I wonder if when defining C (C not yet
in the cache) and loading A (refered-to by C, and referring to C?), A fails to load b/c C cannot be found (and is
sought on disk while it is being defined but hasn't been put in the cache).  If I remember, we decided LTW would
do the right thing wrt cycles (as class-loading does), but only if the scheme to delegate upwards first was
enforced.  One way to test would be to define such a cycle using Java/c. 
(Mind you, this is my memory, not my analysis, and I'm inclined to believe it's not IBM's code's fault because
someone would have found it, neh?  Also, half the time I hazard a complex analysis, it's something dead simple.) 
------------Original Message------------
From: "Ron Bodkin" <rbodkin@xxxxxxxxxxxxxx>
To: "'AspectJ developer discussions'" <aspectj-dev@xxxxxxxxxxx>
Date: Thu, Jan-26-2006 9:39 AM
Subject: RE: [aspectj-dev] Problem with Load Time Weaving with WebSphere 5.1JasperLoader

Hi Wes,

One of the users who reported this problem was able to turn on some useful classloading tracing in WebSphere, and it shows that for the generated closure class the jasper loader is:

  1. looking for the .class file resource on disk
  2. delegating upwards to its parent loader to try and find the class

This behavior suggests that for this user, the loader isnât delegating upwards, even though the parent first option is set in WebSphere (i.e., this supports your analysis).

However ,findLoadedClass should find the generated closure class that was defined during weaving before delegating to the parent, i.e., it should already be defined in memory, and not in the on-disk repository.

Given the check for .class files as a resource and the extra logging information available, Iâm pretty confident that the WebSphere 5.1 JasperLoader is quite customized from the open source Apache versionâ

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


Also, perhaps check the IBM initializes (its version of?) JasperLoader to delegate upwards before checking the local repositories.  This might be different from the websphere PARENT_FIRST option (being set in com.ibm.ws.classloader.J2EEApplicationMode or ??). 



  • Call findLoadedClass(String) to check if the class has already been loaded. If it has, the same Class object is returned.
  • If the delegate property is set to true, call the loadClass() method of the parent class loader, if any.
  • Call findClass() to find this class in our locally defined repositories.
  • Call the loadClass() method of our parent class loader, if any.

If the class was found using the above steps, and the resolve flag is true, this method will then call resolveClass(Class) on the resulting Class object.



------------Original Message------------

From: Matthew Webster <matthew_webster@xxxxxxxxxx>

To: "AspectJ developer discussions" <aspectj-dev@xxxxxxxxxxx>

Date: Wed, Jan-25-2006 9:35 AM

Subject: Re: [aspectj-dev] Problem with Load Time Weaving with WebSphere 5.1 JasperLoader


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


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

Sent by:        aspectj-dev-bounces@xxxxxxxxxxx

To:        "'AspectJ developer discussions'" <aspectj-dev@xxxxxxxxxxx>
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?
aspectj-dev mailing list

aspectj-dev mailing list

aspectj-dev mailing list