Develop Reference

#Autowired vs XML

I'm new to Spring and DI in general. But from what I have read, DI affords you the ability to swap out implementations very easily using frameworks like Spring. I can understand value there when it comes to XML bean configuration because code doesn't need to be changed at all for accomplishing switchable implementations. But if we're using annotations like #Autowired or #Qualifier...we would need to change the code. So why do we want to use annotations over XML-based configuration?

This was actually a topic of lively conversation around the time that Spring 3.0 came out in 2009 and JavaConfig was added to the core system base.
In theory, being able to externalize application setup is a great thing. However, it turns out that in practice there are two distinct groups of setup choices: the application shape or dependency graph, and particular values like API keys, database connection strings, and so on that vary between environment but usually don't change the way that the beans are wired.
Experience has shown that the dependency graph, which is essentially what you'd express in XML, is almost never changed without also making changes to the accompanying implementation code anyway, so there is very little real-world benefit to defining the graph in XML. On the other hand, writing #Bean methods in Java means that it's a lot easier to test configuration when needed, the compiler can ensure type safety, and decision logic (such as conditionals) are simpler to implement.
Furthermore, the availability of annotations means that it's possible to extend the domain-specific language for configuration fairly easily in Java--just create a new annotation and its accompanying processor (such as #ConditionalOnProperty); Spring Boot itself is an extreme example of the flexibility of this model. In XML, on the other hand, injecting new tags or attributes into a schema is a lot more of a hassle.
There are times when XML may still be the better choice (I've particularly gone with it for writing out Spring Integration pipelines, which can be easier to read in XML than in the Java DSL), but the real-world benefits turned out not to be all that valuable in most cases, and the safety and flexibility of configuration as code has won out.

This is not must, you have to choices to use Annotations or XML its up to you but Annotations is easy to use, faster and more readable than configurations, and when you use it you will find all the information in a single file, but it also have disadvantages.
Annotations preferable
Use Annotations in anything that is stable and defines the core
structure of the application. Anything that would need a code change
is okay to sit as an annotation.
I recommended you to read the following links for more info :
xml-configuration-versus-annotation-based-configuration
spring-framework-xml-vs-annotations

Adding spring to servlet just for validation

I am currently not using any frameworks (other than bootstrap) for my java-ee application. But i came across a problem in using server side validation for servlets. I am finding it difficult to implement validation like this
http://spring.io/guides/gs/validating-form-input/
I could use request dispatcher, but I am not sure if it's the right way.
So i wanted to ask is it advisable to use the spring framework just for the validation?
is there any way to convert my entire java application to use spring or should i build the application from the ground up again?

If you just need the validation, then I recommend to use JSR-303/349 Bean Validation 1.0/1.1. The default implementation is done by Hiberante-Validator (this is NOT the Hibernate-ORM project!). It is relative easy to use out of the box.
http://hibernate.org/validator/documentation/getting-started/

An equivalent to Spring Framework's Resource abstraction

Spring Framework provides a wonderful abstraction layer for low-level resource access in Java (the Resource and ResourceLoader interfaces). I'm developing a library which should not be dependent on Spring, and am looking for an equivalent for this capability in a stand-alone Java library. Anyone familiar with one?

Why not just use the one from Spring by itself? It doesn't look like it has any dependencies on the rest of Spring.
Edit
Not sure I understand the problem - you want something that does exactly the same thing, but doesn't come from Spring? Is it a licensing issue?
You only need half a dozen classes from it, if you don't want to add them as an extra jar, move them to your own namespace (good idea anyway, in case you do use Spring at some point, after all) and distribute with your library. Again, assuming your licensing allows it.
If licensing isn't the problem, can you be more specific about why you can't use the Spring implementation in your own library?

You can use Jsr-303 (DI) to match your requirments. The most known implementation is Google Guice. It's a javaEE standard (maybe JavaSE).

Spring Framework - Integration with old Java webapp

I'm working on a 10-year-old Java webapp, and I would like to introduce some new technology into the project. One of the things I would like to start doing is dependency injection. I know the Spring Framework has the capability to do dependency injection, but I am having a hard time integrating the framework into the old project.
Could someone provide an example of what I would have to change in my web.xml, other files I would have to add, and other changes I would need to make? I want the smallest Spring footprint while still being bale to do dependency injection.
There are a lot of examples online about starting a new project using Spring, but I can't find any about integrating Spring into an old project.
Thanks.

You'll have to start by adding a context loader listener into your web.xml, along with the locations of the Spring configuration XML files.
You should configure the Spring DispatcherServlet to accept all URLs that you wish for it to handle.
You should write Controllers to bind and validate HTTP requests, call services, add data to ModelAndView for rendering, and map JSPs to success/failure views as needed.
You should put interfaces in front of your service and persistence tiers. Move implementations into implementation classes that Spring can inject.
Leverage Spring AOP for security and transactions and logging as needed.

Throwing new technology at a project wont make it faster\better, unless you introduce the new technology to all parts of the project. The idea behind DI is to lose dependencies between objects. The project probably is tightly coupled, so you'd have to rewrite at least parts of the thing. Depending on the size, this can be a monster to beat - ask yourself if this is worth it, if it has any positive effect on the project other than introducing new technology.
The reason why there are little to none tutorials about integrating DI container into an old project is quite simple: it usually doesn't make any sense. Either you use the pattern in all places, or none at all. The bastard child that would be creating by mixing both would be a horror to maintain. I'd really advise you think about why you want to introduce a DI container into that 10 year project. Unless there is a real good reason for doing it (and you are happy with rewriting a lot of code) don't do it.

How does Spring fit into my application architecture?

I'm currently rebuilding an existing PHP application using Java. I therefore have an existing frontend GUI and an existing database schema that I'm working with.
Here is the technology stack I'm working towards:
jQuery, client-side
Wicket, front-end
Spring, ???
Hibernate, ORM
MySQL, database
Before reading about Spring in both Wicket In Action and the Hibernate documentation, I envisioned wiring the two together through my own business logic. I have experience with JBoss Seam, but am told that Spring is hardly comparable (although the documentation suggests otherwise, IMO). Short of adding a book about Spring to my reading list (I haven't found an appropriate one with good reviews yet), I'm at a loss.
What benefit(s) will Spring provide in this technology stack?
Subjective & optional follow up question: what reference material (book, website, etc) will get me started with the portion of Spring 3 I may utilize?

First, you can make your web application without Spring. But Spring will greatly facilitate things. Spring framework is a lightweight, non-invasive. Spring is like a kind of conductor. Among other things Spring helps you in:
To keep your objects loosely coupled. This will make your application more flexible and open to future changes
Powerful support for transactions through the AOP (Aspect Oriented Programming).
Object-relational mapping (ORM) integration module. Spring doesn’t attempt to implement its own ORM solution, but does provide hooks into several popular ORM frameworks, including Hibernate, Java Persistence API, Java Data Objects, and iBATIS SQL Maps. Spring’s Transaction management supports each of these ORM frameworks as well as JDBC.
The Spring MVC framework. Even though Spring integrates with several popular MVC frameworks, it also comes with its own very capable MVC framework that promotes Spring’s loosely coupled techniques in the web layer of an application.
A good book about Spring: Pro Spring

Spring, as noted in this review is non-invasive. It just wires your application components. And provides useful classes that make using other frameworks easier (JMS, JPA, etc). Spring doesn't force you to use its classes or interfaces anywhere.
What it handles is the creation of your components (objects), so that you can refer to a class' dependencies, without instantiating them. I.e. you say what your class needs, not how it is obtaining it. This makes the application very flexible.
That's in short - for more, read the linked article. It's not about the latest version, but that doesn't matter.

In addition to dependency injection, Spring offers features like declarative transaction management, simple integration with ORM, aspect-oriented programming support and many other nice things.
For documentation see Spring reference: http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html

#Dolph, in the simplest term, think of Spring as your application framework at the highest degree. This "framework" provides several "component buckets" where you can easily plug in different types of implementations. For example, for ORM, you may choose to use Hibernate over JPA or TopLink, for front end, you may choose Wicket over Struts or SpringMVC, and so forth.
The whole beauty of this (besides all the goodies stated in other posts) is it allows you easily swap out any of these implementations easily in the future. So, you can essentially rip out Hibernate one day and replace with TopLink, and it will never cause ripple effect to other components.
Another beauty of using Spring is your code becomes less clutter and has loose dependencies with other classes because you spend less time creating new objects yourself, Spring handles that for you. That said, you will quickly realize how easy for you to test your code because your API to be tested becomes very atomic. This is one primary reason why folks get discouraged in writing testcases, because they quickly realize that in order for them to test one API, they have to construct whole lot of things just to test that. Because of that, the whole process is brittle, imagine if you change that API, you need to reconstruct everything before testing it again.
Pro Spring book is good, mentioned by #JLBarros. I like Spring in Action very much. It is very very easy to read when I first got started with Spring. This is probably one reference book that I read from skin to skin.