Spring MVC坑汇总+Stackoverflow巧解答

1.http://stackoverflow.com/questions/25598406/spring-annotaion-autowired-inside-methods

Q:

Autowire can be used with constructors, setter and as class variables.

How can I used @Autowire annotation inside a method or any other scope.

A:

Even if it could, there's nothing Spring or any runtime environment could do about it because reflection doesn't provide any hooks into method bodies. You wouldn't be able to access that local variable at runtime.

You'll have to move that local variable to a field and autowire that.

2.http://stackoverflow.com/questions/10997092/autowiring-in-spring-bean-component-created-with-new-keyword

Q:

I have two spring beans as follows:

@Component("A")
@Scope("prototype")
public class A extends TimerTask {

    @Autowired
    private CampaignDao campaignDao;
    @Autowired
    private CampaignManager campManger;
    A(){
        init_A();
       }
    }

I have to make a new object of A with new keyword, due to a legacy code

@Component("B")
@Scope("prototype")
public class B{
     public void test(){
       A a = new A();
     }
}

when Running -> the spring beans in the class A are null, can i create a new instance of the spring bean A and still use autowiring in it ?

A:

Yours component "A" is not created by Spring container, thus, dependencies are not injected. However, if you need to support some legacy code (as I understand from your question), you can use@Configurable annotation and build/compile time weaving:

@Configurable(autowire = Autowire.BY_TYPE)
public class A extends TimerTask {
  // (...)
}

Then, Spring will inject autowired dependencies to component A, no matter if it's instantiated by container itself, or if it's instantiated in some legacy code by new.

3.http://stackoverflow.com/questions/7201728/how-are-spring-handlerinterceptors-instantiated

Q:

Is there a new instance of Spring HandlerInterceptors for each request?

I have an interceptor in Spring, which has a class field.

public class MyInterceptor extends HandlerInterceptorAdapter {
    Private boolean state = false;

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
        state = true;
        return true;
    }

    @Override
    public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) {
        if (state == true) {
        System.out.println("Success");
        }
}

If this interceptor is used will it always print "Success"? (No matter how many threads are doing this at the same time?)

A:

How the interceptor is instantiated depends how you configiure it as a bean. If you don't explicitly specify a scope for the bean, then it'll be a singleton like any other bean, and so the state field will be shared by all requests.

In this sense, interceptors are no different to controllers - be very careful about putting conversation state in them, since the objects will be shared across requests.

if you really need a stateful interceptor and you don't want to share the state between requests, then use a request-scoped bean.

4.http://stackoverflow.com/questions/26131603/autowire-of-prototype-bean-into-prototype-bean

Q:

@Scope("prototype")
public class MyPrototypeClass  {

    @Autowired
    private ReallyGoodSingletonService svc;

    @Autowired
    private APrototypeBean bean;

    public void doSomething() {
        bean.doAThing();
    }
}

@Scope("prototype)
public class APrototypeBean {
   private int stuffgoeshere;

   public void doAThing() {
   }
}

So when doSomething() in MyPrototypeClass is called, is that "bean" a singleton or a new one for each instance of MyPrototypeClass?

A:

In your example, the APrototypeBean bean will be set to a brand new bean which will live through until the instance of MyPrototypeClass that you created is destroyed.

If you create a second instance of MyPrototypeClass then that second instance will receive its own APrototypeBean. With your current configuration, every time you call doSomething(), the method will be invoked on an instance of APrototypeBean that is unique for that MyPrototypeClass object.

5.http://stackoverflow.com/questions/21827548/spring-get-current-applicationcontext

Q:

I am using Spring MVC for my web application. My beans are written in "spring-servlet.xml" file

Now I have a class MyClass and i want to access this class using spring bean

In the spring-servlet.xml i have written following

<bean id="myClass" class="com.lynas.MyClass" />

Now i need to access this using ApplicationContext

ApplicationContext context = ??

So that I can do

MyClass myClass = (MyClass) context.getBean("myClass");

How to do this??

A:

Simply inject it..

@Autowired
private ApplicationContext appContext;

or implement this interface: ApplicationContextAware

6.

Q:

public class UserBoImpl implements UserBo{

@Autowired
UserDao userDao;

public void syso() {
userDao.save();
}

}
这应该是最普遍的Spring注入模版  
userDao是何时被实例化的？？？ 
是调用save方法时  还是 Spring IOC容器建立时 ？？？？
Spring又是如何处理Autowire这个注释的？？何时处理的？？？

A:

默认情况下,bean的装配顺序是
new实例化 -> PostConstruction -> Autowire
至于你这个dao何时实例化,要看你是怎么声明的scope
默认是单例,也就是spring被加载时实例化
如果是scope("prototype")那就是这个dao被引用的时候进行实例化.

[注]如果UserBoImpl也是prototype类型，那么userDao会在程序生成UserBoImpl（例如调用getbean）的时候完成初始化，如果UserBoImpl是singleton类型，那么userDao也会因为UserBoImpl在spring启动的时候初始化而一道被注入。严格意义上来说，外层对象Out声明为singleton，内层成员变量Inner声明为prototype，外层对象中所有的成员函数out.func()和成员变量out.mem都将共享这个Inner。Inner变量只会在Out对象初始化时一起被初始化，有且仅有这一次。

7.http://stackoverflow.com/questions/13951733/contextannotation-config-and-contextcomponent-scan

Q:

In Spring 3 do I need to have <context:annotation-config> and <context:component-scan> defined in order to enable @PostConstruct?

A:

<context:annotation-config> is enough, after that you can instantiate your beans from context.xml and @PostConstruct, @Autowired, @Resource and some other annotations that Spring supports will be processed. Note if you use component-scan annotation-config mode is enabled by default.

8. http://stackoverflow.com/questions/7414794/difference-between-contextannotation-config-vs-contextcomponent-scan

Q:

I'm learning Spring 3 and I don't seem to grasp the functionality behind <context:annotation-config>and <context:component-scan>.

From what I've read they seem to handle different annotations (@Required, @Autowired etc vs @Component, @Repository, @Service etc) but also from what I've read they register the same bean post processor classes.

To confuse me even more, there is an annotation-config attribute on <context:component-scan>.

Can someone shed some light on these tags? What's similar, what's different, is one superseded by the other, they complete each other, do I need one of them, both?

A:

<context:annotation-config> 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).

<context:component-scan> can also do what <context:annotation-config> does but <context:component-scan> also scans packages to find and register beans within the application context.

9. http://stackoverflow.com/questions/18578143/about-multiple-containers-in-spring-framework/18580299#18580299

Q:

In a typical Spring MVC project there two "containers": One created by ContextLoaderListener and the other created by DispatchServlet.

I want to know, are these really two IoC container instance?( I see two bean config files, one is root-context.xml the other is servlet-context.xml)

If there are 2 containers, then what's the relationship?

Can the beans declared in one container be used in the other?

A:

After years later, I have read the spring source code. Now, I can say: 1) yes, there are two instance of ApplicationContext ( each instance will include a instance of beanFactory) 2) the instance of the mvc layer is child and keep a reference of the parent instance. 3) beans in parent instance can be used by child, but beans in child cannot be used by parent.

In Spring Web Applications, there are two types of container, each of which is configured and initialized differently. One is the “Application Context” and the other is the “Web Application Context”. Lets first talk about the “Application Context”. Application Context is the container initialized by a ContextLoaderListener or ContextLoaderServlet defined in the web.xml and the configuration would look something like this:

<listener>
     <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

<context-param>
     <param-name>contextConfigLocation</param-name>
     <param-value>classpath:*-context.xml</param-value>
</context-param>

In the above configuration, I am asking spring to load all files from the classpath that match *-context.xml and create an Application Context from it. This context might, for instance, contain components such as middle-tier transactional services, data access objects, or other objects that you might want to use (and re-use) across the application. There will be one application context per application.

The other context is the “WebApplicationContext” which is the child context of the application context. Each DispatcherServlet defined in a Spring web application will have an associated WebApplicationContext. The initialization of the WebApplicationContext happens like this:

<servlet>
      <servlet-name>platform-services</servlet-name>
      <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
      <init-param>
            <param-name>contextConfigLocation</param-name>
            <param-value>classpath:platform-services-servlet.xml</param-value>
      </init-param>
      <load-on-startup>1</load-on-startup>
</servlet>

You provide the name of the spring configuration file as a servlet initialization parameter. What is important to remember here is that the name of the XML must be of the form -servlet. xml. In this example, the name of the servlet is platform-services therefore the name of our XML must be platform-service-servlet.xml. Whatever beans are available in the ApplicationContext can be referred to from each WebApplicationContext. It is a best practice to keep a clear separation between middle-tier services such as business logic components and data access classes (that are typically defined in the ApplicationContext) and web- related components such as controllers and view resolvers (that are defined in the WebApplicationContext per Dispatcher Servlet).