SpringBoot多模块项目在IDEA下运行调试

一个SpringBoot多模块项目的工程目录如下:

myProject
--api
--ops
--share

现在要在IDEA中调试运行ops模块,程序启动后,所有页面无法访问,提示:

WARN  |-o.e.j.server.handler.ErrorHandler:106  - Error page loop /WEB-INF/jsp/common/404.jsp

这里提示错误页面循环,是因为程序找不到要渲染的jsp页面时,设置了跳转到404页面,结果404页面也找不到了,就出现了错误循环。Jetty查找JSP的文件路径为:

//WebAppContext.getResource(String path):
_baseResource + jsp.prefix + jsp.fileName + jsp.suffix
其中_baseResource 的路径查找步骤为:
//DocumentRoot.getValidDirectory()
getWarFileDocumentRoot();
getExplodedWarFileDocumentRoot();
getCommonDocumentRoot();//判断当前运行目录下是否存在src/main/webapp | public | static 这3个目录中的一个,如果存在,则将当前目录设置为_baseResource
如果根据上面的规则都找不到合适的DocumentRoot,则会使用创建一个运行时的临时目录,项目的JSP文件在临时目录里面肯定是找不到的,所以就不能正常显示了。

解决方案:
在IDEA的Run/Debug Configurations中,将Working directory设置为要运行的模块目录绝对路径,例如/opt/myProject/ops。

找不到JSP的问题算是解决了,如果项目中有用到freemarker和taglib,还会面临一个问题,

Caused by: freemarker.template.TemplateModelException: Error while loading tag library for URI “/my-taglib” from TLD location “servletContext:/my-taglib”; see cause exception.

freemarker查找taglib时,默认使用TaglibFactory.DEFAULT_META_INF_TLD_SOURCES  = Collections.singletonList(WebInfPerLibJarMetaInfTldSource.INSTANCE)
查找tld文件的路径为:sevletContext:/WEB-INF/lib/*.{jar,zip}/META-INF/**/*.tld
在IDEA下直接run SpringBoot,相关的依赖包并不会拷贝到/WEB-INF/lib/下面去,所以就查找不到这些jar包里面的tld文件了,需要让freemarker去classpath中的所有jar包里面去查找,解决方案:

public class IdeFreeMarkerConfigurer extends FreeMarkerConfigurer {

    @Override
    public void afterPropertiesSet() throws IOException, TemplateException {
        super.afterPropertiesSet();          

        super.getTaglibFactory().setMetaInfTldSources(Lists.newArrayList(
                TaglibFactory.WebInfPerLibJarMetaInfTldSource.INSTANCE,
                new TaglibFactory.ClasspathMetaInfTldSource(Pattern.compile(".*\\.jar$", Pattern.DOTALL))));
    }
}

在XML或者Java代码中,配置使用这个FreeMarkerConfigurer 就可以了

 

 

Spring websocket

Spring自从4.0开始提供了对websocket的支持,配合sockjs,可以部分兼容到IE6,websocket终于可以大行其道了。

实际使用中遇到不少问题,逐步列举出来,避免以后忘掉。

  1. 由于浏览器设置了http代理,结果创建websocket时失败,提示:Error in connection establishment: net::ERR_TUNNEL_CONNECTION_FAILED。取消浏览器代理后恢复正常。
  2. 在web.xml中,DispatcherServlet和spring-mvc需要用到的全部filter,都需要加上<async-supported>true</async-supported>,以便在sockjs兼容不支持websocket的浏览器时使用。
  3. 工程使用spring-mvc传统的方式配置,即使用ContextLoaderListener来加载root的Spring-contextConfigLocation(除Controller外的其他Component),使用DispatcherServlet来加载Controller。而处理websocket的业务逻辑写在Controller中,加上了@MessageMapping的注解,结果请求根本到不了Controller里面去。后来发现AbstractMethodMessageHandler负责扫描@MessageMapping,但是在该类的子类实例化时,把Spring的Root Context扔进去了,这里面是没有Controller的类的,所以后面websocket的请求就到不了Controller。将websocket的相关配置文件放到DispatcherServlet里去加载,于是问题解决。

相关配置示例:

web.xml:

<context-param>  
        <param-name>contextConfigLocation</param-name>  
        <param-value>classpath*:/applicationContext*.xml</param-value>  
    </context-param>  
  
<listener>  
        <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>  
    </listener>  
  
<servlet>  
        <servlet-name>SpringMVC</servlet-name>  
        <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>  
        <init-param>  
            <param-name>contextConfigLocation</param-name>  
            <param-value>  
                classpath*:/spring-*.xml  
            </param-value>  
        </init-param>  
        <load-on-startup>1</load-on-startup>  
        <async-supported>true</async-supported>  
</servlet>

applicationContext.xml:

<context:component-scan base-package="xxx.xxx">  
        <context:exclude-filter type="annotation" expression="org.springframework.stereotype.Controller"/>  
</context:component-scan>

spring-mvc.xml:

<context:component-scan base-package="x.x.x" use-default-filters="false">  
        <context:include-filter type="annotation" expression="org.springframework.stereotype.Controller"/>  
</context:component-scan>

spring-websocket.xml:

<websocket:message-broker application-destination-prefix="/app">  
        <websocket:stomp-endpoint path="/chat">  
            <websocket:sockjs/>  
        </websocket:stomp-endpoint>  
        <websocket:simple-broker prefix="/public,/private"/>  
</websocket:message-broker>

Spring命名空间之AOP

Spring加载时,会使用ClassLoader去查找所有能找到的”META-INF/spring.handlers”文件,并存放在handlerMappings中(DefaultNamespaceHandlerResolver在干这事),遇到除beans外的Namespace,就会去这里查找对应的解析器,如果不存在就报错,存在就使用相应的解析器进行解析。

<aop>是由AopNamespaceHandler来进行解析的。

AspectJAutoProxyBeanDefinitionParser会注册3个类来处理解析任务,分别对应为:

“config”, new ConfigBeanDefinitionParser();

“aspectj-autoproxy”, new AspectJAutoProxyBeanDefinitionParser();

“scoped-proxy”, new ScopedProxyBeanDefinitionDecorator();

要使用aop命名空间,需要在spring的xml中加入:

xmlns:aop="http://www.springframework.org/schema/aop"  
  
xsi:schemaLocation="http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-xsd"

这样便可以在该xml中使用<aop …/>了。

<aop:aspectj-autoproxy/>

使用该配置后,AspectJAutoProxyBeanDefinitionParser会注册AnnotationAwareAspectJAutoProxyCreator到Spring管理的bean中。由于AnnotationAwareAspectJAutoProxyCreator是BeanPostProcessor,所以在所有bean初始化完成后,都会调用该类中的postProcessAfterInitialization来进行处理。

AnnotationAwareAspectJAutoProxyCreator使用findEligibleAdvisors来查找是否有bean对应的Advisors(注册在当前beanFactory中的实现了Advisor接口的类,例如BeanFactoryTransactionAttributeSourceAdvisor),如果有,创建一个该bean的代理(AbstractAutoProxyCreator)。

如果使用了<tx:annotation-driven/>,其中的mode属性默认为proxy,解析到这里的时候,AnnotationDrivenBeanDefinitionParser会自动调用AopNamespaceUtils->AopConfigUtils,而AopConfigUtils会把AnnotationAwareAspectJAutoProxyCreator注册到beanFactory里面去,也就是相当于写了个<aop:aspectj-autoproxy/>的标签。

如果不知道程序应该使用Spring-AOP还是AspectJ,这儿有较好的描述:

http://static.springsource.org/spring/docs/3.1.x/spring-framework-reference/html/aop.html#aop-choosing

Spring-AOP默认使用JDKProxy来代理实现了任何接口的类,如果没有实现任何接口,则使用Cglib2AopProxy来创建代理,对原类的方法调用时,会根据代理类设置的Callback[]进行相应处理。

Spring-AOP默认设置的Callback有

DynamicAdvisedInterceptor(拦截方法调用,检查需要使用的拦截器并执行,例如TransactionInterceptor)

DynamicUnadvisedInterceptor/StaticUnadvisedInterceptor

StaticDispatcher

AdvisedDispatcher(不知道拿来干嘛的)

EqualsInterceptor

HashCodeInterceptor

SerializableNoOp(貌似没啥用?)

Spring注入全局的HttpServletRequest

Spring的Controller默认是单例的,也就是说,如果Controller中有个field使用@Autowired自动注入,那么注入后这个field的值在该Controller中是全局的,不会再改变的(手动修改除外)。
在Controller中,很多方法都会用到HttpServletRequest,一般会在方法的参数中写上HttpServletRequest,Spring会自动将这个参数传进来。如果大量的方法都需要这个参数,可以将这个参数定义在Controller的一个field中。

@Controller
@RequestMapping("/")
public class HomeAction {

    @RequestMapping(value = {"", "/"})
    public String index(HttpServletRequest request, HttpServletResponse       response) {
//do something
    }

    @RequestMapping(value = {"list"})
    public String list(HttpServletRequest request, HttpServletResponse response) {
//do something
    }
}

可以使用这种方式来改写,这样所有的方法中都可以直接使用HttpServletRequest:

@Controller
@RequestMapping("/")
public class HomeAction {
    @Autowired
    private HttpServletRequest request;

    @RequestMapping(value = {"", "/"})
    public String index(HttpServletResponse  response) {
//do something
    }

    @RequestMapping(value = "list")
    public String list(HttpServletResponse response) {
//do something
    }
}

这里第一感觉会有点奇怪,因为在HomeAction实例化的时候,HttpServletRequest就已经设置进去了,而且在该Controller实例的整个生命周期内,HttpServletRequest的值都不会变化,那么在多线程的时候,怎么能保证每次使用的HttpServletRequest都能正确对应到当前的http请求呢?
Spring注入的这个HttpServletRequest,其实只是一个代理类,每次调用该request的方法时,会先使用RequestContextHolder.currentRequestAttributes().getRequest() 来获取到当前的实际http请求,然后再执行该实际request的对应方法。

这是一个非常好的使用代理模式的例子,代理类可以全局唯一,但是具体实现类可以有很多不同的实例。

除了在Controller中可以注入HttpServletRequest,在拦截器中也可以进行注入,这样拦截器中可以使用的信息就非常多了。

public class SomeInterceptor implements MethodInterceptor {

    @Autowired
    private HttpServletRequest request;

    @Override
    public Object invoke(MethodInvocation invocation) throws Throwable {
      //do something
    }
}

除了HttpServletRequest外,还有很多其他内容可以通过Spring自动注入,例如:

  • ServletRequest
  • ServletResponse
  • HttpSession
  • Principal
  • Locale
  • InputStream
  • Reader
  • OutputStream
  • Writer

以上Spring能自动注入的列表摘自AnnotationMethodHandlerAdapter.resolveStandardArgument

CORS support in Spring Framework

For security reasons, browsers prohibit AJAX calls to resources residing outside the current origin. For example, as you’re checking your bank account in one tab, you could have the evil.com website in another tab. The scripts from evil.com shouldn’t be able to make AJAX requests to your bank API (withdrawing money from your account!) using your credentials.

Cross-origin resource sharing (CORS) is a W3C specification implemented by most browsersthat allows you to specify in a flexible way what kind of cross domain requests are authorized, instead of using some less secured and less powerful hacks like IFrame or JSONP.

The recently released Spring Framework 4.2 RC1 provides first class support for CORS out-of-the-box, giving you an easier and more powerful way to configure it than typical filter basedsolutions.

Spring MVC provides high-level configuration facilities, described bellow.

Controller method CORS configuration

You can add to your @RequestMapping annotated handler method a @CrossOrigin annotation in order to enable CORS on it (by default @CrossOrigin allows all origins and the HTTP methods specified in the @RequestMapping annotation):

@RestController
@RequestMapping("/account")
public class AccountController {

	@CrossOrigin
	@RequestMapping("/{id}")
	public Account retrieve(@PathVariable Long id) {
		// ...
	}

	@RequestMapping(method = RequestMethod.DELETE, value = "/{id}")
	public void remove(@PathVariable Long id) {
		// ...
	}
}

It is also possible to enable CORS for the whole controller:

@CrossOrigin(origin = "http://domain2.com", maxAge = 3600)
@RestController
@RequestMapping("/account")
public class AccountController {

	@RequestMapping("/{id}")
	public Account retrieve(@PathVariable Long id) {
		// ...
	}

	@RequestMapping(method = RequestMethod.DELETE, value = "/{id}")
	public void remove(@PathVariable Long id) {
		// ...
	}
}

In this example CORS support is enabled for both retrieve() and remove() handler methods, and you can also see how you can customize the CORS configuration using@CrossOrigin attributes.

You can even use both controller and method level CORS configurations, Spring will then combine both annotation attributes to create a merged CORS configuration.

@CrossOrigin(maxAge = 3600)
@RestController
@RequestMapping("/account")
public class AccountController {

	@CrossOrigin(origin = "http://domain2.com")
	@RequestMapping("/{id}")
	public Account retrieve(@PathVariable Long id) {
		// ...
	}

	@RequestMapping(method = RequestMethod.DELETE, value = "/{id}")
	public void remove(@PathVariable Long id) {
		// ...
	}
}

Global CORS configuration

In addition to fine-grained, annotation-based configuration you’ll probably want to define some global CORS configuration as well. This is similar to using filters but can be declared withing Spring MVC and combined with fine-grained @CrossOrigin configuration. By default all origins and GET, HEAD and POST methods are allowed.

The global configuration API has changed after Spring Framework 4.2 RC1, so be sure to use current 4.2.0.BUILD-SNAPSHOT builds or the upcoming 4.2.0.RC2 release.

JavaConfig

Enabling CORS for the whole application is as simple as:

@Configuration
@EnableWebMvc
public class WebConfig extends WebMvcConfigurerAdapter {

	@Override
	public void addCorsMappings(CorsRegistry registry) {
		registry.addMapping("/**");
	}
}

You can easily change any properties, as well as only apply this CORS configuration to a specific path pattern:

@Configuration
@EnableWebMvc
public class WebConfig extends WebMvcConfigurerAdapter {

	@Override
	public void addCorsMappings(CorsRegistry registry) {
		registry.addMapping("/api/**")
			.allowedOrigins("http://domain2.com")
			.allowedMethods("PUT", "DELETE")
			.allowedHeaders("header1", "header2", "header3")
			.exposedHeaders("header1", "header2")
			.allowCredentials(false).maxAge(3600);
	}
}

XML namespace

As of Spring Framework 4.2 RC2, it will also be possible to configure CORS with the mvc XML namespace.

This minimal XML configuration enable CORS on /** path pattern with the same default properties than the JavaConfig one:

<mvc:cors>
	<mvc:mapping path="/**" />
</mvc:cors>

It is also possible to declare several CORS mappings with customized properties:

<mvc:cors>

	<mvc:mapping path="/api/**"
		allowed-origins="http://domain1.com, http://domain2.com"
		allowed-methods="GET, PUT"
		allowed-headers="header1, header2, header3"
		exposed-headers="header1, header2" allow-credentials="false"
		max-age="123" />

	<mvc:mapping path="/resources/**"
		allowed-origins="http://domain1.com" />

</mvc:cors>

How does it work?

CORS requests (including preflight ones with an OPTIONS method) are automatically dispatched to the various HandlerMappings registered. They handle CORS preflight requests and intercept CORS simple and actual requests thanks to a CorsProcessor implementation (DefaultCorsProcessor by default) in order to add the relevant CORS response headers (likeAccess-Control-Allow-Origin). CorsConfiguration allows you to specify how the CORS requests should be processed: allowed origins, headers, methods, etc. It can be provided in various ways:

Spring Boot integration

CORS support will be available in the upcoming Spring Boot 1.3 release, and is already available in the 1.3.0.BUILD-SNAPSHOT builds.

If fine grained CORS configuration is already a perfect fit for Spring Boot applications, a more “Bootiful” way to configure global CORS configuration (based on CorsConfiguration bean declaration and dedicated Spring Boot properties) is likely to be provided with Spring Boot 1.3. See this issue for more details.