Josh X Long

Well, naturally I recommend Spring MVC :-) I'm on phone so don't have the references on hand. You might Google Matt Raible's comparing web frameworks talk - he seemed to like Spring MVC too, and (tried) to give reasons

Hi, you have several options: use a cmd line switch, set it explicitly on application context before starting it, and - in environments like web application contexts where the servlet container creates the AC and thus you don't have a direct reference, use an ApplicationContextInitializer to get an opportunity to set the active profiles on an AC before its initialized. This is also ideal for dynamically testing which environment you're in and setting the profile accordingly. See that and other blogs around same time, as well as 3.1 m1 docs for details (I'm on my phone)

Thanks for having us, guys! I know we had fun hanging out. And of course, congratulations to the winners!

I would try making the equivalent request without ajax to see if it caused an error and hence prevented the output from being delivered. One way to test web-service calls (well, besides regular GET requests) is to use Firefox' POSTER plugin (https://addons.mozilla.org/en-us/firefox/addon/poster/). Additionally, give jquery a chance to notify you of the error with an error callback (see http://stackoverflow.com/questions/1740218/error-handling-in-getjson-calls for information on that)

Naturally, the right answer in absence of specifics is, "it depends." Spring MVC and GWT, for example, will both help you "rapidly" build applications that look nothing like one another. So it depends on what kind of application you're trying to build. Additionally, who says it has to be an either-or question: a lot of people embed GWT islands of code /behavior in Spring MVC applications. Simialarly, many people Spring Web Flow AND Spring MVC, or Spring Faces and Spring MVC, or Spring BlazeDS (for flex clients) and Spring MVC, Spring WS and REST support adjacent to a Spring MVC application, etc.

Spring 3.1 offers profiles which lets you conditionally enable certain beans:

<beans ...> <beans profile= "osgi"> <... /> </beans> <beans profile = "default"> ... </beans> </beans>

the idea is that a bean could be 'active' in one environment, but disabled in another. The environment's arbitrary, of course. It might be that you need to use <jee:jndi-factory/> in production and a regular HSQL DataSource in your local environment, and this would help with that sort of situation, too. For more, see http://blog.springsource.com/2011/02/14/spring-3-1-m1-introducing-profile/

Just the tip of the iceberg. I could go on all day, if I wasn't worried my fingers would fall off.... ;-)

Absolutely!

SpringSource highly encourages open source community contributions in all of its projects. We have two giant major code repositories that are Git-based, besides the repository for core Spring, which is Subversion. You can find all the Git code on github.com/SpringSource and git.SpringSource.com.

First, learn about the social community contribution workflow that we like at SpringSource; read this blog: http://blog.springsource.com/2010/12/21/social-coding-in-spring-projects/

That blog posts explains the development model, and how to fork projects - how to work on it locally and how to - if you've found something worth committing - send your contribution back.

You might "start" your efforts several ways. First, the JIRA (jira.springsource.org) is a great way to see the tasks that are coming (this is also a great way to learn what's coming in the frameworks! ;-)). If you think you can contribute to one of the JIRAs there, or that you know how to fix it, and it's small enough, then write up a suggested patch and send a pull request for the corresponding project on github or on git.springsource.org. If it's a bigger contribution, and you're unsure and want a little more guidance after you've tried your best to understand, you might post on the forums or on the JIRA itself, first proposing an idea, and explaining that you feel like you could help, but asking for some guidance.

BTW, this approach is also similar to the one followed by github.com/VMware and github.com/CloudFoundry (the new VMware/SpringSource open-source cloud platform).

There are lots of good sites and projects built using Spring. As to open-source specific ones, well, our own Hyperic monitoring solution is built using Spring and is open-source. The Greenhouse conference schedule builder is open-source and is specifically meant to be used to learn from (https://github.com/SpringSource/greenhouse) - it provides integration with twitter,data access, a web front-end, an iphone and android client and some extra stuff I'm sure I might've missed.

Honestly, I think some of the best uses for AOP can be found in the Spring framework projects themselves!
- automatically proxying calls to objects to expose JMX methods and attributes (killer feature for monitoring and so on)
- automatically map objects to other APIs based on the presence of your own custom annotations. You see this in Spring MVC, Spring integration, the Spring support in the Activiti project, Spring Data Jpa, Spring Hadoop, Spring Batch, Spring WS, etc, where the annotations tell Spring which beans it should proxy to apply things like HTTP request dispatching, etc)
- ReflectionUtils and ProxyFactoryBean are your friends, btw ;-)
- AOP's used to handle API design in a clean way. One example in the Spring framework is the LocalEntityManagerFactoryBean, wihch helps provide an EntityManager to clients that want it. However, once injected that bean is not (usually, unless scoped) re-injected, which means that the object has to be thread-safe in the face of concurrent access. AOP allows you to get a proxied object which in turn delegates to a real EntityManager, but maintains (basically) a threadlocal map of requests so that - effectively, each thread gets its own EntityManager for each request. To the user, it's just one object, though. It makes the resource - which is not thread safe - threadsafe, while not requiring developers to do things like synchronize access on the class variable. In the Spring support in the Activiti project, there's support for access process variables from the current business process scope. Again, here you inject a variable, but the variable is bound to the scope, so it's actually a different value for different threads.
- AOP provides support for things like mixins - you can actually build a single object that exposes several interfaces and delegates to individual implementations.
- there are other niceties like an factory bean that - using AOP - automatically factories any resource, but makes it thread local to a given client, growing the pool as required.

Basically, AOP is a very powerful technology for implementing framework-type stuff. AOP has some great, well defined, immediately useful use cases like declarative transactions, logging, caching (in Spring 3.1), security, etc., but to me its real power is in being able to meet framework challenges when there's no existing solution at hand. (It doesn't matter how good a technology is, it'll never be perfect, so it's nice to know that Spring has your back here, as well)

Well, as always with these sorts of open-ended comparisons, it's helpful to try to be specific. EJB3 (and EJB 3.1) provides a component model for services that manipulate state (most of the time using JPA (and JPA2). The component model assumes that you might need to expose your EJBs for remote clients using SOAP or RMI, and it assumes that you might need to have declarative transactions. It assumes you might want to handle JMS messages in a bean, too. It assumes that you are content working in an application server, which doesn't promote unit testing or portable code. That's (broadly speaking) about it.

If you simply want service objects that are able to manipulate JPA state and provide declarative transactions and be exposed as web services, than Spring provides all of that *and* you can unit test it naturally and you enjoy full support for deploying to other environments like clouds and web servers, not just Java EE application servers.

However, Spring is a much, much, much larger superset than EJB. "Spring" also provides batch processing, web frameworks, much stronger RDBMS support - JPA1, JPA2, JDBC, JDO, etc, mobile client support, big data (Neo4j, CouchDB, Riak, Redis, MongoDb, etc.), Hadoop support, and numerous simplifying APIs for other APIs that EJB has no particular support for, including JDBC, iBatis, etc. Technically there is no reason to use EJB3 or EJB3.1, there is nothing that it can do that Spring can't and a whole world of things that Spring can do that EJB (and Java EE6) can't.

Hi,

Apress' book "Spring Recipes, 2nd Edition," has deep, recipe-oriented introductions to all of the Spring projects. If you want a quick bootstrap, please consult the "Green Beans" series of blog posts on SpringSource's website. You can, generally, read them individually without any dependence on one another except the first - http://blog.springsource.com/2010/11/09/green-beans-putting-the-spring-in-your-step-and-application/ - which introduces Spring core. All of them cover Spring 3.0 and later, and http://blog.springsource.com/2011/01/04/green-beans-getting-started-with-spring-mvc/ covers introduces Spring MVC. All of them are intended as comprehensive, wholistic introductions to the technologies.

... and of course, Apress' book "Spring Recipes, 2nd Edition," might be a helpful book for general purpose Spring knowledge...

Camel, Mule, ServiceMix all support Spring, but none can hope to provide the same experience as Spring Integration, as it's developed by the same people who built Spring itself.

Of all the projects mentioned, the only one I would consider even remotely simialar to Spring Integration is Camel - the others are essentially top heavy servers. Spring Integration and Camel are APIs that make servers irrelevant. Spring Integration, specifically, is a framework that provides leading integration with Spring. The development moves fast, but the Spring Integration project tends to hold itself to a higher bar for quality of implementations. If it's not clean, and built in keeping with Spring standards, it doesn't get shipped. Spring Integration provides a POJO centric model for business logic, letting you provide a clean, natural mapping for your integration flows in the XML definition. It features an almost 1:1 mapping to the Patterns of Enterprise Application Integration book, where key concepts in the book enjoy a simialar priority in the API. For example, a channel is a top level API concept that you'll deal with in almost everything, just as the book encourages. Camel, on the other hand, does not have as natural an API. And, frankly, it has some very clumsy API elements that - I think - speaks to its sort of urban sprawl approach to API design. Spring Integration, for example, has no <try><catch> blocks in its XML!

As to the advantages, it depends on what you're comparing it to, I suppose.

Generally, we like to talk about:
- the powerful and rich supply of adapters (everything from JMS and AMQP to workflow support for Activiti, Redis-based pub/sub, and SMS gateway support through SMPP!)
- the lightweight nature of the framework. No startup scripts, no heavy brokers, etc
- the very good integration between Spring and Spring Integration, and between Spring Integration and other Spring sister projects. If you know Spring, then your skills are put to good use in Spring Integration, as it's written by many of the sample people that helped make Spring itself a worldwide success.
- If you're coming from something like Tibco, Axway Integrator, Oracle, etc., then you'll appreciate getting all the power (more even, since now you can see what's going on when something goes wrong!) of those products at open-source prices, too! ;-)