The Spring Blog

Spring 2.5 features a new pointcut designator – bean() that allows selecting join points in beans with a matching name pattern. Now it is possible to use the auto-proxy mechanism along with Spring-AspectJ integration to select a specific bean even when there are more than one beans of a type. Earlier, you could use BeanNameAutoProxyCreator to achieve a similar result; however, that mechanism didn’t work with Schema-style or @AspectJ aspects.

Besides selecting a specific bean, this pointcut designator offers two interesting ways to select beans if you follow an appropriate naming convention:

In the aptly titled Nonsense about Interface21, a SourceLabs employee disagrees with my contention that commit rights are necessary to provide credible open source support.

Before I reply: I want to make again something completely clear that I already stated in my last blog, but seems to have been misinterpreted by some: Interface21 has no desire to prevent others making money from Spring. Our track record proves that. We welcome others writing about Spring and providing Spring services. Or basing products on Spring, like Matt Raible’s AppFuse. We wish them success. Spring has partly gotten where it’s gotten to through the richness of the ecosystem around it. As technologists and as a company we have always fostered that and we always will.

My blog a couple of months ago about models of open source businesses seems to have struck a chord. I’ve had many positive responses, and it prompted an interview request from a site called “How Software is Built”. My interview is here.

Finally someone from OpenLogic has posted an interesting reply. Bryan Noll left some comments in a reply to my blog that merit a proper response.

First and foremost, I think your assertion that it is not healthy for a project or open source in general when people who have no real investment in a particular project offer support for it is an interesting one… one I've not heard before. I think there's enough validity to it to make a company like ours consider it and genuinely examine our responsibility to the open source projects we support. The result of this examination, in my mind, would be a demonstrable policy OpenLogic would have in order to mitigate the potential concerns you're raising. I'm sure I don't know what exactly that would be, so allow me to be vague at this point. This dovetails nicely though into some of the issues I have with what you're saying.

Up to this point the Spring Portfolio Maven artifacts, especially the snapshots, were inconsitently created and scattered about in various locations. Over the past couple of weeks, we’ve been working to get the projects to be more consistent in the creation and uploading of these artifacts.

Maven Repositories

One of the most useful improvements to the Maven support in the Spring Portfolio is the use of consistent repository locations. There are three different repositories depending on your level of comfort with the code.

My first blog post - and what a big announcement to make :-)

After a series of Spring 2.1 milestone releases, we’ve been reviewing the overall set of features that we introduced:

• full Java 6 and Java EE 5 support (JDBC 4.0, JTA 1.1, JavaMail 1.4, JAX-WS 2.0, etc)


• full-featured annotation-driven dependency injection (including support for ‘qualifier’ annotations)


• support for component scanning in the classpath (autodetecting annotated classes)


• bean name pointcut element in AspectJ pointcut expressions


• built-in support for for AspectJ load-time weaving (based on Spring’s LoadTimeWeaver abstraction)


• further XML configuration namespaces (“context”, “jms”) for maximum convenience


• extended SimpleJdbcTemplate functionality (support for named parameters etc)


• officially certified WebSphere support (support for the WebSphere 6 UOWManager facility etc)


• Spring framework jars are shipped as OSGi-compliant bundles out of the box


• Spring ApplicationContext can be deployed as JCA RAR file (for headless application modules)


• JCA 1.5 message endpoint management (for Spring-managed JMS and CCI message listeners)


• completely revised framework for integration tests (with support for JUnit 4 and TestNG)

Interface21 got mentioned in testimony before Congress.

Jonathan Silver, a venture capitalist and founder of Core Capital Partners, testified on Thursday against proposed changes in tax rates applying to VCs. One of his arguments was that venture-based companies create jobs across the US:

Where will the next important businesses come from? The truth is, no one knows and that’s why venture capitalists look everywhere, and in all fifty states, for those opportunities. It’s why venture funds have backed Music Nation in New York City and Incept Biosystems in Ann Arbor, Michigan, Interface21 in West Melbourne, Florida, Boston Power in Westborough, Massachusetts and Click Forensics in San Antonio, Texas.

It’s time for the next Java Meetup again. I decided to postpone the 7th installment of this quarterly event in Amsterdam until right after summer, because most people here in The Netherlands take a couple of weeks off in August or so.

I’ve looked at our internal schedules and it seems September 21st is the only day left in September, so I hope it fits with other people’s schedules as well.

We’ll be doing it at the same location as last April’s meetup, as this is pretty convenient for us and everybody seems to be fine with it. The first Java Meetup ever was held in my favorite Amsterdam hangout, the Wijnand & Fockinck, but we quickly realized this is way too small to accommodate for 50 to 100 people and moved to the Jaren.

In a recent blog entry Marc Logemann touches on the subject of proxy performance. In his entry he asks for a white paper by ‘the Spring guys’. I don’t want to spend (p)ages and (p)ages on discussing the differences up to the nanosecond between proxies and byte code weaving mechanisms, but I do think it’s valuable to re-iterate once again what the differences are and whether or not this discussion matters at all.

What are proxies and why do we use them?

Let’s first shortly revisit what proxies are used for (in general, and in Spring). According the Gang of Four (GoF) book on Design Patterns a proxy is a surrogate object or placeholder for another object to control access to it. Because the proxy sits in between the caller of an object and the real object itself, it can decide to prevent the real (or target) object from being invoked, or do something before the target object is invoked.

Introduction

Grails seems to be going from strength to strength, and it looks like it definitely “has legs”, as they say. I am quite interested in stretching those legs a little outside the web application arena. If you are aware of my work on Spring Batch, you will probably be able to guess where that might take me. But for this article I wanted to just share some experiences I’ve had with the basic, low-level deployment and build of a Grails application.

I have a love/hate relationship with Maven 2, and I am learning to love Grails, but sadly the two do not play particularly well together. It would be really nice to see tighter integration. Maven is not always everything we want it to be, but there are some things that really make it worthwhile. It is a standard of sorts (love it or hate it) so when I download a project from somewhere I already know how to build it, what its dependencies are and where the documentation is. Grails has some of the same features, and in fact includes its own quite sophisticated build tool based on Groovy scripting of Ant. Maybe there is a middle way, where we can have the best of both worlds?

A couple of month ago, we start publishing polls on www.springframework.org asking people to provide their feedback about Spring, some of its features and how they are using those features. The first question I posted was whether or not people were checking required dependencies and if so, what mechanisms they used. I quickly followed up on this question asking the community what transaction management strategy it used.

To my delight when I first checked the results, back in March, a lot of people told us by voting in the first poll that they were using the @Required annotation. The second poll–on transaction management, quickly showed that a lot of people were using the @Transactional annotation. Below you can find some of the results of the poll about checking required dependencies. Together with the poll on transaction management (about 30% of all respondents are using the @Transactional annotation to demarcate transaction boundaries) they consistently show that people are using Spring 2.0 a lot, which was very good news for us. Because upgrading an application that uses Spring 1.x to use Spring 2.0 shouldn’t be any issue, we really hoped people would not stick to Spring 1.x and in fact, people massively upgraded.