Results 1 to 6 of 6

Thread: Advising non spring beans

  1. #1
    Join Date
    Feb 2009
    Posts
    11

    Default Advising non spring beans

    Howdy,


    I've been googling around for a solution to advise non-beans with Spring's AOP and I can't find anything that works for me.

    I have an interface, DataSession which is implemented by DataSessionImpl. Instances of DataSessionImpl are created as needed by other components in the application, and the Spring container is unaware of their existence.
    I do realise it makes no sense to be expecting Spring to apply advices to things it doesn't even know exist, but isn't there a way to force this? I read something with @Configurable but I can't get that working.
    Should I place @Configurable in the interface (DataSession) or the class (DataSessionImpl)? If the answer is the class, then do I have to enable cglib's proxies to enable advices to classes?

    To sum up, what I need is when a specific method is called in any instance of the non-bean DataSession interface (either in DataSessionImpl or any other implementation), an advice is triggered.
    Is this possible?

  2. #2
    Join Date
    Feb 2009
    Posts
    11

    Default

    Okay, so I got it to work (not perfectly but it's going there) but there's a strange thing happening that I don't quite understand.

    I wrote a method profiler that acts on all methods of package "foo..*" and all my classes are in foo package. It's working great, profiling everything but if I change the following code:

    Code:
    public class Test {
        public static void main(String[] args) {
            new ClassPathXmlApplicationContext("foo/beans.xml");
    
            // everything after the initialisation of the context
            StuffInterface executer = new StuffExecuter();
            executer.doStuff();
            StuffInterface anotherExecuter = new StuffExecuter();
            anotherExecuter.doStuff();
    
            OtherStuff stuff = new OtherStuff();
            stuff.doMoarStuff();
    
            new ShutdownThingie().shutdown();
        }
    }
    to

    Code:
    public class Test {
        public static void main(String[] args) {
            // these two lines were pulled up, before the context init
            StuffInterface executer = new StuffExecuter();
            executer.doStuff();
    
            new ClassPathXmlApplicationContext("foo/beans.xml");
    
            StuffInterface anotherExecuter = new StuffExecuter();
            anotherExecuter.doStuff();
    
            OtherStuff stuff = new OtherStuff();
            stuff.doMoarStuff();
    
            new ShutdownThingie().shutdown();
        }
    }
    Then none of the executions of StuffInterface.doStuff() are profiled, not even the ones created after the context init.
    It seems as classes are only being woven if their first instance is created AFTER the load time weaving is enabled. I'm pretty green in AOP so this may even be the expected behaviour, but still gave me some headaches until I figured it.

    Question is, is there any way around this? Or the context initialisation is absolutely, positively and unquestionably the first thing to initialise in my application? If so, I could I possibly profile stuff like hashtable methods, that are eventually created before I can even load the context?

  3. #3
    Join Date
    Aug 2004
    Posts
    2,715

    Default

    Quote Originally Posted by ovokinder View Post
    It seems as classes are only being woven if their first instance is created AFTER the load time weaving is enabled.
    Usually context initialization is the first thing I do, so I didn't bother considering this too deeply. However, in your case you not only instantiate the class upfront, you also invoke the doStuff() method before. In that case your advice will definitely not be present on execution.

    It might work, if the method execution follows after context initialization, but I would definitively suggest to do initialization first.

    Regards,
    Andreas

  4. #4
    Join Date
    Feb 2009
    Posts
    11

    Default

    After reading a bit about it I realised it makes sense, since weaving takes place at class load time. I now have everything working perfectly.

  5. #5
    Join Date
    Aug 2009
    Posts
    1

    Default

    Quote Originally Posted by ovokinder View Post
    After reading a bit about it I realised it makes sense, since weaving takes place at class load time. I now have everything working perfectly.
    Do you mind sharing how to advise non-spring beans? I'm facing a similar situation but couldn't figure out the solution. Thanks!

  6. #6
    Join Date
    May 2007
    Location
    Saint Petersburg, Russian Federation
    Posts
    1,189

    Default

    Quote Originally Posted by shoma View Post
    Do you mind sharing how to advise non-spring beans? I'm facing a similar situation but couldn't figure out the solution. Thanks!
    Weaving with AspectJ

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •