Multiple load-time-weaver elements cause repeated addition of AspectJ transformer [SPR-14373] #18946
If context:load-time-weaver/ or
The obvious solution is "don't specify load-time-weaver repeatedly", but this may be confusing or difficult for large projects.
For example, in a Spring project where the context is composed of multiple submodules with beans that are imported by using <import resource="..."/> elements, it makes logical sense for the submodule <beans> elements to specify context:load-time-weaver/ because they contain Aspect beans and were designed for load-time weaving. Placing context:load-time-weaver/ statement in the "top-level" context file may not make sense because it may not even be aware that some of its submodules use Aspect-Oriented-Programming. Also, multiple top-level context files may exist (e.g., for testing or for different actual context features using shared code) and this would mean putting the load-time-weaver element in all of them.
These error messages are not necessarily harmless. If context:load-time-weaver/ is specified with conflicting options, i.e., the use of the Spring AOP processor vs the full AspectJ weaver, then unexpected behaviour could result. A submodule specifying load-time-weaving without turning on AspectJ and without having an aop.xml file, but loaded near the start of the "master" context file, could prevent submodules that might require the full AspectJ weaver from working correctly merely because they were loaded later in the "master" context file.
It seems like things would be a lot easier for users if load-time-weaver instructions could be collapsed into one before java.lang.instrument.Instrumentation.addTransformer() is called. When there are conflicting options specified, the whole context should be aborted.
Referenced from: commits 981d449
The text was updated successfully, but these errors were encountered:
Juergen Hoeller commented
I'm afraid this is not designed for fully merging such definitions at this point. However, the "loadTimeWeaver" beans should at least replace each other within the same application context, with the last definition winning: This seems to work fine for