On the day before my wedding I gave a talk at local (St.-Petersburg Russia) IEEE Chapter as part of work on my dissertation. Thanks to Motorola for hosting it! The first time I got acquainted with AOP being a portlet developer it struck me that all portlets dealt with cross-cutting concerns. Cross-cutting concerns in the portlets world are modes and states, b/c any portlet ever developed is rendered (or is concerned with) in very limited (4 in most portal servers) modes and states. So, in AOP terms, each portlet mode or state is just an aspect that portlet is associated with. Portlets rendering is one thing, but this idea lead to another conclusion: the logic portlets use to render themselves in some mode or state can also be moved into a separate aspect. To prove that my idea was no nonsense I had to develop a working XSL transformation that would transform portlets configuration (portlet.xml) into AOP configuration (jboss-aop.xml). XSL transformation file is available at https://www.dusystems.com/aopportlets.html. The resulting jboss-aop.xml works with portlet containers (it takes some effort to bundle in JBoss AOP though). So, if anyone is interested – welcome to take a look and comment on this approach. Soon I will publish Eclipse plugins that produce jboss-aop.xml form portlet.xml on the fly (using XSL), and do another nice thing – they generate all the code for you! Ok, not all the code, just aspect skeletons for you to implement 🙂 Software Development