All Things WebSphere

The advantage of pointcuts in Spring is that we don’t have to change every individual piece of code we want to be notified about.  We simply write the pointcut with a wildcard match. JEE interceptors seem to be able to be configured using XML instead of annotations

With CDI, Interceptors are defined and configured via annotations (@Interceptor and @InterceptorBinding) and are ONLY enabled via XML. In your case you will ONLY enable the FrameworkUsageInterceptor in the beans.xml file. You will have the following beans,xml in your application
<beans
  xmlns="http://java.sun.com/xml/ns/javaee"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
  http://java.sun.com/xml/ns/javaee/beans_1_0.xsd">
  <interceptors>
     <class>com.allstate.audit.FrameworkUsageInterceptor</class>
  </interceptors>
</beans>

The nice thing then about AOP is that we can create some kind of cross cut notification of code use.  The advantage of pointcuts in Spring is that we don’t have to change every individual piece of code we want to be notified about.  We simply write the pointcut with a wildcard match.  

This can be done with Java EE CDI by creating a FrameworkLoggingInterceptor that intercepts ALL method invocations and applying the InterceptorBinding (say @FrameworkAudit) dynamically at runtime during application startup to all the application code. http://www.warski.org/blog/2011/03/timing-interceptor-for-cdiweld/  solves a similar problem and explains how to write a timing interceptor where the interceptor applies to any arbitrary code in the app. Code in the application is agnostic of the timing interceptor. You have to follow a very similar approach for your common framework audit interceptor.  CDI extensions will work across application servers since they code to SPIs defined in the Java EE spec.

You will be writing a CDI extension similar to how you will be writing java advice or a pointcut. the beans advised with AOP need to be annotated with @Service or @Component. The CDI extension does this automatically for you i.e. make all the application classes eligible for interception.

Another advantage to Spring AOP is that we can use it outside of a JEE container,

CDI container can also be run standalone i.e. outside the container. Currently WAS does not support this client mode; however the CDI spec and other open source projects are all moving in this direction i.e. to define CDI behavior in a client container. see  http://struberg.wordpress.com/2012/03/17/controlling-cdi-containers-in-se-and-ee/  The reference implementation of CDI called Weld comes with a client container.  Please also look at project Arquillian which makes testing with CDI and Java EE easy.  My advice would be to stick with Java EE and do integration testing with httpunit or httpclient, You don't need to use arquillian or Weld. A standalone CDI container would have been nice for WAS.