Announcement Announcement Module
Collapse
No announcement yet.
Advising non spring beans Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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
    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?

    Comment


    • #3
      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

      Comment


      • #4
        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.

        Comment


        • #5
          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!

          Comment


          • #6
            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

            Comment

            Working...
            X