What is a Spring “stereotype”?

The JavaDoc says a bit about it.
Annotations denoting the roles of types or methods in the overall architecture (at a conceptual, rather than implementation, level).
The noun definition of sterotype from Merriam-Webster says this:
something conforming to a fixed or general pattern; especially : a standardized mental picture that is held in common by members of a group and that represents an oversimplified opinion, prejudiced attitude, or uncritical judgment
It seems that it is for suggesting a role of particular class that is being annotated. This seems to make sense because it is often recommended that you annotate your Controller classes with @Controller, Service classes with @Service, and so on.
In general, Spring suggests that they make nice point-cut demarcations for your AOP needs. (besides the obvious component-scanning functionality)

Spring annotations @Repository and @Service

The @Repository annotation (introduced in Spring 2.0) and @Service annotation (introduced in Spring 2.5) are specialization of the @Component annotation.
The main advantage of using @Repository or @Service over @Component is that it’s easy to write an AOP pointcut that targets, for instance, all classes annotated with @Repository.
Also, the specialized annotations help to clearly demarcate application layers (in a standard 3 tiers application).

Difference between context:annotation-config vs context:component-scan

 is used to activate annotations in beans already registered in the application context (no matter if they were defined with XML or by package scanning).
 can also do what  does but also scans packages to find and register beans within the application context.
I’ll use some examples to show the differences/similarities.
Lets start with a basic setup of three beans of type AB and C, with B and C being injected into A.
package com.xxx;
public class B {
public B() {
System.out.println("creating bean B: " + this);
}
}

package com.xxx;
public class C {
public C() {
System.out.println("creating bean C: " + this);
}
}

package com.yyy;
import com.xxx.B;
import com.xxx.C;
public class A {
private B bbb;
private C ccc;
public A() {
System.out.println("creating bean A: " + this);
}
public void setBbb(B bbb) {
System.out.println("setting A.bbb with " + bbb);
this.bbb = bbb;
}
public void setCcc(C ccc) {
System.out.println("setting A.ccc with " + ccc);
this.ccc = ccc;
}
}
With the following XML configuration :
<bean id="bBean" class="com.xxx.B" />
<bean id="cBean" class="com.xxx.C" />
<bean id="aBean" class="com.yyy.A">
<property name="bbb" ref="bBean" />
<property name="ccc" ref="cBean" />
</bean>
Loading the context produces the following output:
creating bean B: com.xxx.B@c2ff5
creating bean C
: com.xxx.C@1e8a1f6
creating bean A
: com.yyy.A@1e152c5
setting A
.bbb with com.xxx.B@c2ff5
setting A
.ccc with com.xxx.C@1e8a1f6
OK, this is the expected output. But this is “old style” Spring. Now we have annotations so lets use those to simplify the XML.
First, lets autowire the bbb and ccc properties on bean A like so:
package com.yyy;
import org.springframework.beans.factory.annotation.Autowired;
import com.xxx.B;
import com.xxx.C;
public class A {
private B bbb;
private C ccc;
public A() {
System.out.println("creating bean A: " + this);
}
@Autowired
public void setBbb(B bbb) {
System.out.println("setting A.bbb with " + bbb);
this.bbb = bbb;
}
@Autowired
public void setCcc(C ccc) {
System.out.println("setting A.ccc with " + ccc);
this.ccc = ccc;
}
}
This allows me to remove the following rows from the XML:
<property name="bbb" ref="bBean" />
<property name="ccc" ref="cBean" />
My XML is now simplified to this:
<bean id="bBean" class="com.xxx.B" />
<bean id="cBean" class="com.xxx.C" />
<bean id="aBean" class="com.yyy.A" />
When I load the context I get the following output:
creating bean B: com.xxx.B@5e5a50
creating bean C
: com.xxx.C@54a328
creating bean A
: com.yyy.A@a3d4cf
OK, this is wrong! What happened? Why aren’t my properties autowired?
Well, annotations are a nice feature but by themselves they do nothing whatsoever. They just annotate stuff. You need a processing tool to find the annotations and do something with them.
 to the rescue. This activates the actions for the annotations that it finds on the beans defined in the same application context where itself is defined.
If I change my XML to this:
<context:annotation-config />
<bean id="bBean" class="com.xxx.B" />
<bean id="cBean" class="com.xxx.C" />
<bean id="aBean" class="com.yyy.A" />
when I load the application context I get the proper result:
creating bean B: com.xxx.B@15663a2
creating bean C
: com.xxx.C@cd5f8b
creating bean A
: com.yyy.A@157aa53
setting A
.bbb with com.xxx.B@15663a2
setting A
.ccc with com.xxx.C@cd5f8b
OK, this is nice, but I’ve removed two rows from the XML and added one. That’s not a very big difference. The idea with annotations is that it’s supposed to remove the XML.
So let’s remove the XML definitions and replace them all with annotations:
package com.xxx;
import org.springframework.stereotype.Component;
@Component
public class B {
public B() {
System.out.println("creating bean B: " + this);
}
}

package com.xxx;
import org.springframework.stereotype.Component;
@Component
public class C {
public C() {
System.out.println("creating bean C: " + this);
}
}

package com.yyy;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;
import com.xxx.B;
import com.xxx.C;
@Component
public class A {
private B bbb;
private C ccc;
public A() {
System.out.println("creating bean A: " + this);
}
@Autowired
public void setBbb(B bbb) {
System.out.println("setting A.bbb with " + bbb);
this.bbb = bbb;
}
@Autowired
public void setCcc(C ccc) {
System.out.println("setting A.ccc with " + ccc);
this.ccc = ccc;
}
}
While in the XML we only keep this:
<context:annotation-config />
We load the context and the result is… Nothing. No beans are created, no beans are autowired. Nothing!
That’s because, as I said in the first paragraph, the  only works on beans registered within the application context. Because I removed the XML configuration for the three beans there is no bean created and  has no “targets” to work on.
But that won’t be a problem for  which can scan a package for “targets” to work on. Let’s change the content of the XML config into the following entry:
<context:component-scan base-package="com.xxx" />
When I load the context I get the following output:
creating bean B: com.xxx.B@1be0f0a
creating bean C
: com.xxx.C@80d1ff
Hmmmm… something is missing. Why?
If you look closelly at the classes, class A has package com.yyy but I’ve specified in the to use package com.xxx so this completely missed my A class and only picked up B and C which are on the com.xxx package.
To fix this, I add this other package also:
<context:component-scan base-package="com.xxx,com.yyy" />
and now we get the expected result:
creating bean B: com.xxx.B@cd5f8b
creating bean C
: com.xxx.C@15ac3c9
creating bean A
: com.yyy.A@ec4a87
setting A
.bbb with com.xxx.B@cd5f8b
setting A
.ccc with com.xxx.C@15ac3c9
And that’s it! Now you don’t have XML definitions anymore, you have annotations.
As a final example, keeping the annotated classes AB and C and adding the following to the XML, what will we get after loading the context?
<context:component-scan base-package="com.xxx" />
<bean id="aBean" class="com.yyy.A" />
We still get the correct result:
creating bean B: com.xxx.B@157aa53
creating bean C
: com.xxx.C@ec4a87
creating bean A
: com.yyy.A@1d64c37
setting A
.bbb with com.xxx.B@157aa53
setting A
.ccc with com.xxx.C@ec4a87
Even if the bean for class A isn’t obtained by scanning, the processing tools are still applied by on all beans registered in the application context, even for A which was manually registered in the XML.
But what if we have the following XML, will we get duplicated beans because we’ve specified both and ?
<context:annotation-config />
<context:component-scan base-package="com.xxx" />
<bean id="aBean" class="com.yyy.A" />
No, no duplications, We again get the expected result:
creating bean B: com.xxx.B@157aa53
creating bean C
: com.xxx.C@ec4a87
creating bean A
: com.yyy.A@1d64c37
setting A
.bbb with com.xxx.B@157aa53
setting A
.ccc with com.xxx.C@ec4a87
That’s because both tags register the same processing tools ( can be omitted if  is specified) but Spring takes care of running them only once.
Even if you register the processing tools yourself multiple times, Spring will still make sure they do their magic only once; this XML:
<context:annotation-config />
<context:component-scan base-package="com.xxx" />
<bean id="aBean" class="com.yyy.A" />
<bean id="bla" class="org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor" />
<bean id="bla1" class="org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor" />
<bean id="bla2" class="org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor" />
<bean id="bla3" class="org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor" />
will still generate the following result:
creating bean B: com.xxx.B@157aa53
creating bean C
: com.xxx.C@ec4a87
creating bean A
: com.yyy.A@25d2b2
setting A
.bbb with com.xxx.B@157aa53
setting A
.ccc with com.xxx.C@ec4a87
OK, that about raps it up.
I hope this information along with the responses from @Tomasz Nurkiewicz and @Sean Patrick Floyd are all you need to understand how  and  work.

How to fix error “Updating Maven Project”. Unsupported IClasspathEntry kind=4?

The problem is caused by the fact that the STS (the Spring IDE/Eclipse) uses the m2e(clipse) plugin but that eclipse:eclipse has been probably been run on the project. When m2e encounters a “var” .classpath entry, it throws this error.
In order to fix this problem, you need to do the following:
  1. Make sure that the version of the m2e(clipse) plugin that you’re running is at least 1.1.0, and preferably, the latest available. The update site is the following url: http://eclipse.org/m2e/download/.
  2. Disable the maven nature for the project (via the right-click menu)
  3. run mvn eclipse:clean (while your project is open in STS/eclipse)
  4. re-enable the maven nature.
    (Most of the time, this can be done by right-clicking on the project in question in the package explorer pane, and then choosing ‘Configure’-> ‘Convert to Maven Project’)

http://stackoverflow.com/questions/10564684/how-to-fix-error-updating-maven-project-unsupported-iclasspathentry-kind-4

Why use Spring Framework ?

For a job interview, the info found in the Wikipedia should suffice:
http://en.wikipedia.org/wiki/Spring_framework

Look at the the “Dependency Injection” section.
Follow this logic:

  1. Eorget about Spring for a moment.
  2. Think about an application with many classes, where -as usual- each class depend on many others.
  3. Think about how you would instantiate those classes.
  4. Soon you realize that the way they are coupled together, makes it a nightmare to instantiate them.
  5. Moreover, if you are unit testing, you want to make it flexible enough so that you can change those dependencies with mock objects.
  6. You realize that factories are a good way of abstracting and centralizing those object creations.
  7. You think about centralizing all this, so that you only worry about the functionality of the classes, and let “something else” worry about all that creation boilerplate.
  8. That’s when Spring comes. It’s a centralized container for those objects. Those objects are just POJOs (or beans). Pretty simple.
  9. Spring is much more than a container, but that’s for the dependency injection related stuff.



Cheers.

http://forum.springsource.org/showthread.php?113923-Why-use-Spring-Framework

Spring Framework

Hibernate is an Object Relational Mapping tool, an alternative to Sun’s Entity Beans 2.0. Hibernate has become over the years a “de facto standard” for object persistence in Java and today’s JPA API is highly inspired by Hibernate (which can be used as JPA implementation).
Spring is a dependency injection framework which allows you to wire components and to benefits from additional services like declarative transaction management, declarative security, integration with many other frameworks, abstraction layers etc. Spring has been created to ease Enterprise Java applications development and to make it possible without EJBs and a “heavyweight” container. With Spring and Hibernate and e.g. Tomcat, you get a nice Enterprise stack. Spring is a “lightweight” container.
Spring and Hibernate have heavily influenced the way we build Java application and their adoption are the proof of the need for simplification. Despite, I see JEE 5 as Sun’s answer to these “non standard” solutions to simplify Java Enterprise development.
So yes, Spring Hibernate are widely used together and Spring offers Hibernate (and JPA) integration but Spring and Hibernate are two different projects with separated board and governance. They have mutual interests but IMO the Hibernate Team manages Hibernate, the Spring Team manages Spring.

What does the Spring framework do? Should I use it? Why or why not? [closed]

What does the Spring framework do? Should I use it? Why or why not?
Spring is a framework that helps you to “wire” different components together. It is most useful in cases where you have a lot of components and you might decide to combine them in different ways, or wish to make it easy to swap out one component for another depending on different settings or environments.
This is what I’ve always understood “dependency injection” to be.
I would suggest a different definition:
“Dependency injection is where you design your classes so that they expect an outside actor to directly give them the sub-tools they need to do their jobs before anybody starts asking them to do something.”
Most of the XML (or annotation-based) stuff is telling spring:
  • When someone asks for a “HammerStore”, I want you to create a example.HammerStore and return it result. Cache the result, since there is only one store.
  • When someone asks for a “SomeHammer”, I want you to find a “HammerStore” and return the result of its getHammer() method. Do not cache the result, but make a new hammer each time.
  • When someone asks for a “SomeWrench”, I want you to create a example.WrenchImpl and take the configuration setting guage and put it into the setWrenchSize() property. Do not cache the result, but create a new one each time.
  • When someone asks for a “OurPlumber”, I want to you create an instance of example.PlumberImpl. Put the string “Pedro” into its setName() method, put a “SomeHammer” into its setHammer()method, and put a “SomeHammer” into its setWrench() method. Return the result, but do cache it, since we only have one Pedro.
In this way, Spring lets your connect components, label them, control their lifecycle/caching, and alter behavior based on configuration.
To facilitate [testing] I typically make (at least) two versions of a method : one that uses instance variables, and one that only uses variables that are passed in to the method.
That sounds like a lot of overhead for not a lot of benefit for me. I would suggest that you make your instance variables protected or package-level, and then locate the unit tests inside the same package. That way you can alter or test the instance variables in-place.

What does the Spring framework do? Should I use it? Why or why not? [closed]

What does the Spring framework do? Should I use it? Why or why not?
Spring is a framework that helps you to “wire” different components together. It is most useful in cases where you have a lot of components and you might decide to combine them in different ways, or wish to make it easy to swap out one component for another depending on different settings or environments.
This is what I’ve always understood “dependency injection” to be.
I would suggest a different definition:
“Dependency injection is where you design your classes so that they expect an outside actor to directly give them the sub-tools they need to do their jobs before anybody starts asking them to do something.”
Most of the XML (or annotation-based) stuff is telling spring:
  • When someone asks for a “HammerStore”, I want you to create a example.HammerStore and return it result. Cache the result, since there is only one store.
  • When someone asks for a “SomeHammer”, I want you to find a “HammerStore” and return the result of its getHammer() method. Do not cache the result, but make a new hammer each time.
  • When someone asks for a “SomeWrench”, I want you to create a example.WrenchImpl and take the configuration setting guage and put it into the setWrenchSize() property. Do not cache the result, but create a new one each time.
  • When someone asks for a “OurPlumber”, I want to you create an instance of example.PlumberImpl. Put the string “Pedro” into its setName() method, put a “SomeHammer” into its setHammer()method, and put a “SomeHammer” into its setWrench() method. Return the result, but do cache it, since we only have one Pedro.
In this way, Spring lets your connect components, label them, control their lifecycle/caching, and alter behavior based on configuration.
To facilitate [testing] I typically make (at least) two versions of a method : one that uses instance variables, and one that only uses variables that are passed in to the method.
That sounds like a lot of overhead for not a lot of benefit for me. I would suggest that you make your instance variables protected or package-level, and then locate the unit tests inside the same package. That way you can alter or test the instance variables in-place.

What does the Spring framework do? Should I use it? Why or why not?

What does the Spring framework do? Should I use it? Why or why not?

Spring is a framework that helps you to “wire” different components together. It is most useful in cases where you have a lot of components and you might decide to combine them in different ways, or wish to make it easy to swap out one component for another depending on different settings or environments.

This is what I’ve always understood “dependency injection” to be.

I would suggest a different definition:
“Dependency injection is where you design your classes so that they expect an outside actor to directly give them the sub-tools they need to do their jobs before anybody starts asking them to do something.”
Most of the XML (or annotation-based) stuff is telling spring:

  • When someone asks for a “HammerStore”, I want you to create a example.HammerStore and return it result. Cache the result, since there is only one store.
  • When someone asks for a “SomeHammer”, I want you to find a “HammerStore” and return the result of its getHammer() method. Do not cache the result, but make a new hammer each time.
  • When someone asks for a “SomeWrench”, I want you to create a example.WrenchImpl and take the configuration setting guage and put it into the setWrenchSize() property. Do not cache the result, but create a new one each time.
  • When someone asks for a “OurPlumber”, I want to you create an instance of example.PlumberImpl. Put the string “Pedro” into its setName() method, put a “SomeHammer” into its setHammer() method, and put a “SomeHammer” into its setWrench() method. Return the result, but do cache it, since we only have one Pedro.

In this way, Spring lets your connect components, label them, control their lifecycle/caching, and alter behavior based on configuration.

To facilitate [testing] I typically make (at least) two versions of a method : one that uses instance variables, and one that only uses variables that are passed in to the method.

That sounds like a lot of overhead for not a lot of benefit for me. I would suggest that you make your instance variables protected or package-level, and then locate the unit tests inside the same package. That way you can alter or test the instance variables in-place.

http://programmers.stackexchange.com/questions/92393/what-does-the-spring-framework-do-should-i-use-it-why-or-why-not