The Path to Zen » aop http://www.digizenstudio.com/blog Jing Xue's Weblog Tue, 01 Jun 2010 01:40:50 +0000 http://wordpress.org/?v=2.9.2 en hourly 1 The self-calling limitation in Spring-AOP and one unintrusive solution http://www.digizenstudio.com/blog/2007/05/29/the-self-calling-limitation-in-spring-aop-and-one-unintrusive-solution/ http://www.digizenstudio.com/blog/2007/05/29/the-self-calling-limitation-in-spring-aop-and-one-unintrusive-solution/#comments Wed, 30 May 2007 00:45:52 +0000 Jing Xue http://www.digizenstudio.com/blog/2007/05/29/the-self-calling-limitation-in-spring-aop-and-one-unintrusive-solution/ Spring-AOP is implemented by creating proxies decorating the target bean. One typical gotcha from using these proxies, for instance, in declarative transaction management, is the proxy can't intercept a call made from one method to another on the same target object (typically a service bean), even though both methods are supposed to be wrapped by the proxy.

One obvious solution to the problem is to always explicitly get the bean reference from the Spring context and then call the method on it, instead of calling the method on 'this'. For example, instead of this.anotherServiceMethod(), do:

PLAIN TEXT
JAVA:
  1. // get hold of the application context either through
  2. // a singleton locator or through a private reference, then
  3. context.getBean("aServiceBean").anotherServiceMethod();

It's an easy solution, but one that doesn't come without a few nuisances. For instance, it adds to your service bean some compile-time dependencies on Spring classes that wouldn't have been necessary otherwise.

One less intrusive solution I've come up with is a AdviceSkippingInjector.java that injects the reference to any proxied Spring bean into a property on the "raw" bean, i.e., the object prior to being wrapped in the proxy.

To use it, add a proxiedSelf property to the service bean (it doesn't have to be on any public interface), add this to your context file:

PLAIN TEXT
XML:
  1. <bean id="aService" class="your.proxied.service.Bean">
  2. </bean>
  3.  
  4. <bean id="ProxySkippingInjector" class="com.digizen.commons.spring.AdviceSkippingInjector">
  5.     <property name="beanProperties">
  6.         <map>
  7.             <entry key="aService" value="proxiedSelf" />
  8.         </map>
  9.     </property>
  10. </bean>

In the map beanProperties, each key is a bean name defined in the context, and the corresponding value a property name on the bean. At run-time, if the AdviceSkippingInjector sees a bean name in its map, it will drill into the proxies, find the reference to the original bean, and inject the reference to the proxy into the original bean's proxiedSelf property.

This solution is unintrusive because the service bean remains unaware of any of the plumbing work. All the wiring is done in the application context. In fact, the service bean isn't even necessarily aware that proxiedSelf, despite the name, points to its "proxied self".

]]> http://www.digizenstudio.com/blog/2007/05/29/the-self-calling-limitation-in-spring-aop-and-one-unintrusive-solution/feed/ 2 Inject Spring Beans into JSP Tags http://www.digizenstudio.com/blog/2006/05/07/inject-spring-beans-into-jsp-tags/ http://www.digizenstudio.com/blog/2006/05/07/inject-spring-beans-into-jsp-tags/#comments Mon, 08 May 2006 03:46:02 +0000 Jing Xue http://www.digizenstudio.com/blog/?p=96 Spring 2.0 supports injecting beans into an arbitrary POJO, which isn't necessarily instantiated by a Spring bean factory. This powerful feature is mostly used in injecting into domain objects whose life cycle is usually managed by ORM tools such as Hibernate. But we don't have to stop here, e.g., JSP tags can also be injected the same way. Here's how:

First let's have a sample tag implementation:

PLAIN TEXT
JAVA:
  1. // In order for itself to be picked up by
  2. // Spring for injection, a class needs to wear
  3. // this @Configurable "badge"...
  4. @Configurable
  5. public class InjectedTag extends SimpleTagSupport {
  6.     private AService _service;
  7.  
  8.     /***/
  9.     @Override
  10.     public void doTag() throws IOException {
  11.         getJspContext().getOut().write("Service injected: " + _service + "<br />");
  12.     }
  13.  
  14.     public void setService(AService service) {
  15.         _service = service;
  16.     }
  17. }

Now, in the Spring application context file:

PLAIN TEXT
CODE:
  1. <aop :spring-configured/>
  2.  
  3. <bean id="aService" class="com.foo.AService">
  4.   <!-- configure the service. -->
  5. </bean>
  6.  
  7. <bean class="com.foo.InjectedTag" lazy-init="true">
  8.   <property name="service"><ref local="aService"/></property>
  9. </bean>

That's all there is to it. The tag declaration in the TLD isn't really relevant, because it's no different from what you would do with any other tags, but for the sake of completeness...-

<tag>
    <name>injectedTag</name>
    <tag-class>com.foo.InjectedTag</tag-class>
    <body-content>empty</body-content>
</tag>

]]> http://www.digizenstudio.com/blog/2006/05/07/inject-spring-beans-into-jsp-tags/feed/ 7 The Circular Bean Reference Problem in Spring 2.0’s Arbitrary Domain Object Wiring http://www.digizenstudio.com/blog/2006/02/06/the-circular-bean-reference-problem-in-spring-20s-arbitrary-domain-object-wiring/ http://www.digizenstudio.com/blog/2006/02/06/the-circular-bean-reference-problem-in-spring-20s-arbitrary-domain-object-wiring/#comments Tue, 07 Feb 2006 03:00:22 +0000 Jing Xue http://www.digizenstudio.com/blog/?p=86 Spring 2.0 has an exciting new feature that, with AspectJ's powerful AOP support, allows arbitrary domain objects to be injected with dependencies at the time of creation, even when the domain object is not created by Spring. This feature helps developers avoiding the "Anemic Domain Model" because now domain objects can have references to services or even DAO's, instead of just some other domain objects.

This particular problem comes when I try to inject a DAO into a domain object (I know it's some debatable practice, but please just bear me for a moment). So the DO is annotated with @Configurable, its constructor is advised such that, at runtime, after the initialization, the Spring aspect will try to get a reference to the DAO, and sets it into this new DO instance. However, in order to materialize the DAO, which naturally holds a reference to a Hibernate session factory. The session factory needs to be instantiated first - and that, surprisingly, is when I get the "circular bean reference" meltdown.

After one pint of log reading, three shots of source code tracing, and a pinch of hair pulling, this here turns out to be the story: at the session factory initialization time, Hibernate3 needs to know which id value represents an unsaved object. E.g., null, -1, or whatever sensible value depending on the nature of the object and the corresponding table. This value is specified via the 'unsaved-value' attribute in the object mapping., and, as suggested by the reference, can usually be omitted safely, for Hibernate3 is very smart and can actually guess the unsaved-value by instantiating a new instance of the DO, which naturally would be intercepted by Spring and be injected with a DAO reference, which naturally would need a reference to the session factory, which naturally would have to guess what the unsaved-value is....

The solution is easy - just add 'unsaved-value="null"' to the mapping file, to prevent Hibernate from attemping the guess.

Now, I can hear you making some impatient noise - "what's all this inject-DAO-into-DO business?!" Well, I agree it's some debatable practice, but then it's also hardly the point here. I could well have tried to inject a service object into this DO, and the service object could have held a legit reference to some DAO. It would have been the same circular reference, only a larger circle.

]]> http://www.digizenstudio.com/blog/2006/02/06/the-circular-bean-reference-problem-in-spring-20s-arbitrary-domain-object-wiring/feed/ 2 Inject Into Domain Objects http://www.digizenstudio.com/blog/2005/06/07/inject-into-domain-objects/ http://www.digizenstudio.com/blog/2005/06/07/inject-into-domain-objects/#comments Wed, 08 Jun 2005 02:08:23 +0000 Jing Xue http://www.digizenstudio.com/blog/?p=54 There is an ongoing discussion on the Spring forums around DAO Reference Inside an Entity Domain Object?. Putting aside the debate on whether the idea is sensible from a design perspective, a practical issue in implementing this approach is that, in a sophisticated application, domain objects, unlike those stateless business service objects or DAOs, are usually instantiated by the data access layer, e.g., an ORM tool such as Hibernate. Therefore it's usually hard to inject dependencies into these domain objects through Spring. In this forum post, Rod Johnson and other guys described a way to inject into domain objects by handling Hibernate object lifecycle events, but as of Spring 1.2, the actually implementation is still in the Sandbox. In this blog entry, I will describe another AOP-based approach that "virtually" injects a DAO reference (or any other Spring bean in general) into a domain object.

For the sake of discussion, let's say we have a domain object, DomainObject, and its DAO interface, IDomainObjectDAO. The basic idea is actually very simple - we declare a method in DomainObject:

PLAIN TEXT
JAVA:
  1. public class DomainObject {
  2.     protected IDomainObjectDAO getDomainObjectDAO() {
  3.         throw new UnsupportedOperationException(
  4.         "This method must be either AOP-intercepted, or overridden by a subclass, in order to provide a concrete implementation.");
  5.     }
  6. }

What we put in the method body does not matter, because the execution of this method will be intercepted with a Spring managed advice that actually gets the DAO instance from a Spring context and returns it on behalf of the method at runtime.

There can be many ways to implement the idea. The one described below uses Aspectwerkz's offline weaving, and relies on the AppContextCollector, and Spring-manage Aspectwerkz Aspects ideas, so it might be beneficial to read those two blog entries first.

First we need a holder bean class as the runtime bridge to the target DAO reference:

PLAIN TEXT
JAVA:
  1. package com.digizen.commons.aop;
  2.  
  3. import org.springframework.beans.BeansException;
  4. import org.springframework.context.ApplicationContext;
  5. import org.springframework.context.ApplicationContextAware;
  6.  
  7. public class BeanReferenceAdvice implements ApplicationContextAware {
  8.  
  9.     private ApplicationContext contextRef_;
  10.     private String beanName_;
  11.  
  12.     public void setApplicationContext(ApplicationContext context) throws BeansException {
  13.         contextRef_ = context;
  14.     }
  15.  
  16.     public String getBeanName() {
  17.         return beanName_;
  18.     }
  19.  
  20.     public void setBeanName(String beanName) {
  21.         beanName_ = beanName;
  22.     }
  23.  
  24.     public Object getBean() {
  25.         return contextRef_.getBean(beanName_);
  26.     }
  27. }

The context definition file (with only the relevant parts):

PLAIN TEXT
XML:
  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd">
  3. <beans>
  4.   <bean id="domainObjectDAO" class="com.digizen.dao.DomainObjectDAOHibernateImpl">
  5.     <property name="sessionFactory"><ref local="mySessionFactory"/></property>
  6.   </bean>
  7.  
  8.   <!-- this declares the context collector instance.  Note the contextKey, which will be referenced in the aop.xml below. -->
  9.   <bean id="contextCollector" class="com.digizen.commons.spring.AppContextCollector" singleton="true">
  10.     <property name="contextKey"><value>appContext</value></property>
  11.   </bean>
  12.  
  13.   <!-- configure the advice bean.  The beanName references the dao bean declared above.
  14.           We don't use the bean reference itself because we don't want this advice to hold on to any bean references.
  15.    -->
  16.   <bean id="domainObjectDAORef" class="com.digizen.commons.aop.BeanReferenceAdvice" singleton="true">
  17.     <property name="beanName"><value>domainObjectDAO</value></property>
  18.   </bean>
  19. </beans>

Now in the aop.xml, just add:

PLAIN TEXT
XML:
  1. <aspect name="appContext:domainObjectDAORef" class="com.digizen.commons.aop.BeanReferenceAdvice" container="com.digizen.commons.aop.SpringBeanAspectContainer">
  2.   <pointcut name="getDomainObjectDAOPC">execution(* com.digizen.domain.DomainObject.getDomainObjectDAO())</pointcut>>
  3.   <advice name="getBean" type="around" bind-to="getDomainObjectDAOPC"/>
  4. </aspect>

Once this is weaved into the DomainObject class, getDomainObjectDAO will be intercepted at runtime and will retrieve the DAO bean instance dynamically. Because it does not cache the bean reference, this implementation is not limited to inject singleton beans, but also prototypes.

On first sight, this approach may cause some concerns in the readability of the codebase. However as long as this is used consistently across the application, and becomes a pattern, it is not hard to realize the getter method is being injected - not harder than any average AOP intercepted code anyway. Another plus of it is it does not rely on any specific ORM tool feature (such as the Hibernate events). Finally, if a different way of providing the DAO is needed in the future, a subclass can always override this method.

]]> http://www.digizenstudio.com/blog/2005/06/07/inject-into-domain-objects/feed/ 0 Spring-manage Aspectwerkz Aspects http://www.digizenstudio.com/blog/2005/06/06/spring-manage-aspectwerkz-aspects/ http://www.digizenstudio.com/blog/2005/06/06/spring-manage-aspectwerkz-aspects/#comments Tue, 07 Jun 2005 02:23:33 +0000 Jing Xue http://www.digizenstudio.com/blog/?p=53 Jonas Bonér devised a clever way to spring-manage aspects in his blog Spring and AspectWerkz - A Happy Marriage. The only drawback in his approach is that the bean factory managing the aspects must be called a certain name, and be created by the SpringAspectContainer, which limits the usability because in many cases (e.g. in a Spring MVC powered Web application) contexts might have to be instantiated somewhere else. So as the first application of the AppContextCollector I described in Global References To ApplicationContext(s) Unintrusively, SpringBeanAspectContainer provides an alternative, unintrusive way to manage aspects in Spring.

The main implementation class is the SpringBeanAspectContainer. (See here for the source code of AppContextCollector)

PLAIN TEXT
JAVA:
  1. package com.digizen.commons.aop;
  2.  
  3. import java.util.Iterator;
  4.  
  5. import org.apache.log4j.Logger;
  6.  
  7. import org.codehaus.aspectwerkz.AspectContext;
  8. import org.codehaus.aspectwerkz.aspect.AbstractAspectContainer;
  9. import org.springframework.context.ApplicationContext;
  10.  
  11. import com.digizen.commons.spring.AppContextCollector;
  12.  
  13. public class SpringBeanAspectContainer extends AbstractAspectContainer {
  14.  
  15.     private static final Logger LOG = Logger.getLogger(SpringBeanAspectContainer.class);
  16.  
  17.     public SpringBeanAspectContainer(AspectContext aspectContext) {
  18.         super(aspectContext);
  19.     }
  20.  
  21.     @Override
  22.     protected Object createAspect() {
  23.         String aspectName = getContext().getAspectDefinition().getName();
  24.         int pos = aspectName.indexOf(':');
  25.         if (pos> 0) {
  26.             String contextKey = aspectName.substring(0, pos);
  27.             String beanName = aspectName.substring(pos + 1);
  28.  
  29.             if (LOG.isDebugEnabled()) {
  30.                 LOG.debug("loading aspect bean [" + beanName + "] from Spring context [" + contextKey + "]");
  31.             }
  32.  
  33.             return AppContextCollector.getContext(contextKey).getBean(beanName);
  34.         } else {
  35.  
  36.             if (LOG.isDebugEnabled()) {
  37.                 LOG.debug("No context key specified, try every one registered with AppContextCollector with bean name ["
  38.                           + aspectName + "]");
  39.             }
  40.  
  41.             for (Iterator<applicationcontext> iAppContext = AppContextCollector.getContextIterator();
  42.                  iAppContext.hasNext(); ) {
  43.                 ApplicationContext appContext = iAppContext.next();
  44.                 Object bean = appContext.getBean(aspectName);
  45.                 if (bean != null) {
  46.                     if (LOG.isDebugEnabled()) {
  47.                         LOG.debug("Found bean '" + aspectName + "'");
  48.                     }
  49.                     return bean;
  50.                 }
  51.             }
  52.         }
  53.         return null;
  54.     }
  55. }

When being called to create an aspect instance, this class parses the aspect name specified its aop.xml definition into a context key and a bean name (e.g. "mainContext:myDAO" is parsed to a Spring bean named "myDAO" defined in an application context keyed by "mainContext" in AppContextCollector), and then uses those to get a bean from a Spring context previously created anywhere else. If the aspect name has only a bean name (i.e. doesn't have a ':' in the name string), the container searches through all the contexts in AppContextCollector until it finds a bean with that name.

]]> http://www.digizenstudio.com/blog/2005/06/06/spring-manage-aspectwerkz-aspects/feed/ 0 It’s there, it’s not, it’s there now, it’s not. http://www.digizenstudio.com/blog/2005/04/24/its-there-its-not-its-there-now-its-not/ http://www.digizenstudio.com/blog/2005/04/24/its-there-its-not-its-there-now-its-not/#comments Mon, 25 Apr 2005 01:07:14 +0000 Jing Xue http://www.digizenstudio.com/blog/2005/04/24/its-there-its-not-its-there-now-its-not/ This below is done with aspectwerkz 2.0 in Tomcat 5.5.7.

I have a web app, which I offline-wove with the aspectwerkzc ant task. When I deploy the web app to tomcat (in exploded format), the same aop.xml is copied to WEB-INF/aop.xml. Then when I try to run the web app, none of the aspects would kick in. But if I go to the deployed web app directory, create an empty directory WEB-INF/classes (note that the aop.xml is still under WEB-INF), restart the server, and try to access the web app again, everything works fine.

After a few email exchange with Alexandru Popescu from the Aspectwerkz team, it appears that "WEB-INF/aop.xml would only work in tomcat." So I moved the file to WEB-INF/classes/META-INF/aop.xml. Now everything works fine.

]]> http://www.digizenstudio.com/blog/2005/04/24/its-there-its-not-its-there-now-its-not/feed/ 0