Rob, Juergen, can you tell us a bit about yourselves and your work with Spring?

Rob: I'm Rob Harrop the core developer on Spring right now, I'm working with Juergen mainly, we develop most of the framework alongside with Rod who does quite a bit of coding, but mainly me and Juergen work on all the maintenance and all the features. In my day to day job I'm working as Principal Consultant at Interface21 where the company provides support, consulting and training around Spring. Most of my work life is spent with Spring, with clients, with large scale projects and most of my night life is spent also with Spring in the truly sad life of a Spring developer. Juergen: I guess my situation is not that different. My name is Juergen Holler, I'm co-founder of the Spring framework project and I guess I have a similar day and night life. In my day life I'm both Principal Consultant and CTO at Interface21 and also responsible as a technical lead for the Spring framework project which means there's a lot of coding which tends to shift into the night, the weekends and all the other time when normal people go out there and do something with their lives.

You recently announced Spring 2. What are the big highlights there?

Rob: I think the biggest highlight on the Spring 2 is quite clearly from the feedback from all the users, on the XML configuration. It's much simpler now to configure infrastructure components like AOP, Transactions, JNDI. I think that has really been a big help from the users. I guess aside from that there's also AOP, the AspectJ Integration, the JMS asychronicity and the task execution and a bunch of other features as well. Juergen: It has become quite a major release overall. So while from the technical perspective we actually build on existent facilities as far as possible, from the user's perspective, from the application's perspective, there are a lot of major enabling features in this release. We are looking forward to seeing the adoption. Rob: The final release can take quite a few additional things as well as portal support (a big one for many users), MVC support is going to be increased, it's going to be more conventional over configuration support. We've a lot of feedback from the Ruby community, from the Java developers who are on both sides of the fence. I think it's important to take their feedback into consideration and try to make it easier for people to configure. Surely that's been one of the biggest pushes in this release: to make all the framework components easy to configure whether that is through custom XMLtags or just general configuration improvements in that area. Juergen: There are really different angles towards this release. There's the configuration angle that we are tackling with quite new approaches compared to the Spring 1.x general format. We're going quite a step beyond. There also the application integration angle that we're tackling, so we're doing further work on the integration with the specific application server features beyond Standard J2EE. The third one is closing gaps in the functionality such as the portlet support and asychronous JMS

Previously Spring only had smaller point?Why are you now calling it Spring 2 and not Spring 1.3?

Rob: There are a number of reasons why we are calling it Spring 2. I think it's important to understand it wasn't a decision that we took that lightly; there was a lot of discussion about this between the main guys, whether we should call it Spring 1.3 (which was the original plan) or whether we should move to 2.0. And I think in the end the fact that we have switched to a new model for configuration, which essentially is the core part of how many people introduced to Spring as into we had such a new model for aspects or into programming with the aspectJ integration there were so revolutionary features in terms of the way Spring was working that it was preferable to move to 2.0 as opposed to 1.3, just to give users an idea of how far a jump forward the move was. Juergen: It jumped forward in particular from the useage perspective. We previously tented to look at it from the internal perspective where we thought it really needed radical, major internal changes to do a major version upgrade jump, but in the end it seemed reasonable to take the user's perspective; if from the user's perspective there are major new enables, major new features that change the everyday usage of Spring for many people or is about to change those, then from this perspective a major release seemed absolutely justified. Rob: I think the original assumption that we would actually make that change when it was a major change for us in terms to the entire container it was actually a flawed - it doesn't matter to the users whether we made a major change to the container as long as it is completely backward compatible, as long as it still works. The big version change in my opinion should be a change to the user model quite as radical as what we have. So while it was full backward compatible (we had to place a lot of emphasis on that you can take just any existing Spring application, it will run with Spring 2.0(. The big thing is the user's model going forward as they develop new applications, as they update their existing applications will have changed quite a bit with the new configuration. Juergen: And it will also be identified as "this is Spring application" because it is obviously using the schema support rather than the pure DTD based. Rob: An interesting thing to know is that if you look at the movement between individual versions so far people wouldn't necessary say: that's a Spring 1.2 application or a Spring 1.1 application. Certainly with the new configuration people would say "That's a Spring 2.0 application", or with the AOP "That's a Spring 2 application". It seems right when you take that point into consideration, that you should be doing it with a 2.0 as opposed to 1.3. Juergen: If we hadn't jumped now when would we have had a major version? It's a bit like the JDK syndrome where essentially Sun decided to introduce a major version jump later on and we wanted to avoid that situation.

What are the main drivers behind the new xml format and why did you choose xml again given all the backlash?

Rob: I guess we can attack the second question first about why we chose xml again. The main reason is because xml is not really that bad when you take everything into consideration. I was just with one of the people today talking about how the configuration format is not human readable and is hard for humans to comprehend. Well if you look at that point of view I think most people have been correct in that assertion. If you look at the Spring configuration in Spring 1.2. Any developer can read that and understand it. It's fairly simple to understand. And an important think to understand from the configuration file point of view is that people want tooling; and if you want to get tooling for free you need to use xml. There's no substantial tool support for Ruby, there's no substantial tool support for plain text, so if you want to get really good tooling support out of the box you need to know how use xml. And that's why we decided to stick to xml and also why we wanted to move to schema as opposed to DTD validation, because there's much stronger tooling when you're using XSD And actually the pairing of the schema and the xml is a really strong model for tooling support. You can get quite impressive code completion with very simple schemas. Juergen: With strong semantics expressed by the underlying schema essentially, giving standardized semantics that any standard xml editor, as you get it from your development environment is essentially able to provide huge benefits in terms of code completion and static validation. Rob: One of the other benefits of xml is name spaces. Namespaces is essentially the key enabler in Spring 2.0 for pluggable configuration. We didn't just want to lump a bunch of tags into the main DTD or the main schema support it that way. We wanted an extensible approach where you can plug in additional tags and have additional classes to handle those tags. And name spaces is a really good way to do that. Xml with schemas with namespaces is the ideal form of for building toolable and extensible configuration. The nice thing we got with the current model is that third party products can build their own schema, build their own harness for configuration and just have auto discovery when they start up in the Spring application. Juergen: Which we are also using in Spring core itself -autodiscovery of all higher level functionality tags, which was an important concern we had; we were essentially wondering whether our project, internal decoupling between those subsystems might pose a problem the long term in getting convenient higher level functionality into the configuration format, but it turned out that we were actually able to fully keep the internal decoupling while providing the highest level conveniences into the configuration file which is an ideal scenario for us. So we are a little different from traditional deployment descriptor driven tools products that essentially where there's a central God configurer that knows the entire system reach in that file and does whatever is necessary, Spring is very different in that respect, since the core container still doesn't know anything about the AOP or transaction demarcation or whatsoever. That's all done by the autodetect namespace handlers. Rob: So back to the original question "What is the main motivation behind the xml?": simplicity. We just wanted to make it simple for users to configure Spring and moreover to make it simple to configure the core parts of Spring like AOP, like Transactions, like JNDI, the kind of infrastructure components you need to use Spring. It's always been our goal that it should be as simple as possible to use Spring, and while the initial xml configuration is very simple it can be a little bit intimidating to new users and I think it can be one of those things is quite hard to maintain. If you write configuration, it might be easier when you do and refresh, when you come back three or four months down the line, is it so easy to understand again? I think the biggest barrier there, is that the bean tags don't necessarily display the intent of what you want to configure. They are really good for generic configuration; they just don't explain the intent of what was configured. Juergen: It's the limitation of generic configuration model where essentially every component is treated with the same configuration format so it's of course not very expressive in terms of the actual intent of a specific component definition. This is essentially what the new configuration format makes much more explicit, much clearer upfront which shows in all forms validation as well as code completion where it's now much clearer what's available, which name spaces, which tags in the name spaces. Rob: Of course now we got the best of both, we got completely generic configuration and the custom configuration which can be used independently or together. There's complete interoperability there, so it's quite nice.

What are some of the big configuration changes and what are the migration paths for the existing Spring projects?

Rob: Some of the simple changes: if you look at a typical use case in any enterprise application, looking up a data source from JNDI; right now that's a JNDI object definition with a normal bean tag. So in the new Spring configuration you just got the JNDI name space and there's a look up tag in that name space and you just specify JNDI name and you get code completion for all the things that are required. I've seen JNDI names that actually required property and you get code completion for that. Then on top of the JNDI stuff we got util properties for creating a property instance and we got support for collections like maps, lists, sets. The big two that we did originally were AOP and the Transactions. AOP was the main one we wanted to do. We wanted to have simple configuration for advisers. At the same time I was working on that the work was going on with the AspectJ Integration and that was mainly exposed via code so there was mainly a Java API for doing that and the new tags helped so I was actually exposing the AspectJ stuff via XML as well. So it's not just simplified functionality there for the existing AOP style in Spring, but also new configuration support, new AOP style with AspectJ, and the AspectJ annotation model. Juergen: That's a natural fit in terms of the configuration model. Rob: There's a bunch of other stuff there: scheduling, remoting, the core parts of Spring, essentially the infrastructure parts of Spring that are not in the users' application.

What advice do you have for people currently using Spring heavily in terms of how to migrate to the new configuration format?

Rob: Don't change if you don't have to. We've spent a lot of time trying it make it so that you can just deploy your DTD validated files without any changes into the framework. That's not something that's supported by xml parsers . SO an xml parser can't just choose between a schema and DTD on the fly, you have to tell it which one to do, so we've put a lot of effort into that stuff, because we don't want people to change unnecessarily. I guess that if you do want to move across it's a case of either changing to XSD but still keeping the same configuration, if you want to move to XSD validation you don't need to use all the new tags, you can just stick with the schema and then gradually introduce the configuration. If you're starting a new project, the decision is clear; the AOP configuration, the Transaction configuration, those are substantially simpler so a new project will start with those. For an existing project I don't think it's that much of a benefit to move. Juergen: There's also the way to mix and match. If you got a larger project consisting of different modules, different configuration files you can essentially keep all configuration files you don't want to touch at this point just in the generic bean definition format, and selectively introduce the new configuration format to the parts of the application you're actually working on. So there's a very flexible migration path essentially not forcing anybody to migrate. I can even imagine that there are applications that will stick with the pure generic bean definition format for a long time if they don't feel the need for using the specific name spaces. And we will fully keep supporting these applications of course.

What about custom tags? What is the intention there? Should developers need to use custom tags?

Rob: The intention there is that the developers would never need to use to use custom tags. We still believe that the core configuration, the bean tag, is perfectly acceptable for most application configuration needs. Certainly if you got the traditional kind of architecture with value objects, service objects, web tier objects, or data objects you won't be using custom tags to configure your own application components. You'll be using the supplied tags to do AOP and Transactions, but you won't be building myApp: DAO tag for your own DAOs. Where the custom tags fit in, is for third party vendors like ActiveMQ to supply simplified configuration for their products. I think Acegi is going to be one of the biggest wins there because right now it is using the generic configuration in Spring but there are lot of areas where it can benefit from schema based code completion. Juergen: From concise and explicit configuration within the application. While of course those hooks are available for third party products, it's clear that most applications will just stick with the "out of the box" infrastructure tags. I guess infrastructure is all about those tags they are meant to express common infrastructural concerns and we essentially ship like a comprehensive set of tags "out of the box" so we don't really see the need for custom additions to those. Rob: If there is a pressing need for a custom tag, it is going to be something that might have a wider application beyond just somebody's application. So we should try to put it in the framework.

It seems that the industry, both open-source and commercial is tooling up to use annotations to drive configuration, but not Spring 2. Why did you guys not choose that path?

Juergen: Annotations are certainly a really popular mechanism right now which is relevant to Spring itself as well, to some degree. We do embrace annotations in specific areas such as the transactional annotation, JMX export annotation. We do offer some specific facilities where we optionally provide annotations. What we clearly don't do and don't intend to do is build annotations into the core container or into any core facilities. Essentially for us an annotation is one mechanism to express metadata in, but it's in no area within Spring the only mechanism to express metadata . We strongly believe in externalized configuration where it actually makes sense, where externalized configuration is part of the value proposition, so essentially dependency injection really belongs in a really dedicated configuration file. This is the very point of dependency injection. There are some areas where it is a little less clear like transaction metadata: would you want to put those into a java source file or would you want to express those in XML in the bean definition file? We offer both options. People's tastes and needs are different, application scenarios are different and we respect this situation out there in the real world by just supporting both mechanisms. We support those mechanisms just alongside each other as full first class citizens in the Spring world. Rob: What Juergen is saying is that we are not naive to assume that all our clients are just going to jump to Java 5 and start use annotations. We've got a lot of large enterprise clients using Spring and they are using Java 1.4, Java 1.3 and will be using it for sometime. It's not that simple for a client to say "I'm going to drop my current WebLogic or WebSphere installation and just fire over to one of those in Java 5". That's not going to happen. So what we wanted to do is provide those users with a compiling model on any JVM. There seems to be a trend towards mis-use of annotations with annotations solving complex behavior, where annotations are only metadata. We want to take our time with that and we want to make sure we get it right, because when you put out an API you don't want to change it. And we are going to consider any annotations as part of the API. If we get it wrong, and the user model is flawed, it puts us in a strange position. We want to take our time and really have our annotations driven by user needs not 20 annotations that we think are cool and we release them; that's a bad idea.

Why are you positioning Spring so strongly as an AOP solution?

Rob: I think because AOP has a real value to users. We don't do anything unless we believe it's got value. We are not the kind of people who think they got a cool solution and we got to build it. We don't have the time. We spend most of our time trying to build features that would offer value. AOP has the real potential; the potential already is delivering value to a large number of people. I think the area where the AOP is perhaps lacking, is in a cohesive model that is taking users right from the beginning and right through to the full features like Aspect J. And that's where we position Spring 2. The basic model for doing it is the kind of Enterprise services where AOP fits really quite nicely so transactions, security, remoting, JMX exposure, all those cool things; but then as a path moving towards domain main aspects find grained and apply it to the entire application. We wanted to provide a coherent model so between Spring AOP, between Aspect J and in-between as well and we've got a really nice proposition there now. Juergen: We're strongly taking this from the application's configuration perspective to make it as straightforward and convenient as possible, not only to use the "out of the box" infrastructural aspects we ship, but also custom aspects as far as possible, with a high degree of freedom on the application developers' side, features that we selectively want to use but we don't have to use. Essentially they stay out of your way if you don't need them. But if you wanted custom aspects, just right at your fingertips.

Why AspectJ's point cut language?

Rob: Because many people are using AspectJ, it is very powerful and we see AspectJ as something we can align up our product with and we see Aspect J as the next progression from Spring AOP. We see a lot of people using AOP for the kind of things to do now which is transactions, as I mentioned before, but also we see AspectJ as being the logical step for building fine grained domain aspects. What we wanted to do was provide a model for the user to use in both worlds. The AspectJ pointcut expression means two things: it provides that model, it provides that link between the two products and it also simplifies the configuration substantially. So even with the new xml tags without a good matching language for matching on types, on methods basically on other joint points in the AOP program it's very hard to simplify the configurations, so with the new xml and the AspectJ point cut language we've really now got that concise and succint configuration that we always wanted. Juergen: For trivial scenarios where essentially you proxy a single bean with some transaction configuration, it's of course not necessary to have the expression language available so there's where essentially the previous model worked reasonably well; but once you start into applying very specific aspects, define very specific point cuts, you need the power of a more expressive point cut language and that's exactly what AspectJ gives us. From Spring's AOP model it's essentially a seamless move from the AOP alliance model that we are coming from to AspectJ and back. It's essentially a choice of the user concerning which level he'd like to adopt here, so we're still supporting the classic Spring proxy based AOP solution, we're enriching it with AspectJ point cut language to define point cuts and we're moving further in some areas, so there are certainly more stuff to come in this area.

Now you've got support from both POJO and Annotation Driven Aspects. Why did you do both and how does one choose?

Rob: Essentially from the user's perspective they're almost identical aside from the usage of the annotations. And the difference being that with the annotation driven approach the configuration sits in the aspect class itself, whereas with the other approach it sits in the new Spring xml format. The main driver behind the POJO aspects is that they are POJO, so there's no dependence on Spring at all. Unless you use the AspectJ runtime library to access joint point access information there's no coupling there at all. And it gives us a nice side effect which is the argument binding functionality. So if you have a method foo that accepts String and Int, you can point cut that method and have an advice before foo that accepts String and Int and you'll actually get the arguments in a fully typed environment just as you can in Aspect J. This actually realizes the whole thing we wanted for a long time in Spring AOP which is fully typed advice. With the @AspectJ style of annotated aspects, it's a seamless move between Aspect J and Spring; there was a really good proposition for us; you can take one of these things, you can pop it into Spring, you can enable the AspectJ aspects with a single line of xml configuration and you get an aspect, you can apply it to your objects as appropriate or you can take the same aspect, drop it into AspectJ application with AJC compilation or AJDTand Eclipse and you get thensame aspects applied. It's the same class, it's the same aspect, there's no change between the two models. I think that's where the link is now set between the Aspect J and Spring 2.

What is Spring 2 doing to help with the modularization concerns on very large projects?

Rob: We haven't addressed it as a major part in Spring 2 mainly because we had so many other features to focus on, although we have started to move down that road in a very subtle way and you'll see when you look into the AOP configuration now that we tried to keep them all in one place. So the choices are: should we allow advices and point cuts and aspects to be configured all across the configuration file, or should we keep them in a single place? The decision was to keep them in a single place, inside this encompassing AOP conflig tag. I think that's a nice move as it gets to the point where configuration is in a nice succint module. And the next move is to actually take that and make it applicable as a top level file. So rather of having a beans element as your top level element, we're exploring the possibility of putting AOP config as a top level element. But having it pass just a normal Spring configuration file, while allowing a module for your AOP configuration and potentially a module for transaction configuration. But I think right now the main driver behind modularization is to follow some kind of best practice, some kind of naming convention, of beans "these are my internal beans", "these are public beans". Juergen: That's essentially the current best practice that has emerged. We have been supporting auto-discovery of application context definition files for a while, so certainly there are all those facilities that you need, that enable essentially an application architecture where you assemble different application modules, but I would assume that we will add further explicit support in that area - it's certainly on the road map; we're exploring some possibilities in that respect. We're driven by user demand in that respect. Essentially we're reacting to concrete needs users have and for us this is the path that leads to the practical solution that actually adds value to what the users are doing.

What are some common problems people encounter when using Spring and what are the solutions?

Rob: I think one of the common problems that people see is actually proliferation of configuration and this is almost always due to tests. So you'll see people who have a local session factory bean definition and it's the same and they reproduce it in many different files across the application because you've got specific tests that require some other bean to be configured differently. I think there are 2 misunderstandings about how Spring should be used. First of all you can factor out the factory session bean in its own file and compose the configuration into multiple files. You don't want to have a situation where you've got one huge configuration file with everything in it. Take advantage of the ability to compose an application context of multiple configurations, and that way you keep the repetition down because you can reuse snippets of configuration. The other misunderstanding is that people don't really grasp how unit tests should be done with Spring. I think that unit test should be done with Spring. That's the first thing; you don't want to be doing unit testing in the context of Spring. Unit testing should be done without Spring in the picture whatsoever. You don't want to be loading an ApplicationContext, you don't want to be using your configuration files; you should be just using mock objects and wiring the collaborators yourself for pure unit testing. The whole purpose is dependency injection. One of the purposes of dependency injection it to enable that kind of model. For integration testing you really want to be testing real components so you should be using the real production configuration. Obviously externalizing application environment specific things like data source and connection factories, and transaction manager, you can externalize those into long files and bring in different files with a staging environment configuration or testing environment configuration. Juergen: The hard part is to set up integration tested start-up effectively, reasonably faster than those tests running as part of your development process within your IDE, mainly like persistence providers, Hibernate session factory. Those resources really take a while to start up so you want to reuse them. That's where our testing support package comes in it allows you to use context definition for specific testing scenarios. The most important advice to give in terms of handling configurations is to factor out the common parts from the specific parts essentially, factor out the things that change from the things that stay the same, a very general principle in the OO world, applied to configuration files. Rob: In the flipside of that, people would go to the extreme of that and make every bean a sole configuration file, and the intention was never for that to be the case. You want to try to actually separate the static from the dynamic. So things that can change should be factored out, the things that can't change should just stay in the configuration file. Then you might want to do some breakdown based on the layering of your application. It's not just uncommon to see one configuration file for the data tier one for the middle tier, and so on. Juergen: There are different scenarios. Some essentially have horizontal separation in terms of the configuration, some do vertical separation if you have a strongly module based application, it makes more sense for the particular scenario to do it vertically, and from Spring's core container perspective both are valid scenarios so we essentially don't restrict anybody in terms of the choice here. Rob: I think the biggest problem is that people (this is a common case, not just with Spring but with JDK as well) don't understand what features already exist. So they go ahead and re-implement a bunch of stuff like task execution, JMS support; they re-implement support for JDO because they don't know that it exists. All these different things already exist but people don't know about them and go ahead to re-implement them. The key recommendation I always make to my clients is to spend some time browsing through the javadoc, through the source code. You don't have to understand the source, but just to understand what features are available and post that on the main list if you have problems or hire Interface21 if you've got some issues. You need to understand what's available, not just how to use it, just to know that it is there for you to use.

What are the top two lesser known Spring features people should know about but don't?

Juergen: There are certainly a couple of those hiding in Spring. There are some things where it's surprising that even experienced users are not aware of them, or at least not fully aware of their capabilities. Probably the most core feature we're talking about here is the resource loading and the resource pattern resolving which many people are using - at least implicitly - but they don't actually realize the full expressive power of those resource locations where you can essentially throw a single string definition load from the class path, load relative to the current application context, load from a file system location, load from an HTTP server location and mix and match those even as part of the same configuration definition. Also use path patterns in those expressions not only doing name matching in one directory but in the whole directory or subdirectory part of your application. There's a lot of power hiding in those and it's often surprising to find people trying to find a solution for this discovery process and for concise conig locations not knowing the expressive power in the other locations. That's probably my primary one. There are further ones in very specific areas. People are not aware of the javamail support, for example. Those are really more specific things. From the core container perspective I would pick the overall JDBC support package where people do know JDBC template and those prominent DAO implementation classes. But they don't actually know the support that we provide around this, from native JDBC extraction, the lock handling adapters; we provide a number of data source adaptors for lazy connection fetching and for specifying user's credentials seamlessly as part of standard data source invocation, so we provide a number of very pragmatic solutions there; things people have been asking because they need it in their applications. But there is a surprising number of Spring users not being aware of those, often re-implementing them unnecessarily.

Spring MVC, how would you position it compared to other frameworks?

Rob: It depends on where you are classing as other frameworks. If we are going to position it against Web Flow then obviously the two work quite nicely together. We see Spring MVC as essentially two things: it's a great base for frameworks like it; like Spring WebFlow to sit on top of, take advantage of dispatching server, all the cool infrastructural components rooting, interception, all those kind of things. I use it quite a lot with clients and I see it as a powerful MVC model. In the past there have been things that have not been quite as useable obviously the biggest gap we've seen was in the JSP tags, so the lack of support for form tags in JSP, but actually this is solved in Spring 2. With all the features around Spring MVC I have to say it's one of the most powerful MVC tools out there. We've got really comprehensive routing with dispatcher servlet, we've got all the interception capabilities, the built in interception, handler interceptors, the ability to configure Servlet filters in the Spring application context so we've used dependency injection on filters, there's support for file upload, for exception resolving, for all those different kind of infrastructure issues I kind of taken care of in Spring. I think that's a really good benefit of Spring MVC. Of course the controls themselves are so lightweight and they are absolutely trivial to test outside of the server container. Juergen: From the positioning perspective, it's also interesting to see that Spring MVC is actually not like its own subsystem, it's actually a collection of subsystems, so the main value proposition from Springs web support in general is that its reusable subsystems, which can of course be used in conjunction, can be made to work together but also used selectively. So from Spring's dispatcher is for example a self contained solution essentially not being tied to a specific data binding or to any kind of MVC in the traditional sense, it's a straightforward dispatching mechanism for HTTP environments also used for e.g. for HTTP based remoting and also serving as a central hook for plugging in higher level web solutions such as web flow which essentially has a essential entry point, a flow control, in the Spring dispatcher. Spring Web MBC has a different architecture from traditional web frameworks which essentially take a "take it all or nothing" approach so you might find a lot of applications out there which effectively use parts of what you could call Spring Web MVC without being that aware of it. You might have a JSF based application that uses HTTP base remote services living in a Spring dispatcher servlet, happily coexisting with the JSF facesservlet in the same web application. There's a whole world of mixing and matching in that respect. Our Web MVC support is a strong enabler for many other things and one usage is essentially the traditional form controller usage and another is web flow running in that environment benefiting from Spring's dispatcher, Spring's standard field abstraction and also from Spring data binding, which is a separate subsystem. Rob: Here's an interesting issue: because it's so decoupled, you can reuse it in a variety of scenarios; so a reason we have actually build a rest style interface to a CICS mainframe and we used all the core infrastructure of Spring MVC to provide the core HTTP handling and all we need to do is to put a simple REST controller, it was the adaptor between the HTTP request and the backend services that were communicating with the main frame. We want to reuse all that infrastructure because of the decoupling which is a really nice proposition.

What's next for Spring? It seems like Spring is becoming more a stack than a framework.

Rob: It has never been our intention to flash out into a whole stack, we certainly don't see ourselves replacing application servers like WebLogic or WebSphere, rather than just work with those products but there are areas where we can move into where we make sense. I think any area where the programming model comes into question is an area where Spring can add value. We certainly don't see ourselves building database servers or transactions any time soon. What we see though, is a closer integration with the existing application servers. We try to work closely with the Geronimo guys, with WebLogic guys, with WebSphere, as much as we possibly can to build some kind of integration there, to keep Spring working nicely in those products. We need to keep aware of what those guys are doing; if they are building nice transaction stuff, we want to be integrated with that and not have to reinvent it ourselves. Obviously there are a lot of new features on the road map. I think modularization is a big thing for us and I think continued effort to simplify the programming model for people, just to make it as simple as possible. Juergen: We see a reasonable amount of demand for using scripting languages to script bean definitions. There are a lot of things on the road map and we're just fleshing out essentially concrete solutions for those prioritized essentially by the mind. Rob: One of the things we see it's a lot more early announcements and previews of individual features separate from the core framework. We were coming around to the idea of having to release individual previews to give them chances to settle in with the community and foster some feedback. We don't do enough of releasing of individual features early on. What we want to try to do is to package core bits of functionality and package them with whatever Spring releases out so people can feedback. I think that's a mode we can follow in the future. Juergen: Talking about WebFlow and also talking about the stack, about what we could consider a stack, what we are also going for is a road, a product, an ecosystem where Spring is only the foundation and probably what most people will be using as a start, but also having sister projects, related projects, essentially integrating with Spring core and running on top of Spring core with more specific purposes. There's the Acegi security system, on one hand, there's the Spring Web Flow on the other hand which are essentially self contained products with specific ties to Spring core, but having their own release cycle and also their documentation community; it's an important enabler to let those projects have their own life. That's essentially where a whole ecosystem is created, but I would still not call it a stack in the traditional sense where you go from top to bottom with the same provider . Quite on the contrary, Spring will keep its integration focus with existing functionality rather then reinventing stuff that's out there. Rob: One of the big things with we're focused on with integration is Spring.NET to Spring Java. We want to provide a really good model to people using Spring.NET in the a perhaps in a client setting can connectto a Spring Java backend. That's the model we're seeing again and again at our large clients. We've got a lot of cooperation going on with Spring .NET guys so it's quite interesting so see how a lot of core features or ideas behind Spring apply just as well on the .NET platform.