Pointcut expressions for stereotypes

Some of the new additions to Spring in version 2.5 are annotation-driven configuration, classpath scanning for managed components and @AspectJ support for AOP. These features can gretly reduce the amount of XML needed to configure your application context.

Together with classpath scanning came stereotypes, which, as the reference documentation states, make ideal targets for pointcuts. In putting this idea (stereotype as pointcut target) you may find two different candidate expressions in the documentation (the Service stereotype is used as an example): @target(org.springframework.stereotype.Service) and @within(org.springframework.stereotype.Service) with no clear differentiation between them.

However, some of the differences started to show up as Spring auto-proxying mechanism started to try creating proxies for classes that had no stereotype and were not advised in any other way. After a non-immediate web-searching session, the real problem stood up: if you use @target every class is proxied just in case a new subclass with the annotation is introduced. Even though the issue is marked as resolved, I have suffered it in 2.5.6SEC01.

So, in the meantime, just use @within.

Spring and REST

Here's a post on REST Support in Spring 3.0 by Arjen Poustma. I have mixed feelings about this. On the one side I'd prefer better integration with JAX-RS in general and Jersey in particular. On the other side, I appreciate choice and the closer integration.

 

SpringSource App Platform and evolution...

Some days-old news, but interesting anyway. Worth a deeper look.

I think is a concept that many people were thinking about after seeing some big real-word osgi deployments, but it had to be done. Credit when credit is due.

It's hard to balance the need to maintain compatibility (and investment) and the need to keep going forward, and sometimes we all have to deal with some breakage.

Depending on what gets finally goes into Java 7 and the end of the "modularity wars" we may see more interesting steps.

Anyway, there's been some controversy regarding the license. Although I'm sure there's not absolute truth in any camp, if you are a very strong advocate of one position and suddenly (and in a particular issue) change, at least you lose a bit of credibility.

Back to the evolution issues, even though many people argue that the way to innovation in Java (the platform) is other languages on the JVM (scala, groovy, jruby) I think it's high time to start breaking some ties with the past, but, is it worth the effort?....