| RE: [aspectj-users] WasWeaving and still am |
|
Hi Bo, Thanks for the positive feedback about the
plugin. I’m glad you are finding it useful. Thanks also for the feedback
on the instructions I wrote. Some responses to your questions follow below: From:
aspectj-users-bounces@xxxxxxxxxxx [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of bo.zimmerman@xxxxxxxxxxxxxxxxxxxxx Hello all, I've been doing a bit of aspectj work in Websphere 5.1 and Websphere 6+
and thought I would offer you all a few of my observations and all of my
subsequent confusion. But before that -- Kudos to Mr. Bodkin. WasWeavingPlugin works
wonderfully on all versions of Websphere I've tried. You da man. And now my observations and questions regarding the source
link/instructions for WasWeavingPlugin: Step 3 instructs us to add the following to Websphere's server.xml: <systemProperties xmi:id="Property_9927324365996"
name="java.rmi.server.codebase" ... However, I've noticed that Plants By Websphere, the sample web app
included with WebSphere, inexplicably throws an exception on order submission
when this line was included, but remains perfectly happy without it. Leaving
out this line appeared to have no affect on my other load-time weaving
endeavors, which consisted primarily of pointcuts on do* methods of the
HttpServlet variety, and getConnection() methods of the java JDBC Datasource
variety. Obviously I'm happy not to rock my own boat, but I'm wondering if
someone can explain what that line was supposed to accomplish? Should I fear
its removal? Am I asking for trouble down the road? This property is generally used to allow RMI
clients (such as EJB clients) to read code from a given URL location. I wonder
if the error you are seeing in Plants by WebSphere relates to some conflict
whereby setting this is overriding some OTHER code that should be in the RMI
server codebase. The case where this would be necessary is where you are
weaving into types that are transferred by RMI, such as DTO’s. If you are
weaving locally into a single container, it shouldn’t be a problem to not
include this setting. I know that when I built the plugin, we used it for a
distributed project with Web and EJB components. Ok, one last thing! Step 4 instructs us to remove the 1.2 aspectjrt.jar included with
WebSphere 6.0.2 (not 6.0 as the page suggests) and replace it with a good and
nifty better one. Obviously I'm doing loadtime weaving, and I do use aspectj
1.5 at the moment (upgrade is pending). As the instructions suggest, my 1.5
aspectjweaver.jar is plugged right into the Websphere classpath. However, even
if I *don't* touch the antique runtime library, my aspects all seem to work
fine. Am I just lucky, or is aspectjweaver.jar blocking out the decrepit old
1.2 version? Is this step necessary, or was it listed more as a precaution?
Some Advice here would be appreciated (and yes, a pun was most certainly
intended). There are some cases where the AspectJ 1.2.x
runtime library has bugs or lacks features that might be required by an AspectJ
1.5 program. AspectJ 1.5’s runtime library was reworked to add support
for Java 1.5, but also I believe that some improvements and enhancements were
made. If as I’d expect you are not running on Java 1.5, there are fewer
such features. I know I discovered this issue because of some of these changes.
One thing to investigate is which has a higher priority on the classpath: the aspectjrt.jar
that comes with WebSphere or the system classpath entry for the aspectjweaver.jar
plugin. It may turn out that the aspectjweaver.jar is higher priority and since
it now includes the contents of aspectjrt.jar, it may simply be overriding the builtin
WebSphere aspectjrt.jar. Remember that these instructions were written 6 months
ago before AspectJ 1.5.0, so some details might have changed a bit (e.g., I don’t
think aspectjweaver.jar included aspectjrt.jar at that time). Thanks for any response! - Bo
Zimmerman |