As I've posted before, Interface21 is getting involved with the Java EE 6 effort, and various of our folk including myself, Juergen Hoeller, Keith Donald and Rob Harrop will be involved in a number of expert groups.

This means that we're getting more involved with the JCP in general. We respect the confidentiality and other provisions of the JCP, so we won't talk about anything that isn't public. However, I would like to talk about our goals for JCP involvement and the fundamental approach we will bring. Of course we are just one company among many companies and individuals, so we will just be…

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:

1. Selecting a vertical slice of beans: If you follow a convention where bean names include a string indicating their role from the business perspective, a bean() pointcut can select beans based on their business role. For example, you may use the bean(account*) pointcut to select all accounting-related beans such as accountRepository, accountService, and accountController if bean names start with a string representing their business functionality.
2. Selecting a horizontal slice of beans: If you follow a convention where bean names include a string indicating their role from the architectural perspective, a bean() pointcut can select beans based on their architectural role. For example, you can use bean(*Repository) to select all repository beans if bean names end with a string representing their architectural role. Without the bean() pointcut, you had to rely on the package structure or type-based pointcuts, which can be sometimes a bit too restrictive.

Figure 1: Selecting horizontal and vertical slices of beans based on their names using bean() pointcuts

This pointcut represents a Spring-specific extension to the AspectJ pointcut expression language and as such is useful only in a Spring-based application. The name-pattern follows the AspectJ matching rules for a name pattern with '*' being the only allowed wildcard. Here is a table showing a few example pointcuts and beans selected by them.

Pointcut	Join points selected in
bean(accountRepository)	The bean named "accountRepository"
!bean(accountRepository)	Any bean except the "accountRepository" bean
bean(*)	Any bean
bean(account*)	Any bean with name starting in "account"
bean(*Repository)	Any bean with name ending in "Repository"
bean(accounting/showaccount)	The bean named accounting/showaccount (designating, say, a controller handling that URL)
bean(accounting/*)	Any bean whose name starts with "accounting/" (designating, say, any controller handling accounting-related URLs)
bean(accounting/*/edit)	Any bean whose name starts with "accounting/" and ends with "/edit" (designating, say, any controller handling the edit operation functionality related to accounting)
bean(*dataSource) || bean(*DataSource)	Any bean whose name ends with either "dataSource" or "DataSource"
bean(service:name=monitoring)	The bean named "service:name=monitoring"

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…

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.

I think it would be pretty simple to find such a "demonstrable policy". OpenLogic needs to understand that the opening comment in Stormy's post that "Developers that work on open source software typically have day jobs that pay pretty well...so they work on open source software for free and write code during the day for big bucks" is largely wrong, understand where the open source software they hope to profit from comes from, partner appropriately, and set a price point that allows for genuine support. An alternative would be to stop claiming to provide enterprise support, and be clear that what is being offered is a kind of on-call development assistance, with no guarantee of being able to resolve critical issues. Which takes me back to why I felt strongly enough about Stormy's post to deconstruct it.

I see the aggregation model as a supermarket style business. When I shop at at supermarket, I expect that they will take a (small) cut from everything I buy, in return to dealing with many suppliers, bringing all the…

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.

Release Repository

For any final release (Spring 2.5, Spring Web Flow 2.0, etc.) the Maven artifacts for that release will be uploaded to the Maven Central repository (http://repo1.maven.org/maven2). Using this repository requires no effort on your part as Maven will automatically look for artifacts there.

The artifacts in this repository do follow expected repository behaviors and will not (and cannot) not be removed.

Milestone Repository

For any milestone release (Spring 2.5-RC1, Spring Web Flow 2.0-M2, etc.) the Maven artifacts for that release will be uploaded to the the Spring Milestone repository (http://s3.amazonaws.com/maven.springframework.org/milestone). Using this repository requires you to add an entry to the <repositories/> element in your POM. It should look like this:

<repository>
    <id>spring-milestone</id>
    <name>Spring Portfolio Milestone Repository</name>
    <url>http://s3.amazonaws.com/maven.springframework.org/milestone</url>
</repository>

The artifacts in this repository do not follow expected repository behaviors and will be removed regularly. Upon the release of a final version (Spring 2.6, Spring Web Flow 2.1, etc.) all milestone versions from the previous release of an artifact will be removed. For example, when Spring 2.6 is released, Spring 2.5 milestones will be removed while Spring 2.6 milestones will be retained.

Snapshot Repository

For any snapshot build (Spring 2.5-SNAPSHOT, Spring Web Flow 2.0-SNAPSHOT, etc.) the Maven artifacts for that build will be uploaded to the Spring Snapshot repository (http://s3.amazonaws.com/maven.springframework.org/snapshot). Using this repository requires you to add an entry to the <repositories/> element in your POM. It should look like this:

<repository>
    <id>spring-snapshot</id>
    <name>Spring Portfolio Snapshot Repository</name>
    <url>http://s3.amazonaws.com/maven.springframework.org/snapshot</url>
</repository>

The artifacts in this repository do not follow expected repository behaviors and will be removed regularly. At least the last 10 snapshot builds for a given artifact will be retained. If an artifact is removed from a distribution its snapshot builds will be removed immediately. On the release of a milestone or a final release, all snapshots for an artifact will be removed and a new snapshot for the next release created.

Repository Browsing

The milestone and snapshot repositories are both hosted on Amazon’s S3 service and as such the directory structure is not human-readable. To view the repositories in a human-readable format, use the S3Browse utility.

• Milestone Repository: http://s3browse.com/explore/maven.springframework.org/milestone
• Snapshot Repository: http://s3browse.com/explore/maven.springframework.org/snapshot

Only use these URLs for human-readable viewing. If you use them as the URLs for your POMs you will encounter errors.

Artifact Sources

Another important improvement is the addition of source artifacts for all releases. You will notice in the milestone repository all artifacts have sources deployed with them. This will also be true as we go forward for all final releases as well. Specifically, starting with the Spring 2.5 release, in addition to the combined Spring sources, each module will also have a source artifact.

Spring Snapshots

The final improvement is one that isn’t yet complete; a nightly snapshot of Spring. I’m pleased to say that this is close to being completed. I’m still working out the final kinks with respect to the Maven Ant Tasks but this will eventually start showing up and I’ll announce it again when it does. As well, you can expect this functionality to eventually make its way out to all of the other ANT-based Spring Portfolio projects so that all projects will create Maven snapshots as well as milestones.

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)

as well as many refinements in the details. Almost all of those features are available in the recently released 2.1 M4 already.

We concluded that this goes significantly beyond what we originally planned for Spring 2.1. The version number 2.1, as used for the milestones, does not reflect the significance and the comprehensiveness of the features in this major release.

So I'm pleased to announce that the 2.1 milestones will seamlessly turn into Spring Framework 2.5 as the upcoming major release! Spring 2.5 is scheduled for final release in…

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.

Actually, our headquarters are moving to San Mateo, California. Like many software vendors, we believe that Silicon Valley is the best place to achieve our potential. The largest concentration of our partners is here, and it's a great place to recruit executive talent in the software business. However, Silver's point is still valid. We are creating jobs in Florida--where our web team is based and is currently doing great things with Spring Web Flow…

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…

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.

In other words, proxies can be used as stand-ins for real objects to apply extra behavior to those objects--be it security-related behavior, caching or maybe performance measurements…