Bug 568087 - Allow org.aspectj.weaver.loadtime.IWeavingContext implementation to be easily specified externally
Summary: Allow org.aspectj.weaver.loadtime.IWeavingContext implementation to be easily...
Status: NEW
Alias: None
Product: AspectJ
Classification: Tools
Component: LTWeaving (show other bugs)
Version: 1.8.6   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: aspectj inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-10-21 16:21 EDT by Mike Menu CLA
Modified: 2020-10-21 16:21 EDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Menu CLA 2020-10-21 16:21:29 EDT
It would be useful to allow AspectJ agent to be easily configured to use an alternate implementation of org.aspectj.weaver.loadtime.IWeavingContext other than org.aspectj.weaver.loadtime.DefaultWeavingContext.

org.aspectj.weaver.loadtime.ClassLoaderWeavingAdaptor.initialize(ClassLoader, IWeavingContext) hardcodes defaulting to new DefaultWeavingContext(classLoader).

This could be easily done via simple system property set to the name of the class to use without the need to modify AspectJ itself.

I was able to create my own AspectJ agent to use my own custom implementation of IWeavingContext but I needed to create a new Agent class and a number of copy/paste hack changes into my own classes modelled after AspectJ's to make it work.  

Ideally, in order to support ease of customization and extension I try to:
a) Use small methods
b) Use protected vs. private
c) Instantiate new instances of an interface implementation by calling a protected method that returns the interface in its signature
d) Allow configuration to dictate the implementation of the interface I wish to use (e.g. via DI or other similar mechanism - could be as simple as system prop with the class name I want to use).
With all of the above it is much easier to override behavior in valid ways that no author(s) can foresee :-)