Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [aspectj-users] problems with loadtime weavingand rmicommunication

Hi Wes,

 

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

 

Yes because there is a significant performance impact to weaving into lightweight loaders like for remote proxies, possibly CGI, even for JSP’s if you don’t want to weave them. This is true even though none of your aspects will have any effect in the weaver because they won’t match any types being loaded (or because of exclusions)...  It is basically giving the ability to exclude all aspects for efficiency. This you can already do with an aop.xml file, and just as with an aop.xml file, if you do it incorrectly you can break things.

 

It allocates 1-1.5 MB in the optimized case for the Glassbox Inspector aspects, and it of course takes some time to load files to do that too. Eventually, having shared state for classes loaded by another loader so you don’t reload & restore would avoid this issue. There’s still a lot of work to do to get there yet, though. And it is a bit hard since ClassLoaders don’t do anything to cooperate with aspect weaving…

 

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).

 

I agree: the goal here is to make it easier to skip unaffected classes in the same vein, to improve performance. I wouldn’t recommend excluding a loader because you don’t want to weave the types it loads either!

 

 


Back to the top