Announcement Announcement Module
Collapse
No announcement yet.
Can I intercept POJO instead of bean/proxy? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Can I intercept POJO instead of bean/proxy?

    Hi,

    I am implementing the basic HelloWorld Spring AOP example and I am able to get advice to fire for the proxied object. For example (from index.jsp):

    ApplicationContext ctx = new FileSystemXmlApplicationContext(applicationContext .xml);
    HelloWorldInterface h = (HelloWorldInterface)ctx.getBean("helloWorld");
    h.getMessage();

    I have defined a pointcut and before/after advice which fires when getMessage() is called.

    My problem is that when I call the POJO (non-bean) version of HelloWorld the pointcuts don't trigger and the advice doesn't fire:

    HelloWorld h = new HelloWorld();
    h.getMessage();

    I also tried:

    HelloWorldInterface h = new HelloWorld();

    Having to rewrite my code to use proxies instead of the original POJOs doesn't seem very "cross-cutting" to me. I assume that's not how it works and I must just be missing something.

    Can I get my pointcuts/advice to fire on calls to the HelloWorld POJO instead of the proxy/bean?

    Thanks.

  • #2
    Use the search, this question has been answered. Next to that read the reference guide, chapter 6 explains it all.

    Basically you can have AOP applied in 3 ways
    - compile time
    - loadtime
    - runtime

    The first requires you to compile with the AspectJ compiler to weave your aspects.
    The second weaves your aspects when the classes are loaded.
    The third uses proxy based (Spring AOP).

    If you want to have more control you have to either use loadtime or compile time weaving. However as stated Chapter 6 of the reference guide explains this.

    Comment


    • #3
      Thanks

      Thanks for your help.

      I did read the documentation but I didn't make the connection between weaving at compile/load/run time and how that relates to accessing the proxy versus accessing the "original" object. Not to mention that it was less-than-obvious what sort of search keywords I should use (I spent a lot of time on Google). I suppose it's obvious once you know what you're doing, but the whole point of reading documentation is that you don't.

      I imagine there are a lot of people who have legacy code they can't touch and therefore cannot define aspects on the proxy object (via runtime weaving). At my level I could probably have used something like "Spring Load-Time Weaving For Dummies". Perhaps there are others in the same boat.

      Anyway, thanks again.

      Comment


      • #4
        Hmm....

        Not agreeing with you here though understand... AOP is not easy. Not even "AspectJ for Dummies" or any book can really explain this "vanilla-style" since it is complicated. That said, I am not agreeing with you because this is straight from the documentation...

        "6.4.1. Spring AOP or full AspectJ?

        Use the simplest thing that can work. Spring AOP is simpler than using full AspectJ as there is no requirement to introduce the AspectJ compiler / weaver into your development and build processes. If you only need to advise the execution of operations on Spring beans, then Spring AOP is the right choice. If you need to advise domain objects, or any other object not managed by the Spring container, then you will need to use AspectJ. You will also need to use AspectJ if you wish to advise join points other than simple method executions (for example, call join points, field get or set join points, and so on)."

        I am not sure how else can this be explained clearer and yet I've also had some issues at first trying to write field level auditing on the domain objects without aspectj

        Comment


        • #5
          Fair enough.

          My problem is that I am new to web application and Spring configuration. I did read the above paragraph very carefully and thought that I could take any domain object and cause it to be managed by the Spring container by declaring it as a bean.

          Anyway, since load-time weaving involves AspectJ already I just switched to AspectJ and was able to get the desired behavior (fairly quickly, I might add).

          Again, many thanks for your helpful replies.

          Comment

          Working...
          X