[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-dev] RE: aop.xml exclude loader (was [aspectj-users] problems with loadtime weaving and rmi communication)


Ron,

> ... one of the primary uses of aop.xml files is to configure which aspects apply to which ClassLoaders.
Nope. There is no reliable way to associate an aop.xml file exclusively with the classes defined by a particular class loader. There should be 3 types of aop.xml file:
1. Associated with an aspect or aspects. This can be generated by the tools and simply declares which aspects exist
2. Associated with an application, component or set of classes. The best use case is the <concrete-aspect> element that allows you to customize an abstract aspect. You may also add include/exclude elements in both the <aspects> and <weaver> sections but their use is problematic at this level because they affect all classes defined in that branch of the class loader hierarchy. Typically people writing applications either have no knowledge or desire to have knowledge of class loader hierarchies, and certainly should not have to understand them to write and deploy an AO program which must behave the same wherever or however it is run. The expert user that does understand how a particular platform is implemented can pragmatically use include/exclude for certain applications.
3. Associated with the system. This can be added to the server classpath and will affect everything. It is a useful mechanism to guarantee certain classes are not woven, request verbose messages and byte-code dumps or switch off weaving globally e.g. <aspects exclude="*"/>. It can also be used to customize LTW for integration purposes e.g. define a message handler or perhaps IWeavingContext as suggested below.

I don't quite understand your 2) below but it does illustrate the complexity of the J2EE environment, a situation that I don't think will be helped by adding configuration to AspectJ that refers to it. However I do understand your concerns about performance and tailoring AspectJ to different environments. This is why I think the IWeavingContext is the right approach.

Cheers

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] RE: aop.xml exclude loader (was [aspectj-users]        problems with loadtime weaving and rmi communication)


While I agree with you Matthew that there’s scope for misuse in using an aop.xml file to exclude ClassLoaders from weaving, one of the primary uses of aop.xml files is to configure which aspects apply to which ClassLoaders. I don’t see why deploying an aop.xml file with aspect exclusions is any less fragile or potentially error prone than scattering aop.xml files across a ClassLoader hierarchy.
 
I think there are really two issues here:
 
1)       Having better server-specific integration. For that, I agree completely with you that it would be better to define a way of customizing the weaving agent, e.g., a tailored IWeavingContext.
2)       Disabling costly but unneeded weaving. For example, many app servers create 1 ClassLoader per JSP. If you write aspects in a Web application that don’t affect JSPs, it can be a major memory and performance hit to weave into each of these JSP loaders. It would be even worse to never weave into the JSP loaders for integration purposes (since this can be required for some aspects!), but it is quite valuable to not have to weave if no aspects apply. JSP ClassLoaders are supposed to see the same class files as the Web application, so there’s no place to deploy an aop.xml file to exclude the aspects.
 
Naturally, the best thing is to smoothly support #2, so you can have a small memory and performance overhead when weaving into a lightweight ClassLoader. But until we’re there, I think we need to provide options to users.
 




From: Matthew Webster [mailto:matthew_webster@xxxxxxxxxx]
Sent:
Monday, March 13, 2006 7:08 AM
To:
Wes Isberg; rbodkin@xxxxxxxxxxxxxx
Cc:
aspectj-dev@xxxxxxxxxxx
Subject:
aop.xml exclude loader (was [aspectj-users] problems with loadtime weaving and rmi communication)

 

Wes,


You are correct. The primary purpose of aop.xml is to declare, because in general they cannot be discovered, and define the set of aspects to be used for weaving. The syntax deliberately does not use any sort of path (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=93320) or class loader  information because it would be fragile.The file's secondary purpose is a means of passing compiler options. The remaining include/exclude configuration is not intended as an extension to the pointcut language but as tactical measure to be used by administrators (who may not have understanding of AOP and AspectJ) to exclude certain aspects or certain classes in a particular system. The AspectJ approach to AOP is to use a type-checked language rather than a bunch of configuration files.


However I do understand the need to deal with performance issues. I just don't think aop.xml is the right place to do it. I am sure excluding a class loader would never be recommended as a way to determine whether the types it loads are woven but I can guarantee that's what it would be used for! There is another mechanism which I have already used when integrating AspectJ LTW with OSGi: IWeavingContext. An implementation can be supplied when the WeavingAdaptor is created and it allows the set of aop.xml files that are visible to be filtered. I could imagine using a server specific weaving context that excluded class loaders from weaving by returning an empty list of files.


I think this is an integration rather a configuration problem. The LTW agent is general purpose and will work (reasonable well) in any environment (i.e. application server). However it might need to be tailored - send messages to a platform-specific console or exclude certain class loaders from weaving - which should be done somewhere other than aop.xml.


BTW I think this discussion belongs on aspectj-dev.


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 Wes Isberg <wes@xxxxxxxxxxxxxx>; Please respond to aspectj-users@xxxxxxxxxxx

Sent by:        aspectj-users-bounces@xxxxxxxxxxx

To:        aspectj-users@xxxxxxxxxxx
cc:        
Subject:        
RE: [aspectj-users] problems with loadtime        weavingand        rmicommunication


Are there times you'd want to exclude a loader that you couldn't specify it in terms of types?

 
Granted, AspectJ isn't good at saying "oh yeah, and don't advise/extend these types" so doing it that way would be a hassle involving changing lots of aspects, but it makes me nervous to think e.g. that an implementation of an interface loaded in one class loader is modified but not an implementation loaded in another class loader, when we're declaring members on that interface.  I suppose it's possible that class loaders are part of the programming model in J2EE (yuck!), so it might make sense to developers.

 
I could be wrong, but last I heard the exclusions/controls in AOP.xml were intended to make it

easier for the class loader to find aspects and skip unaffected classes.  I didn't think they were

to act as modifiers to pointcuts and type patterns (though I understand you can use them that

way, and, judging from the responses, it must be necessary to do so).

 
I just hate the idea of going too far down this road (or, if we do, that it should be limited to

load-time weaving).

 
Wes

 
------------Original Message------------

From: "Ron Bodkin" <rbodkin@xxxxxxxxxxxxxx>

To: aspectj-users@xxxxxxxxxxx

Date: Fri, Mar-10-2006 6:45 AM

Subject: RE: [aspectj-users] problems with loadtime    weavingand    rmicommunication

I think there are valid cases where a user can know that they don’t want to weave in a loader _for their application_, for just the same reasons that we have exclude clauses in an aop.xml file. This isn’t implying that no one would ever need to weave the loader, just that for my aspects, I don’t need to affect the types loaded by this loader.

 

The graphs that Thilo posted were a little hard to read in that the 1.5.0 vs. dev builds both showed memory use after just 500 requests and for the experimental build that I made showed memory use after 3000 requests…

 

I agree that the weaver state shouldn’t pin class loaders, but the memory that is added per proxy can be significant. I’d like to dig in a bit to see if I can reproduce Thilo’s results to understand what loader(s) are in effect. Maybe a good first step is to allow another trace option just to trace the construction of weavers for a loader. It would be nice to have a means to get statistics on the weaving container too (a JMX remote option maybe)…

 



From: aspectj-users-bounces@xxxxxxxxxxx [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Matthew Webster
Sent:
Friday, March 10, 2006 9:32 AM
To:
aspectj-users@xxxxxxxxxxx
Subject:
RE: [aspectj-users] problems with loadtime weavingand rmicommunication

 


Ron,


My point is that if we as framework providers cannot robustly determine when a class loader should or should not be used for weaving what hope has the user. Requiring them to use extensive diagnostics or trial an error to set options is unsatisfactory. The type of configuration you suggest is a short term solution for experts only.


The weaver state should not pin the class loader; if it does it's a bug. The dramatic difference in the graphs between the FINAL and the DEVELOPMENT builds would suggest we have fixed such a bug. The only official link between a class loader and it's weaver is in Aj and that's a WeakReference.


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-users@xxxxxxxxxxx

Sent by:        aspectj-users-bounces@xxxxxxxxxxx

To:        <aspectj-users@xxxxxxxxxxx>
cc:        
Subject:        
RE: [aspectj-users] problems with load time        weavingand        rmicommunication


Hi Matthew,


Let me look into the situation a little more. It appears that in Thilo’s case some other lightweight ClassLoaders are being allocated. My concern is that we aren’t going to be able to hard-code all the possibilities (e.g., if WebLogic or WebSphere or … have their own per object loader for RMI calls or for that matter dynamically generated proxies). In a case like that, at least there would be a possibility to improve memory use by configuration. It, to me, is very much like excluding by type name, or indeed by putting an aop.xml file in a place that’s visible to a loader, except that there are often loaders for which an aop.xml cannot be deployed in advance.


I do agree that the weaver state should be eligible for GC if the ClassLoader is. However, adding even 1 MB of Weaver State per remote proxy (which pins its ClassLoader) is a pretty significant amount of overhead!

 

 



From:
aspectj-users-bounces@xxxxxxxxxxx [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Matthew Webster
Sent:
Friday, March 10, 2006 8:19 AM
To:
aspectj-users@xxxxxxxxxxx
Subject:
RE: [aspectj-users] problems with load time weavingand rmicommunication



Ron,


The fix to https://bugs.eclipse.org/bugs/show_bug.cgi?id=120473 ensured that delegating class loaders were not used for weaving. If the class loaders in question fall into this category then they should also be excluded; not by name but using some other robust mechanism. Suggesting configuration implies a user may wish to weave on some occasions but not others. How would they make this decision? How would they know the name of the class loader to supply to the configuration? If we can't answer these questions then providing such an option will just confuse the user.


It would seem that these class loaders are short lived; if not the JVM would go OutOfMemory eventually without the help of LTW. Looking at the graphs it would seem that the first solution to this problem. releasing any references to the class loaders so that they and the associated weaver state can be collected, has been integrated. Reducing the overall footprint of the weaver continues and will also benefit this problem.


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-users@xxxxxxxxxxx

Sent by:        aspectj-users-bounces@xxxxxxxxxxx

To:        <aspectj-users@xxxxxxxxxxx>
cc:        
Subject:        
RE: [aspectj-users] problems with load time weaving and        rmicommunication


Hi Thilo,

I was suggesting that this might be a good change to make to AspectJ to
support cases like not creating weaving state when using RMI. However, as
you found, it isn't implemented in AspectJ (yet). It would be relatively
easy to do and I think it'd be interested to try it out.

Does <exclude loader="..."> seem like a good suggestion to you and others?
If so, we could put a bugzilla entry in to track it.

-----Original Message-----
From: aspectj-users-bounces@xxxxxxxxxxx
[mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Thilo Focke
Sent: Friday, March 10, 2006 3:19 AM
To: aspectj-users@xxxxxxxxxxx
Subject: Re: [aspectj-users] problems with load time weaving and
rmicommunication

Hi Rod,

thanks for your detailed message. Now i understand whats the problem
between load time weaving and rmi communication i think. According to
your suggestion i added the following to my aop.xml

<aspectj>
<weaver options="-verbose -proceedOnError -noWarn
-Xlintfile:META-INF/Xlint.properties">
...
<exclude loader="sun.reflect.DelegatingClassLoader"/>
<exclude loader="weblogic.utils.classloaders.GenericClassLoader"/>
</weaver>
...
</aspectj>

Unfortunately it has no effect on reducing the rmi-overhead. The console
still does the following output on each request:

info AspectJ Weaver Version LTWExperimental built on Thursday Jan 26,
2006 at 03:39:19 GMT
info register classloader
weblogic.utils.classloaders.GenericClassLoader@9754965
info using
file:/C:/Programme/apache-tomcat-5.5.12/shared/lib/pmon-1.0.0-SNAPSHOT.jar!/
META-INF/aop.xml
info register aspect de.myApp.PerformanceMonitor
info weaving 'de/myApp/service/bean/MyService_ee9ogc_HomeImpl_814_WLStub'
info AspectJ Weaver Version LTWExperimental built on Thursday Jan 26,
2006 at 03:39:19 GMT
info register classloader
weblogic.utils.classloaders.GenericClassLoader@15456211
info using
file:/C:/Programme/apache-tomcat-5.5.12/shared/lib/pmon-1.0.0-SNAPSHOT.jar!/
META-INF/aop.xml
info register aspect de.myApp.PerformanceMonitor
info weaving 'de/myApp/service/bean/MyService_ee9ogc_EOImpl_814_WLStub'
10.03.2006 08:48:48 de.ewetel.test.DummyServlet doThis_aroundBody4
INFO: Hello World!
10.03.2006 08:48:48 de.ewetel.test.DummyServlet doThis_aroundBody4

If you want to replicate my results: its just a simple servlet that
receives a user request. The doGet()-implementation of the servlet just
forwards the request to a method (doThis()) that opens a connection to a
remote EJB object (located in Bea Weblogic) and calls a
HelloWorld-method ;) On each request you get the output i pasted before.

if you have any more ideas how to reduce the overhead or need someone to
test a new overhead-reducing aspectj version please let me know ;)

Greetins,
Thilo



Ron Bodkin wrote:

>Hi Thilo,
>
>I think the results are encouraging in the sense that my optimizations have
>a big positive impact (1/6 the overhead with RMI, and at most 1/3 without
>RMI). As Andy and I noted, we're working to integrate them into AspectJ
>HEAD, in addition to the optimizations that Andy and Adrian have been
>working on.
>
>While your tests showed while the overhead is significantly reduced, there
>is still some noticeable overhead per ClassLoader. I'd like to optimize it
>further to allow nearly all the state in a case like this to be shared.
>
>Java VM's create ClassLoaders for RMI calls and proxies, presumably to
>isolate them so that "normal" classes don't see them. In this and in other
>circumstances, Java libraries often assume creating a ClassLoader is a
>lightweight operation... So I think AspectJ load-time weaving needs to keep
>focusing on adding small overhead in these cases.
>
>I do think there's an interesting short-term answer to scenarios like this.
>It would be helpful if the aop.xml file allowed excluding weaving in child
>ClassLoaders by name pattern, e.g.,
><aspectj>
>  <weaver>
>   <exclude loader="sun.reflect.DelegatingClassLoader"/>
>  </weaver>
>...
></aspectj>
>
>While this isn't ideal, it would make a huge difference in the runtime
>performance of load-time weaving (as in cases like this where you just
don't
>need to weave into the generated RMI classes).
>
>I'd be interested in trying to replicate your results in a simple example.
>Am I right that you are just opening a connection to a remote EJB object
>from inside your Web application?
>
>Integrating the optimizations for shared state is still pending some
>foundational work that's in progress...
>
>One thing that should help a lot is making sure that there are no hard
>references to the weaving state: conceptually whatever memory the weaver is
>allocating for this ClassLoader should be eligible for GC once the RMI
proxy
>object is eligible for GC... so some of the recent work in AspectJ CVS HEAD
>might just fix your memory problem. Of course, creating a megabyte of
>weaving state each time you use an RMI proxy is probably going to have some
>negative performance impact...
>
>-----Original Message-----
>From: aspectj-users-bounces@xxxxxxxxxxx
>[mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Thilo Focke
>Sent: Monday, March 06, 2006 1:44 AM
>To: aspectj-users@xxxxxxxxxxx
>Subject: Re: [aspectj-users] problems with load time weaving and rmi
>communication
>
>Hi guys,
>
>first of all thank you for your answers.
>i did some testing with the aspectjweavers from aspectj final, from the
>current development build and from Rods expermintal build from glassbox
>inspector. The results are alarmingly different.
>
>i did a little stress tests, that did about 3000 requests in a loop.
without
>rmi rmi communication there is no significant memory usage. with rmi
>communication and rods development aspectjweaver i was able to send nearly
>3000 requests. the memory usage went up to 500 MByte. with the
aspectjweaver
>from the aspectj final build and from the actual development build i was
>only able to send nearly 500 requests. the memory usage went up to 500MByte
>and i got an out of memory error. rods experimental build made a
significant
>difference in memory usage.
>
>i summarized my results on the following url:
>http://www.webengineer.de/ltw.html
>there you can find some screenhots from jconsole i made during my tests.
>
>i also switched on the -verbose option in my aop.xml. as matthew mentioned
>before, when using rmi communication there are created a lot of class
>loaders. see the following i pasted from my tomcat console:
>
>06.03.2006 10:17:36 myTest.DummyServlet doThis_aroundBody4
>info AspectJ Weaver Version LTWExperimental built on Thursday Jan 26, 2006
>at 03:39:19 GMT
>info register classloader
>weblogic.utils.classloaders.GenericClassLoader@18880287
>info using
>file:/C:/Programme/apache-tomcat-5.5.12/shared/lib/pmon-1.0.0-SNAPSHOT.jar!
/
>META-INF/aop.xml
>info register aspect de.pmon.PerformanceMonitor
>info weaving 'myTest/bean/Service_ee9ogc_HomeImpl_814_WLStub'
>info AspectJ Weaver Version LTWExperimental built on Thursday Jan 26, 2006
>at 03:39:19 GMT
>info register classloader
>weblogic.utils.classloaders.GenericClassLoader@32211177
>info using
>file:/C:/Programme/apache-tomcat-5.5.12/shared/lib/pmon-1.0.0-SNAPSHOT.jar!
/
>META-INF/aop.xml
>info register aspect de.pmon.PerformanceMonitor
>info weaving 'myTest/bean/Service_ee9ogc_EOImpl_814_WLStub'
>06.03.2006 10:17:36 myTest.DummyServlet doThis_aroundBody4
>06.03.2006 10:17:36 myTest.DummyServlet doThis_aroundBody4
>info AspectJ Weaver Version LTWExperimental built on Thursday Jan 26, 2006
>at 03:39:19 GMT
>info register classloader
>weblogic.utils.classloaders.GenericClassLoader@20872473
>info using
>file:/C:/Programme/apache-tomcat-5.5.12/shared/lib/pmon-1.0.0-SNAPSHOT.jar!
/
>META-INF/aop.xml
>info register aspect de.pmon.PerformanceMonitor
>info weaving 'myTest/bean/Service_ee9ogc_HomeImpl_814_WLStub'
>info AspectJ Weaver Version LTWExperimental built on Thursday Jan 26, 2006
>at 03:39:19 GMT
>info register classloader
>weblogic.utils.classloaders.GenericClassLoader@22373430
>info using
>file:/C:/Programme/apache-tomcat-5.5.12/shared/lib/pmon-1.0.0-SNAPSHOT.jar!
/
>META-INF/aop.xml
>info register aspect de.pmon.PerformanceMonitor
>info weaving 'myTest/bean/Service_ee9ogc_EOImpl_814_WLStub'
>06.03.2006 10:17:36 myTest.DummyServlet doThis_aroundBody4
>06.03.2006 10:17:36 myTest.DummyServlet doThis_aroundBody4
>info AspectJ Weaver Version LTWExperimental built on Thursday Jan 26, 2006
>at 03:39:19 GMT
>info register classloader
>weblogic.utils.classloaders.GenericClassLoader@25411170
>info using
>file:/C:/Programme/apache-tomcat-5.5.12/shared/lib/pmon-1.0.0-SNAPSHOT.jar!
/
>META-INF/aop.xml
>info register aspect de.pmon.PerformanceMonitor
>info weaving 'myTest/bean/Service_ee9ogc_HomeImpl_814_WLStub'
>info AspectJ Weaver Version LTWExperimental built on Thursday Jan 26, 2006
>at 03:39:19 GMT
>info register classloader
>weblogic.utils.classloaders.GenericClassLoader@10284000
>info using
>file:/C:/Programme/apache-tomcat-5.5.12/shared/lib/pmon-1.0.0-SNAPSHOT.jar!
/
>META-INF/aop.xml
>info register aspect de.pmon.PerformanceMonitor
>info weaving 'myTest/bean/Service_ee9ogc_EOImpl_814_WLStub'
>06.03.2006 10:17:36 myTest.DummyServlet doThis_aroundBody4
>06.03.2006 10:17:36 myTest.DummyServlet doThis_aroundBody4
>
>can you explain me why it is necessary to register a new classloader on
each
>rmi request?
>we planned to integrate the permormance monitoring in one of our production
>systems. but as long as the memory increases on each rmi request we think
it
>is not a good idea to integrate it. currently we only use it on our test
>systems (unfortunatley).
>
>greetings,
>thilo
>
>
>
>
>Ron Bodkin wrote:
>
>  
>
>>Thilo,
>>
>>Just as a quick follow up, the AspectJ 1.5.0 release adds some nontrivial
>>overhead per ClassLoader where you do weaving. When you are using RMI, the
>>VM can create a lot of different ClassLoaders for reflective acessors.
>>
>>The experimental LTW version I pointed you at allows for sharing aspect
>>definitions and AspectJ delegates between ClassLoaders where it is safe
(it
>>tests for nondelegation), so it should make a significant difference. I
>>haven't yet created a patch for this optimization, since as Andy noted,
I'm
>>working with him to integrate some foundational memory improvements,
>>bringing them up to generally usable production quality :-)
>>
>>The same issue applies for JSP's, where many containers create a large
>>number of lightweight ClassLoaders and maintaining heavyweight weaving
>>    
>>
>state
>  
>
>>for each results in major overhead.
>>
>>-----Original Message-----
>>From: aspectj-users-bounces@xxxxxxxxxxx
>>[mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Thilo Focke
>>Sent: Friday, March 03, 2006 8:06 AM
>>To: aspectj-users@xxxxxxxxxxx
>>Subject: Re: [aspectj-users] problems with load time weaving and rmi
>>communication
>>
>>Hi Matthew and Andy,
>>
>>1. The memory usage when using RMI without the aspect ist absolutely
>>constant and in acceptable ranges (about 30-40 MByte). The memory usage
>>increases permanently when using the aspect. When using the aspect on code
>>without RMI communication the memory usage is constant (about 100MByte).
>>
>>2. IŽm using  AspectJ 1.5.0, released on 20th December, 2005
>>
>>3. My aop.xml looks like this
>>
>><!DOCTYPE aspectj PUBLIC "-//AspectJ//DTD//EN"
>>"http://www.aspectj.org/dtd/aspectj_1_5_0.dtd">
>><aspectj>
>>   <weaver options="-proceedOnError -noWarn
>>-Xlintfile:META-INF/Xlint.properties">
>>       <include within="my.package..*"/>      
>>   </weaver>
>>   <aspects>        
>>       <aspect name="MyMonitor"/>
>>   </aspects>
>></aspectj>
>>
>>Thanks a lot,
>>Thilo
>>
>>
>>
>>
>>--------------->
>>
>>Thilo,
>>
>>Can I ask some questions:
>>1. What is the memory usage when you use RMI but not the aspect?
>>2. Which version of AspectJ are you using? We have made some enhancements
>>recently in memory usage.
>>3. Do you use -verbose in the weaver options of aop.xml? If so could you
>>post it. I think the problem might to do with creating lots of class
>>loaders, each with a weaver and the accompanying footprint.
>>
>>Cheers
>>
>>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
>>_______________________________________________
>>aspectj-users mailing list
>>aspectj-users@xxxxxxxxxxx
>>https://dev.eclipse.org/mailman/listinfo/aspectj-users
>>
>>
>>_______________________________________________
>>aspectj-users mailing list
>>aspectj-users@xxxxxxxxxxx
>>https://dev.eclipse.org/mailman/listinfo/aspectj-users
>>
>>    
>>
>
>_______________________________________________
>aspectj-users mailing list
>aspectj-users@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>_______________________________________________
>aspectj-users mailing list
>aspectj-users@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>  
>

--
EWE TEL GmbH
Thilo Focke
IP/IT-Systeme & Netze
Cloppenburger Strasse 310, D-26133 Oldenburg
Telefon: +49 (0)441 8000-2863
Telefax: +49 (0)441 8000-2799
thilo.focke@xxxxxxxxx
http://www.ewetel.de

_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users

_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users

_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/aspectj-users _______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-dev