| [aspectj-dev] Re: Load-Time Weaving configuration |
Martin, I have been playing with subclasses of ConcreteName (based on your example) obtained from a new JVMObjectTypeProvider supplied to the WeavingAdaptor on construction. I haven't got it working yet so decided to fall back on your suggested use of "getResourceAsStream()" to get the actual bytecodes for a class without knowing the static classpath (class loader delegation does it for you) as a way of fixing https://bugs.eclipse.org/bugs/show_bug.cgi?id=74246. I am using a modified ClassPathManager constructed with a ClassLoader. It's also a way of loading the bytecode for an aspect which we still need to do to obtain aspect metadata (pointcuts, perclause, ITDs, ...) until/unless we chose expose this another way at runtime (Java 5 metadata perhaps). However I have got stuck with aspectpath. Currently it's defined just like classpath and the WeavingAdaptor iterates over the URLs calling BcelWEaver.addLibraryJarFile() which figures out which types are aspects. Unfortunately this has SecurityManager issues. What I'd rather have is just a list of the aspects types which the weaving class loader has already figured out (it has the correct file/network read access already). How did you configure aspectpath in your Eclipse LTW implementation? 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/ Martin Lippert <lippert@xxxxxxx>@eclipse.org on 05/04/2004 12:08:10 Please respond to aspectj-dev@xxxxxxxxxxx Sent by: aspectj-dev-admin@xxxxxxxxxxx To: aspectj-dev@xxxxxxxxxxx cc: Subject: Re: [aspectj-dev] Re: [Bug 55107] add removeLibraryAspect method to weaver Hi, >>That sounds like a great thing. Would that be possible with the current >>weaver implementation or do you need to reimplement parts of that >>because of the BCEL dependencies? > >>BTW: I am currently using a specialized version of BcelWorld which >>enhances the "lookupJavaClass" method. My implementation first calls the >>super class and then tries to load the bytecode of the class via >>getResource using the class loader. Using this mechamism I do not need >>to set the complete classpath to my BcelWorld (which would be quite >>complicated using the Eclipse 3.0 runtime model). What do you think >>about an interface for this class lookup? > > You are in the right ball park. An idea that I discussed briefly with Jim > was to create an implementation of ConcreteName that relies on information > from Java reflection. This will cut down on footprint, be quicker that > re-parsing byte-code and guarantee the correct type. However your approach > is an excellent first step. Can you send me a code snippet and I will try > to add it to 31460. The idea to improve the weaving performance this like sounds great! The code snippet I could send you depends on some Eclipse internal classes. Nevertheless I could send you that snippet, if you like. Maybe we should create something like a TypeInformationProvider interface which contains methods for getting the complete bytecode for a specific type as well as a faster method for getting the Class object for a specific type. Then the weaver could use the getClass method whenever possible and getBytecode method if he needs the complete bytecode (maybe if the Class object is not yet available). In addition to that we could add a method to the WeavingAdaptor to set this kind of interface. That would make the WeavingAdaptor more flexible, I think. The weaving class loader could create a default implementation for the interface mentioned above that uses the ClasspathManager to load bytecode and a map of already loaded classes for the getClass method. What do you think? -Martin
Attachment:
smime.p7s
Description: Binary data