Announcement Announcement Module
Collapse
No announcement yet.
Getter interceptor for non-spring beans - is it possible? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Getter interceptor for non-spring beans - is it possible?

    I have a number of beans that all extend certain interface. These beans are not managed by Spring (they are domain objects). Is it possible to intercept all calls to these beans' getters, using Spring AOP, without having to manage them in Spring container?

    Thanks,

    Alex

  • #2
    If you don't manage them in the Spring container you would still have to use the Spring APIs for creating Spring AOP proxies. For a truly non-invasive approach at the code level I would suggest AspectJ. The downside of using AspectJ is you introduce a new compiler/runtime into your infrastructure.

    Comment


    • #3
      Thanks - that's what I figured as well I assume this hasn't changed in Spring 2.0

      I'll look at AspectJ, then...

      Comment


      • #4
        You might find the following link interesting: http://www.aspectprogrammer.org/blog...cal_gui_2.html

        Comment


        • #5
          Using AspectJ is not particularly hard. You can use the ajc compiler or load time weaving. Load time weaving is easy to apply based on the Spring 2.0 LoadTimeWeaver infrastructure (originally built for JPA support). This enables the AspectJ ClassFileTransformer to be applied transparently to the appropriate class loader, so you don't need to weave your entire server.

          The infrastructure is already there, and hopefully we will have time to build examples and out-of-the-box activation options before 2.0 final.

          Comment


          • #6
            Spring 2.0 LoadTimeWeaver

            Hi all!

            Are there any examples or documentation available by now on how to use the Spring 2.0 LoadTimeWeaver infrastructure?
            I've searched the Web, but didn't find anything useful.

            I'm using the @Configurable anotation on entity beans, just as suggested in the "Practical Guide" referenced above.
            However, using "-javaagent:aspectjweaver.jar" for a large project is impracticable; it's just too slow!
            Using Eclipse AJDT is nice, but unusable for production builds (running on a Continous build server, without Eclipse).
            Using the iajc ant-support (from AspectJ) on the other hand makes things clumsy and slow for running the project inside Eclipse (on Tomcat) using the WTP tools.
            So, having a fast LoadTimeWeaver would solve both cases, and it sounds like the Spring LTW infrastructure could do that...

            Anyone has experience with that stuff?

            Best regards,
            Florian

            Comment


            • #7
              You can configure the aspectj xml file to define exactly which classes should be considered for weaving and which aspects should be used....check out the aspectj web site for more details

              Comment


              • #8
                Done that - however, restricting the classes to weave using the "include within" and "exclude within" weaver-settings in META-INF/aop.xml doesn't seem to affect performance and memory-usage in any way.
                It does affect the classes being weaved (so the settings are effective), but the weaver still consumes >150MB memory on startup, regardless of the number of classes matching the filter.

                Furthermore, I noticed that using LTW, CGLIB proxies for my classes get woven es well, in addition to the classes themselfs. Using build-time weaving, only the "real" classes get woven, so LTW seems less efficient in this respect. Rigth?

                Best regards,
                Florian

                Comment

                Working...
                X