Is Spring AOP so limited?

[michaelf]

Hello!
I’ve started to use SpringAOP and the creation of Before and After advises were really fast.
Unfortunately, I can see the limitations which prevent me to use SpringAOP for a real application.

1) It is possible to advise only the beans witch registered in some application context.
2) The advices will be called only to beans allocated with some BeanFactory
3) The result from the items 1) and 2) is that it is impossible to add advices to Servlets, EJB and other files allocated by Servlet or EJB containers.

I just want to check if I am correct.

[snpe]

1) and 2) is correct, of course.It is spring AOP

3) You can instantiate servelt filter,EJB etc with spring context

For general AOP you need AspectJ or AspectWerktz, but for the most thing spring AOP is enough

regards

[kantorn]

Just for the record:

I find your subject line a bit strange. What do you mean by it? Sounds as if you're terribly upset about something. (?)

Spring AOP does exactly what Spring AOP could be expected to do, and from what I gather it's a highly developed and potent AOP framework. It's open source (free!!), a lot of skilled programmers have put a lot of sweat into it. Please respect that. Furthermore support is free on this forum.

And tell us when you have found the tools to build a "real application". At least I'm interested.

[michaelf]

Dear kantorn!

I DO respect the Spring framework and the big effort of many people.
I DO respect Rod Johnson and his books are always on my table.
I DO NOT have any intention to injure anybody.

I am now in the middle of the investigation. We are ready to start big J2EE project (couple of years for couple of people – so called “real application”).
My task is to choose the AOP framework from the following open source, free, GLGL frameworks:
SpringAOP
JBossAOP
AspectWerkz AOP

For now my favorite is JBossAOP, but I want to be fair and do not want to miss something.

Please note, that I think to use Spring framework for application context and it is GREAT thing, but JBossAOP is really good AOP framework (once again, I DO NOT have any intention to injure anybody).

[ego]

My 2 cents....

AOP is good, ok. But be carefull because AOP is new. I mean that because AOP is new, people/programmers/designers have to invent a new way to design an application and I'm not sure that everybody is mature with that.
So, what is really important with SPRING is that it helps you to create a entire application/tiers. SPRING AOP is not AspectJ but it helps you to integrates the AOP concepts to ease the use of all J2EE components/APIs and more. And to my point of view it is the more important because it helps you to incrementally migrate toward AOP with concrete usages.

[Ben Alex]

Most AOP concerns relate to the services or persistence layers, such as transactions and security. Spring AOP handles these layers brilliantly, as the related POJOs will be coming from its IoC container. There are three areas you might want to use AOP aside from these layers:

1. Domain object instances. Having a POJO that can access its own data access object and do things, or enforce its own security via AOP, is an interesting option. You can actually do the latter today using Acegi Secuirty + AspectJ. You can do the former by creating the POJO and passing it to Spring's AutowireCapableBeanFactory.autowire method, and on the read side using org.springframework.orm.hibernate.support.Dependen cyInjectionInterceptorFactoryBean. Be cautious about IDE support if developing AOP advised domain objects. For example, I found AspectJ's Eclipse IDE support a little too slow to develop a large application with (due to limited incremental compilation, at least when I looked). Given this, I use Spring IoC's AOP support + Acegi Security to enforce domain object instance security via interception of services layer method invocations.

2. Servlets. What sort of advice does a servlet need that cannot be achieved using a Filter? For example, Acegi Security provides filters which enforce web request security.

3. EJBs. With the notable exceptions of legacy system integration or political reasons, I cannot see why people would use EJBs for brand new applications. Even reasons that were valid six months ago are no longer valid, such as transparent propagation of security identity from server-to-server, and the absence of messaging support in Spring. Whilst Spring doesn't handle transparent transaction propagation from server-to-server, this is an unusual requirement and could often be deveoped using messaging patterns. So any AOP limitations concerning EJBs are unlikely to be issues for most new Spring applications, simply as EJB with AOP isn't generally a technical requirement.