Load-Time Weaving and @Configurable Sometimes Seems Flaky

[phkoester]

Hello out there,

I'm new to this forum so say hello to everyone.

I need this initial post because I want to give code snippets containing the at character for annotations, which this software interprets as an URL that I, as a newbie, may not post ...

[phkoester]

With Spring 2.5.6, Spring agent 2.5.6 and AspectJ 1.6.2 (no application server whatsoever involved---I have an SWT application), I've recently observed two obscure problems concerning LTW and @Configurable auto-wiring that occur only under certain rare circumstances and are thus hard to reproduce.

1. Assignment To Instance Fields May Fail

Auto-wiring may not work if a newly-created object is assigned to an instance field somewhere in a compilation unit. I've experienced situations where code like this wouldn't work although I think it should:

public class MyApp {
    @Configurable
    static class MyWindow extends Window {
        @Resource
        ApplicationContext context;
    }

    MyWindow field;

    void init1() {
        // Assignment to instance field: auto-wiring fails
        field = new MyWindow();
    }

    void init2() {
        // This, however, will work, but only if ‘init1()’ is commented out!!
        MyWindow var = new MyWindow();
    }
}

2. Auto-Wiring Seems to Be Thread-Dependent

I've seen situations where auto-wiring configurables fails when they are created in separate threads, like this:

new Thread(new Runnable() {
    public void run() {
        // We are in a separate thread---auto-wiring may fail!
        MyWindow win = new MyWindow();
    }
}).start();

However, creating a ‘MyWindow’ instance beforehands in the main thread will be a workaround and ensure the load-time weaver will work as expected in other threads as well.

*

Admittedly, I'm neither a Spring nor an AOP expert, but I'm puzzled and believe things shouldn't behave the way they apparently do. It's not easy to set up small stand-alone Maven projects that reveal these spooky problems. So, before taking the effort to do this, I'd like to pose two questions:

1) Is any of this familiar to anyone or known already?

2) Who'd actually be able to look into and, more importantly, look after this? Have I come to the right place at all?

Best
Phil

[ramnivas]

Yes, this is the right place to ask this kind of question.

I really can't think of any reason why either of the cases will fail.
1. The @Configurable support works by advising the constructor initialization (or object deserialization--doesn't matter in your case, though). So I cannot think how assigning that object to a field has any effect.
2. Configuration happens in the thread that calls the constructor. Therefore, I don't see any reason why threading plays a role.

Also, LTW cannot be playing a role here, since it comes into picture only when a class is loaded. In your case, MyWindow will be loaded quite early on. At object creation time, LTW isn't into the picture.

Do you have reproducible test cases for either of the two? If so, file an issue with those and I will take a look.

-Ramnivas

[phkoester]

Thanks a lot for your reply, Ramnivas, but relax, I think I was able to eventually narrow down the problem. With a little research and field hacking I wrote myself a utility method that lists all loaded classes for a given class loader, and it clearly appears that the ‘MyWindow’ class is loaded before the Spring application context and the load-time weaving are initialized. In fact, my application class creates both the context and the configurable window, so I have to be very careful about when exactly my classes are loaded.

AFWIW, it's interesting to see that field declarations and anonymous inner classes occasionally do have an impact on the order in which classes are loaded. I don't feel comfortable to be dependent on the exact loading behavior so will have to find a way to decouple my classes.