<aspectj>
<aspects>
<concrete-aspect name="com.XXX.YYY.governor.aspects.ConcreteGovernor"
extends="com.XXX.YYY.governor.aspects.AbstractGovernor
">
<pointcut name="..." _expression_="..."/>
</concrete-aspect>
</aspects>
</aspectj>
Is this correct? If so my suggestion
was to replace the aop.xml definition (which results in an aspect and hence
a class being generated at runtime) with a concrete aspect defined using
code. You can still use LTW which given the complex structure of your application
seems like the best approach.
If possible you might like to define
a META-INF/aop.xml in the problematic WAR file that just turns on some
extra debug information:
<aspectj>
<weaver
options="-debug -verbose"/>
</aspectj>
Matthew Webster
AOSD Project
Java Technology Centre, MP146
IBM United Kingdom Limited
Hursley Park, Winchester, SO21 2JN, England
Telephone: +44 196 2816139 (external) 246139 (internal)
"Macon Pegram"
<mpdisposal@xxxxxxxxxxx>
Sent by: aspectj-users-bounces@xxxxxxxxxxx
26/03/2007 18:10
|
Please respond to
aspectj-users@xxxxxxxxxxx |
|
|
To
| aspectj-users@xxxxxxxxxxx
|
|
cc
|
|
|
Subject
| RE: [aspectj-users] Scoping or Weaving
problem (???) with LTWin anEARon a WAR |
|
Matthew,
Are you suggesting trying "static" weaving? Ron Difrango
recommended a
similar approach in some side conversations we've had. I'm working
on
putting together a test build script right now that explodes our EAR and
does the static weaving. I've created code based concrete aspects
(extending the abstract Aspect and providing pointcuts).
I've kind of bought in to the need to do static instead of load time weaving
for my particular application, but I'd still like to understand the obstacle
I've run into. I've done a little classloader research and
found the
following:
Files in .WAR are loaded by a classloader 1 level deeper than those that
are
at the EAR level (which I expected).
Here's the dump (Each * represents the number of classloader layers that
would need to be traversed to reach it):
EAR Level class
---------------------
* weblogic.utils.classloaders.GenericClassLoader@25b8af2( finder:
weblogic.utils.classloaders.CodeGenClassFinder@25b8b65, annotation:
simpleportal@, parent:
weblogic.utils.classloaders.GenericClassLoader@1b4d2ad( finder:
weblogic.utils.classloaders.CodeGenClassFinder@1b4d320, annotation:
ApplicationClassLoader@, parent:
weblogic.utils.classloaders.GenericClassLoader@17cce51( finder:
weblogic.utils.classloaders.CodeGenClassFinder@17cd88e, annotation: null,
parent: sun.misc.Launcher$AppClassLoader@1d05a1)))
** weblogic.utils.classloaders.GenericClassLoader@1b4d2ad( finder:
weblogic.utils.classloaders.CodeGenClassFinder@1b4d320, annotation:
ApplicationClassLoader@, parent:
weblogic.utils.classloaders.GenericClassLoader@17cce51( finder:
weblogic.utils.classloaders.CodeGenClassFinder@17cd88e, annotation: null,
parent: sun.misc.Launcher$AppClassLoader@1d05a1))
*** weblogic.utils.classloaders.GenericClassLoader@17cce51( finder:
weblogic.utils.classloaders.CodeGenClassFinder@17cd88e, annotation: null,
parent: sun.misc.Launcher$AppClassLoader@1d05a1)
**** sun.misc.Launcher$AppClassLoader@1d05a1
***** sun.misc.Launcher$ExtClassLoader@1ce2ad
WAR Level class
-------------------
* weblogic.utils.classloaders.GenericClassLoader@266e282( finder:
weblogic.utils.classloaders.CodeGenClassFinder@266e309, annotation:
simpleportal@1_0, parent:
weblogic.utils.classloaders.GenericClassLoader@25b8af2( finder:
weblogic.utils.classloaders.CodeGenClassFinder@25b8b65, annotation:
simpleportal@, parent:
weblogic.utils.classloaders.GenericClassLoader@1b4d2ad( finder:
weblogic.utils.classloaders.CodeGenClassFinder@1b4d320, annotation:
ApplicationClassLoader@, parent:
weblogic.utils.classloaders.GenericClassLoader@17cce51( finder:
weblogic.utils.classloaders.CodeGenClassFinder@17cd88e, annotation: null,
parent: sun.misc.Launcher$AppClassLoader@1d05a1))))
** weblogic.utils.classloaders.GenericClassLoader@25b8af2( finder:
weblogic.utils.classloaders.CodeGenClassFinder@25b8b65, annotation:
simpleportal@, parent:
weblogic.utils.classloaders.GenericClassLoader@1b4d2ad( finder:
weblogic.utils.classloaders.CodeGenClassFinder@1b4d320, annotation:
ApplicationClassLoader@, parent:
weblogic.utils.classloaders.GenericClassLoader@17cce51( finder:
weblogic.utils.classloaders.CodeGenClassFinder@17cd88e, annotation: null,
parent: sun.misc.Launcher$AppClassLoader@1d05a1)))
*** weblogic.utils.classloaders.GenericClassLoader@1b4d2ad( finder:
weblogic.utils.classloaders.CodeGenClassFinder@1b4d320, annotation:
ApplicationClassLoader@, parent:
weblogic.utils.classloaders.GenericClassLoader@17cce51( finder:
weblogic.utils.classloaders.CodeGenClassFinder@17cd88e, annotation: null,
parent: sun.misc.Launcher$AppClassLoader@1d05a1))
**** weblogic.utils.classloaders.GenericClassLoader@17cce51( finder:
weblogic.utils.classloaders.CodeGenClassFinder@17cd88e, annotation: null,
parent: sun.misc.Launcher$AppClassLoader@1d05a1)
***** sun.misc.Launcher$AppClassLoader@1d05a1
****** sun.misc.Launcher$ExtClassLoader@1ce2ad
Any thoughts on an explanation?
Macon
>From: Matthew Webster <matthew_webster@xxxxxxxxxx>
>Reply-To: aspectj-users@xxxxxxxxxxx
>To: aspectj-users@xxxxxxxxxxx
>Subject: RE: [aspectj-users] Scoping or Weaving problem (???) with
>LTWin
anEARon a WAR
>Date: Mon, 26 Mar 2007 08:49:08 +0100
>
>Macon,
>
>This might be a problem with the <concrete-aspect> feature of
aop.xml.
>Could you try defining your aspect using code instead?
>
>Matthew Webster
>AOSD Project
>Java Technology Centre, MP146
>IBM United Kingdom Limited
>Hursley Park, Winchester, SO21 2JN, England
>Telephone: +44 196 2816139 (external) 246139 (internal)
>
>
>
>"Macon Pegram" <mpdisposal@xxxxxxxxxxx>
>Sent by: aspectj-users-bounces@xxxxxxxxxxx
>22/03/2007 18:02
>Please respond to
>aspectj-users@xxxxxxxxxxx
>
>
>To
>aspectj-users@xxxxxxxxxxx
>cc
>
>Subject
>RE: [aspectj-users] Scoping or Weaving problem (???) with LTW in anEARon
a
>WAR
>
>
>
>
>
>
>Ron,
>
>I realized shortly after posting the question that I had left some
details
>
>out.
>
>The JAR containing the aspect is actually at the EAR level. The
>exceptions
>from the original posting actually occurred with that configuration.
>
>I've tried putting it at both the EAR and the WAR level and it
balked
>about
>having 2 copies of the Concrete aspect. There is a possible
(but nasty)
>solution where I could create 2 variations of the aspect jar with
>different
>concrete definitions in aop.xml.
>
>I have not tried putting it at the container level yet. Again,
an
>approach
>I'd prefer to avoid if possible, but I'm not completely adverse to
it.
>
>Right now I'm trying to get an understanding of why this is happening
and
>that may illuminate the way to a solution.
>
>Macon
>
>_________________________________________________________________
>5.5%* 30 year fixed mortgage rate. Good credit refinance. Up to 5 free
>quotes - *Terms
>https://www2.nextag.com/goto.jsp?product=100000035&url="">
>
>
>_______________________________________________
>aspectj-users mailing list
>aspectj-users@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>
>
>
>
>
>
>Unless stated otherwise above:
>IBM United Kingdom Limited - Registered in England and Wales with number
>741598.
>Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
PO6 3AU
>
>
>
>
>
>_______________________________________________
>aspectj-users mailing list
>aspectj-users@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/aspectj-users
_________________________________________________________________
Exercise your brain! Try Flexicon.
http://games.msn.com/en/flexicon/default.htm?icid=flexicon_hmemailtaglinemarch07
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
