[
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
|
Ron,
I assume the user has AspectJ 1.5 Final.
In which case there should be a verbose message for the generated closure
e.g.:
info AspectJ Weaver Version
1.5.0 built on Tuesday Dec 20, 2005 at 12:05:54 GMT
info register classloader
org.aspectj.weaver.loadtime.WeavingURLClassLoader
info using /C:/workspaces/temp/Classes/bin/META-INF/aop.xml
info using /C:/workspaces/temp/Aspects/bin/META-INF/aop.xml
info register aspect AroundAspect
info weaving 'HelloWorld'
info generating class 'HelloWorld$AjcClosure1'
info weaving 'AroundAspect'
info processing reweavable
type AroundAspect: C:\workspaces\temp\Aspects\src\AroundAspect.aj
AroundAspect.around() call(void java.io.PrintStream.println(String))
Hello World!
As you know the cardinal rule for class
loaders is "cache, parent, disk". Some class loaders e.g. OSGi
redefine "parent" others e.g. Web swap the order of the last
2 but checking the cache first is essential to avoid duplicate class definitions.
I do not believe the WAS JasperLoader breaks this rule. The WAS trace indicates
the closure cannot be found in the cache. We need to find out whether the
closure definition succeeded.
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:
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_______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-dev