3

I am trying to configure AspectJ load time weaving and I need to weave a spring managed bean. This is because unfortunately the spring bean I'm interested in is in a third party library and has no null constructor so I can't use spring AOP.

My load-time-weaving Aspect is working for some classes in the same package as the class i'm really interested in. So I think I am hitting the problem that the bean class has been eagerly loaded before it can be loaded in the TomcatInstrumentableClassLoader

I've seen warnings about this in questions such as:

(a) AspectJ load time weaving not working for Spring beans

(b) http://forum.spring.io/forum/spring-projects/aop/123993-enableloadtimeweaving-is-not-working-but-context-load-time-weaver-is-worked

(c) Unable to apply advice to third party library (log4g - Logger.getLogger call) using Spring LoadTimeWeaving?

But it's not clear whether this is something you can work around - if you have the smarts. It sounds like it may be in link (a): There is the suggestion of creating two config classes and making sure one is loaded first. Is that possible with xml context configuration files. We are using xml configuration for our beans. Perhaps enforcing order of spring config files is only possible in java config? For this profiling project i can't change all our bean config unfortunately.

I've tried setting default-lazy-init="true" in the beans element in all our context files, but that didn't work sadly.

Is there anything else I can try? Even if it's quite tricky.

Community
  • 1
  • 1
moncheery
  • 333
  • 4
  • 17
  • 1
    You can easily split up your XML configuration files and enforce import ordering using `````` statements. It's synonymous to the Java ```@Import``` annotation. – Misha Jun 04 '14 at 22:23
  • 1
    If you are using Java based configuration it is hard as as soon as the class is loaded all directly referenced classes are loaded also (see one of those threads which has an answer from me). With XML it should generally work, unless there is something else triggering the load of the class (i.e. a filter/servlet etc. before the context is being loaded). – M. Deinum Jun 05 '14 at 06:21
  • Thanks's everyone :) In terms of forcing the TomcatInstrumentableClassLoader to start before the beans are loaded, i'm still unclear. Is the suggestion to have the line in the first file to be loaded and then all the other beans in another? Because that's what I have already. The instruction is in my applicationContext.xml but the bean i'm interested in is in another xml file. As far as i can *tell* nothing in the applicationContext references that bean, but I appreciate these things are not always obvious :) – moncheery Jun 05 '14 at 10:14
  • 1
    I'd love to accept someone's answer but you answered in comments. I could do with the reputation points - i need 15 to start upvoting people's helpful answers elsewhere :( If anyone reads this who answered could you change your answer to an answer and i'll give you the proper credit. thanks – moncheery Jun 06 '14 at 16:05

0 Answers0