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