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 ??).
http://tomcat.apache.org/tomcat-5.5-doc/jasper/docs/api/org/apache/jasper/servlet/JasperLoader.html
- 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
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
_______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-dev