Hi Matthew,
I had Aaron (the user in question) try it
again with my own custom built version of AspectJ 1.5 that has more info
messages, and with AspectJ 1.5.0 final also (he was using my experimental
memory optimized LTW version… this part of the code was the same… ).
I explicitly logged all cases in the ClassLoaderWeavingAdaptor class (see code
below). Interestingly, it shows that the definition is clearly working (unless
Aaron made a mistake somehow). It looks like I am stuck without a way to debug
this and Aaron has given up.
[1/30/06 12:19:26:418 CST] dcc6f99
SystemErr R info weaving 'org.apache.jsp._Collection'
[1/30/06 12:19:26:543 CST] dcc6f99 SystemErr R
weaveinfo Join point 'method-call(void
javax.servlet.jsp.PageContext.handlePageException(java.lang.Throwable))' in
Type 'org.apache.jsp._Collection' (Collection.jsp :40) advised by
afterReturning advice from
'glassbox.inspector.monitor.operation.ServletMonitor' (ServletMonitor.aj:73)
[with runtime test]
[1/30/06 12:19:26:606 CST] dcc6f99 SystemErr R
weaveinfo Join point 'method-execution(void
org.apache.jsp._Collection._jspService(javax.servlet.http.HttpServletRequest,
javax.servlet.http.HttpServletResponse))' in Type 'org.apache.jsp._Collection'
(Collection.jsp ) advised by around advice from 'glassbox.inspector.monitor.operation.ServletMonitor'
(AbstractOperationMonitor.aj:93) [with runtime test]
[1/30/06 12:19:26:606 CST] dcc6f99 SystemErr R
weaveinfo Join point 'method-execution(void
org.apache.jsp._Collection._jspService(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse))'
in Type 'org.apache.jsp._Collection' (Collection.jsp ) advised by around
advice from 'glassbox.inspector.monitor.operation.ServletMonitor'
(ServletMonitor.aj:87)
[1/30/06 12:19:26:684 CST] dcc6f99 SystemErr R
info generating class 'org.apache.jsp._Collection$AjcClosure1'
[1/30/06 12:19:26:684 CST] dcc6f99 SystemErr R
info successfully defined class
defineClass.invoke(loader,
new Object[] { name, bytes,
new
Integer(0), new Integer(bytes.length) });
//Added test code:
try
{
//
debug
Class
theClass = loader.loadClass(name);
if
(theClass != null) {
info("successfully
defined class");
}
else {
if
(loader.getParent() == null || loader == ClassLoader.getSystemClassLoader()) {
warn("failed
to define class!! No relevant loader to try");
}
else {
warn("failed
to define class!! Trying parent loader");
defineClass(loader.getParent(),
name, bytes);
info("parent
define returned normally");
}
}
}
catch (Throwable t) {
warn("Problem
in debug code for define class", t);
}
}
catch (InvocationTargetException e) {
if
(e.getTargetException() instanceof LinkageError) {
warn("define
generated class failed",e.getTargetException());
//is
already defined (happens for X$ajcMightHaveAspect interfaces since aspects are
reweaved)
//
TODO maw I don't think this is OK and
}
else {
warn("define
generated class failed",e.getTargetException());
}
}
catch (Exception e) {
warn("define
generated class failed",e);
}
catch (Throwable t) {
warn("define
generated class failed",t);
}
From:
aspectj-dev-bounces@xxxxxxxxxxx [mailto:aspectj-dev-bounces@xxxxxxxxxxx] On Behalf Of Matthew Webster
Sent: Friday, January 27, 2006
3:38 AM
To: AspectJ
developer discussions
Subject: RE: [aspectj-dev] Problem
with Load Time Weaving with WebSphere5.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
