The Spring Framework has a fairly toned down, pragmatic view of AOP. This article covers the basics to get you quickly developing using aspect orientation in Spring. It shows how to declare pointcuts and advice in order to apply aspects using the unique facilities that the Spring framework provides.

XML Configuration of Spring AOP

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC
    "-//SPRING//DTD BEAN//EN"
    "http://www.springframework.org/dtd/spring-beans.dtd">

<beans>

   <!-- Bean configuration -->
   <bean id="businesslogicbean"
   class="org.springframework.aop.framework.ProxyFactoryBean">
      <property name="proxyInterfaces">
         <value>IBusinessLogic</value>
      </property>
      <property name="target">
         <ref local="beanTarget"/>
      </property>
      <property name="interceptorNames">
         <list>
            <value>theTracingBeforeAdvisor</value>
            <value>theTracingAfterAdvisor</value>
         </list>
         </property>
   </bean>
   <!-- Bean Classes -->
   <bean id="beanTarget"
   class="BusinessLogic"/>

   <!-- Advisor pointcut definition for before advice -->
   <bean id="theTracingBeforeAdvisor"
      class="org.springframework.aop.support.RegexpMethodPointcutAdvisor">
      <property name="advice">
         <ref local="theTracingBeforeAdvice"/>
      </property>
      <property name="pattern">
         <value>.*</value>
      </property>
   </bean>

   <!-- Advisor pointcut definition for after advice -->
   <bean id="theTracingAfterAdvisor"
      class="org.springframework.aop.support.RegexpMethodPointcutAdvisor">
      <property name="advice">
         <ref local="theTracingAfterAdvice"/>
      </property>
      <property name="pattern">
         <value>.*</value>
      </property>
   </bean<

   <!-- Advice classes -->
   <bean id="theTracingBeforeAdvice"
      class="TracingBeforeAdvice"/>
   <bean id="theTracingAfterAdvice"
      class="TracingAfterAdvice"/>

</beans>

Read more in An Introduction to Aspect-Oriented Programming with the Spring Framework, Part 1

Simple and great AOP feature by Spring!
But In my humble opinion the best and most practical way
of leveraging AOP is using j2se1.5 annotations(sometime in the future)
to make it simple to use, to not challenging with complex XML
configuration files, see the XML of this article , just for a simple test
class we have to define many things,
Has anyone used Spring in a large scale project?

Spring 1.1 will also include integration with AspectJ, allowing the Spring IoC container to configure AspectJ aspects using Dependency Injection. Adrian Colyer (AspectJ lead) blogged about this a while ago, and support will be included with the Spring 1.1 RC1 release next week.

I believe that both proxy-based AOP frameworks (like Spring and DynAOP) and full-blown AOP solutions (like AspectJ) are valuable, and I'm excited that Spring users will be able to use the full power of AspectJ within a consistent configuration model.

Rod

Annotations will definitely be useful in some cases--for example, providing information about transaction propagation and isolation to a transaction aspect. (In fact, Spring supports that model now, with much simpler XML configuration. The problem is that J2SE 1.5 isn't released yet.) However, adding an annotation will usually mean that the class in question knows about the advice that will apply to it. This isn't always appropriate, and partially defeats the pointcut concept.

Rod,

I have been working on some personal projects using the spring framework for a few weeks and just want to extend a big thanks to yourself and your team for developing such a wonderful library. I have found that with many framework I reach a certain impasse where their is no clean solution to a particular hurdle. I have yet to reach this situation to spring (I have had to create a couple of implementations of existing spring interfaces to suit my needs, but it is exactly this flexibility which seem to prevent reaching these impasses).

I have yet to delve into the proxy-AOP support by intend to implement logging, auditing and transaction management using this method.

I have been using the acegi library to provide security services. I dont know how close the relationship is between your team and the acegi developers but it seems that one area where the standard acegi classes fall a little short is in assigning security contexts to methods and URLs (it seems that the current default implementation uses a fairly obscure regex style to map methods calls and urls to roles).

As I said, I am unsure of how much influence you have over the acegi development, but it would be interesting to see an alternative method where roles were assigned to resources using AOP wrappers around target beans (for method invocation security) and around the actually controller 'modules' (for web based URL security).

Something to consider perhaps?

Once again, thanks for the work you have put into Spring.

...
 I dont know how close the relationship is between your team and the acegi developers but it seems that one area where the standard acegi classes fall a little short is in assigning security contexts to methods and URLs (it seems that the current default implementation uses a fairly obscure regex style to map methods calls and urls to roles). As I said, I am unsure of how much influence you have over the acegi development, but it would be interesting to see an alternative method where roles were assigned to resources using AOP wrappers around target beans (for method invocation security) and around the actually controller 'modules' (for web based URL security).Something to consider perhaps?Once again, thanks for the work you have put into Spring.

Wesley,

The Acegi Security framework for Spring was mostly written by somebody called Ben Alex. I'm the only Spring developer who's also an Acegi Security Framework committer, and we all have a good relationship with Ben, but he is responsible for probably 95% of the Acegi lib.

You'll have to clarifly what you mean by using AOP wrappers to assign roles to resources. Of course, AOP wrappers are _used_ to enforce method security, but the regex mechanism you mention is simply a form of pointcut to specify where the security interceptor should apply, e.g.

<bean id="bankManagerSecurity" class="net.sf.acegisecurity.intercept.method.MethodSecurityInterceptor">
   ...
  <property name="objectDefinitionSource">
    <value> net.sf.acegisecurity.context.BankManager.delete*=ROLE_SUPERVISOR,RUN_AS_SERVER
      net.sf.acegisecurity.context.BankManager.getBalance=ROLE_TELLER,ROLE_SUPERVISOR,BANKSECURITY_CUSTOMER,RUN_AS_SERVER
    </value>
  </property>
</bean>

From an example security interdeptor. Given that this interceptor can ultimately be applied to any object, this is actually a fairly clear and concise mechanism to specify what classes and methods to apply the role checks on.

All of the Acegi framework is built in an IOC style, so it's completely pluggable, including the source of the information as to what roles are required for what objects and methods. (These pluggable sources are in fact pretty similar to how the Spring transaction interceptors work). You could of course have an implementation which reads required security role information from JDK 1.5 annotations (or an alternative like commons-attributes). Whether it'd be appropriate to tie that information so closely to the java class being affected probably depends on the scenario. Personally most of the time I wouldn't want to do that, as the class shouldn't care.

With the AspectJ integration that is available now, I could see AspectJ notation being used to specify where an Acegi based security interceptor should apply. Given the tool support for AspectJ, there are probably some nice potential benefits to this approach, in terms of being able to manipulate these pointcuts in your IDE. There are of course some disadvantages too, such as the fact that the AspectJ compiler now has to be used.

If you've got some ideas, I encourage you to sign up to the acegisecurity-developer mailing list, and send them in. Ben is extremely responsive.

Regards,
Colin

Colin,

I dont think I was being as clear as I could have been. Also, please bear with me because I am certainly a greenhorn when it comes to many of these concepts.

Lets take the example of URL based security (The FilterInvocationInterceptor). The mapping between the security role required and the actual code that handles that URL invocation seems to be based on a list of URL's and the roles required to access them. I can understand the benefits of this approach but I have found that if I decide to change my controller mappings I also have to go back and change the information supplied to the objectDefinitionSource attribute of the FilterInvocationInterceptor.

I wonder whether it would be possible to obtain the information provided by the objectDefinitionSource from the Controller itself.

Lets say I have a controller called 'AdminController' that provides the model and the view for a system administration screen. This controller is mapped to /admin/index.html. The objectDefinitionSource in the FilterInvocationInterceptor has '\A/admin/.*\Z=ROLE_ADMIN'. If I later decide that the admin URL shoudl be '/tools/admin.html' I have to change both the controller mapping and the objectDefinitionSource.

This is not a major problem, and perhaps I am splitting hairs but if the 'ROLE_ADMIN' was assigned directly to the controller then I could remap URLs without needing to reconfigure the security system.

I suspect that a similar approch could be used to wrap the 'BankManager' bean in your provided example, this would allow the security information to remain 'attached' to the object that it is securing.

I hope this was a little clearer.

Wez

Wesley,

I see what you are trying to say w/regards to the web request controller. One thing to keep in mind is that the Acegi security interceptor, when it applies to web requests (my example would have been from a business layer bean), applies at a different layer than the Spring controlelr mapping. The former is done via servlet filters, and is able to do things like automatically redirect between http and https, apply security constraints, etc., well before any other spring framework code like the controller mappings is executed.

That said, both the source of the mappings for acegi as to what to intercept, and the Spring web controller mappings, are pluggable, so it would probably be realistic to draw the information from a common source.

I invite you to bring this topic up on the acegisecurity-developer list if you wish to continue the discussion, as it's probably a much better place for it past this point.

Regards,
Colin

Not sure if it qualifies as 'large scale' yet , but Red-Piranha (Lucene Based Search and learning) uses Spring as it's framework. It makes the design of the system a lot more modular and scalable , and gives us the ability to run from Tomcat , the command line and J2EE servers.

Project is available on sourceforge at : http://red-piranha.sourceforge.net

I just love Spring, don't you? :->