More AOP Reading

I think I understand that duplicate functionality found in multiple methods, like logging is called a crosscutting concern. The simple thing to do is to cut and paste it all over your code, and otherwise make a huge mess of your code base. This is obviously undesirable, so we need a way to encapsulate these behaviors into their own modules called advices.

I understand the need all too well, but I haven't grasped the environment yet. I have another article here about profiling with AOP, and its slow start and link to a previous article look promising for cracking this thing wide open for me.

I just haven't figured out if this is more of a methodology for me to implement in my code in my own way, or does the implementation lie only in a product I should learn and use (Aspectwerkz, AspectJ, JBoss AOP)? It's very much like when I wanted to move from Perl to JSP for web development. I could plug all this JSP code into my html, rename it .jsp, and drop it on my Apache web server, but that obviously didn't run it. Before even getting started, I had to find a container and start thinking in the terms of a container running my code. I found Tomcat, and I was in business. I had to take another leap when I started reading about having my JSPs call EJB. After figuring out that Tomcat couldn't run it for me, I found JBoss. AOP will be another container leap, I think.

Trying to think in AOP but stick with my normal APIs, I've actually ended up implementing a proxy-based decorator pattern driven by dynamically reloaded properties files. This allows me to wrap layers of proxies around a core functionality. Specifically, this allows me to dynamically configure the wrapping of static classes around method invocations of a query manager. It feels versatile, but sticks to the familiar static strong typing. I realize it's not AOP, though, since a method still remains my smallest unit of execution.

I expect I'll find that AOP is going to based on something overly simplistic like a preprocessor substituting in code bits at compile time, or a framework which uses BCEL to plug the functionality right into the bytecode of my compiled classes as they run. That's my impression at this point -- I'll have yet another layer added somewhere to implement this.

That brings me to another concern of eventually introducing that last layer that sends a project spiraling to its death do to complexity making it too difficult to ever debug or maintain. I've left this Pandora's box sealed for now.