"Configuration file Node" Java World Configuration file node

Spring <context:property-placeholder/>

Expectation: There is a solution can be convenient we do not need to write the value of a parameter frequently in a phase, but in different stages can easily switch parameter configuration information to solve: Spring3 provides a convenient way is the context: The property-placeholder/element simply adds a sentence to the spring configuration file:<Context:property-placeholder Location= "Classpath:jdbc.properties"/>Here, the location value is the position of the parameter configuration file, the parameter profile is usually placed in the SRC directory, and the parameter configuration file is the same as the Java common parameter configuration file, that is, the form of key-value pairs, for example: # JDBC Configuration test.jdbc.driverclassname=com.mysql.jdbc.drivertest.jdbc.url=jdbc:mysql://localhost:3306/ Testtest.jdbc.username=roottest.jdbc.password=root in line # The following section is a comment application: 1. This allows you to set values for the properties of a spring-configured bean, such as a class in spring that has a JDBC data source Drivermanagerdatasource The bean in the config file:<BeanID= "Testdatasource"class= "Org.springframework.jdbc.datasource.DriverManagerDataSource">    < Propertyname= "Driverclassname"value= "${test.jdbc.driverclassname}"/>    < Propertyname= "url"value= "${test.jdbc.url}"/>    < Propertyname= "username"value= "${test.jdbc.username}"/>    < Propertyname= "Password"value= "${test.jdbc.password}"/></Bean>http://stamen.iteye.com/blog/1926166

Spring <context:annotation-config/>

In a host-based configuration spring configuration file, you may see<Context:annotation-config/>such a configuration, his role is to register the Spring container autowiredannotationbeanpostprocessor, Commonannotationbeanpostprocessor, Persistenceannotationbeanpostprocessor and Requiredannotationbeanpostprocessor the 4 beanpostprocessor. Registering these 4 beanpostprocessor functions is for your system to be able to identify the corresponding annotations. For example: If you want to use @autowired annotations, you must declare the Autowiredannotationbeanpostprocessor Bean in the Spring container beforehand. The traditional declaration method is as follows<Beanclass= "Org.springframework.beans.factory.annotation." Autowiredannotationbeanpostprocessor "/>If you want to use @ Resource, @ postconstruct, @ Predestroy and other annotations must be declared commonannotationbeanpostprocessor if you want to use @persistencecontext annotations, You must declare the Persistenceannotationbeanpostprocessor bean. If you want to use @Required annotations, you must declare the Requiredannotationbeanpostprocessor bean. Similarly, the traditional way of declaring is as follows:<Beanclass= "Org.springframework.beans.factory.annotation.RequiredAnnotationBeanPostProcessor"/>Generally speaking, these annotations we are more commonly used, especially antowired annotations, in the automatic injection is often used, so if you always need to follow the traditional way a configuration is a bit cumbersome and unnecessary, so spring provides us<Context:annotation-config/>simplified configuration to help you complete the declaration automatically. But, hehe, we usually configure the scan package path option with annotations<Context:component-scanBase-package= "xx.xx"/>This configuration item also includes the ability to automatically inject the above processor, so when using <context:component-scan/>, you can add<Context:annotation-config/>removed.

<context:component-scan base-package= "Com.javaniu"/>

about the use of Spring Auto-detect components There's too much on the web, and it's not the focus of my record, I want to say something you don't know yet. We know that if we don't want to configure the bean in an XML file, we can add a spring component annotation to our class. The automatic loading of beans can be achieved simply by configuring the spring scanner. Write a small example, and the rest is explained below<!--defines the scan root path as leot.test, without using the default scan mode -<Context:component-scanBase-package= "Leot.test"use-default-filters= "false">  <!--scan classes that conform to @service @Repository -  <Context:include-filtertype= "Annotation"expression= "Org.springframework.stereotype.Service" />  <Context:include-filtertype= "Annotation"expression= "Org.springframework.stereotype.Repository" /></Context:component-scan>Here's a quote from the Spring Framework Development Manual, "Spring 2.5 introduces more typical annotations (stereotype annotations): @Component, @Service, and @Controller. @Component is a common form of all spring-managed components, whereas @repository, @Service, and @Controller are @component refinements to represent more specific use cases (for example, the persistence layer, the service layer, and the presentation layer, respectively) )。 That is, you can annotate your component classes with @component, but if you annotate them with @repository, @Service, or @controller, your class might be better handled by tools or associated with facets. For example, these typical annotations can be ideal pointcut targets. Of course, in later versions of the spring Framework, @Repository, @Service, and @Controller might be able to carry more semantics. Thus, if you are considering whether the service layer is to be used @component or @service, that @service is obviously a better choice. Again, as previously stated, @Repository can be used as a marker for exception conversions in the persistence layer. "The following is the most detailed introduction to the current on-line component scanning of the spring Applicationcontext.xml<Context:component-scan>The label uses more than I thought. And then we know that, with the<Context:component-scan>, another<Context:annotation-config/>Tags can be removed at all, because they are included. Originally I survery Spring3 usually only configured as<Context:component-scanBase-package= "Com.foo.bar"/>, meaning to search for the target Class with @component and @configuration under Base-package. And now the following meal:<Context:component-scanBase-package= "Com.foo"use-default-filters= "false"><Context:include-filtertype= "Regex"expression= "Com.foo.bar.*config"/><Context:include-filtertype= "Regex"expression= "com.foo.config.*"/></Context:component-scan> 　　 <Context:component-scan>Two sub tags are available:<Context:include-filter>And<Context:exclude-filter>each representative introduced and excluded the past discard. In the example above, the Use-default-filters is set to false, meaning that in base-package all declared as @component and @configuration, Target class is not registered as a bean,　　By the filter child label. The filter tag has five type in Spring3, as follows: Filter Type Examples Expression descriptionannotation org.example.SomeAnnotation compliant Someannoation Target classassignable org.example.SomeClass Specifies the full name of class or interface AspectJ org.example. *service+ aspectj regex org\.example\. default.* regelar expressioncustom org.example.MyTypeFilter Spring3 New custom type, actually Org.springframework.core.type.TypeF Ilter so the regex in the example above has a language disease, com.foo.config.* You can find Com.foo.config.WebLogger, but you can also find COM1FOOL2CONFIG3ABCDE, because the decimal point in the Regex is any character, so use \. To jump off a small number is good.　　(2010/3/15 supplement: But to use \. Mode, its use-default-filters can not be false, or not caught, feeling is a bug) SPRING3 provides rich filter support, beneficial configuration strategies, without the need to face the configuration Hell, such as the com\.foo\.*\.action\.*config of the regex, so you can find Com.foo Target class for the *config of all action sub-package under the package. I follow his example and configure my own as follows:<Context:component-scanBase-package= "Com.xhlx.finance.budget"  >  <Context:include-filtertype= "Regex"expression= "com.lee.finance.budget.service.*"/>  <Context:include-filtertype= "Regex"expression= "Com.lee.finance.budget.security.*"/> </Context:component-scan>But the scan is not, online and no better explanation, no way to have to try, change into<Context:component-scanBase-package= "Com.xhlx.finance.budget" >  <Context:include-filtertype= "Regex"expression= "com.lee.finance.budget.*"/></Context:component-scan>so even without annotated class also scanned and instantiated, the result is error, because some classes at all there is no default constructor cannot be instantiated, can not error?<Context:component-scanBase-package= "Com.xhlx.finance.budget"  >  <Context:include-filtertype= "Regex"expression= "com\.lee\.finance\.budget\.service.*"/>  </Context:component-scan>The problem remains<Context:component-scanBase-package= "Com.xhlx.finance.budget" >  <Context:include-filtertype= "Regex"expression= "Com.lee.finance.budget.service.TestService"/></Context:component-scan>Hey, this time, write the fully qualified name can be, the expression is not, but if I have thousands of hundred still have to one of such configuration ah? No, continue to study, I want to have a base-package configuration, from the surface of the meaning of this is a "basic package", whether the following filter path is based on this package? So try to change it.<Context:component-scanBase-package= "Com.xhlx.finance.budget" >  <Context:include-filtertype= "Regex"expression= ". service.*"/></Context:component-scan>Hey, all right. 

<mvc:annotation-driven/>

<Mvc:annotation-driven/>explanation According to the Spring API documentation<Mvc:annotation-driven/>The main analysis is @controller @RequestMapping and other annotations. Official Note:<Mvc:annotation-driven/>declares explicit support for Annotation-driven MVC controllers (i.e. @RequestMapping, @Controller, although support For those are the default behaviour), as well as adding support for declrative validation via @Valid and message body Marsh  Alling with @RequestBody/responsebody. Translation:<Mvc:annotation-driven/>The statement explicitly supports the annotation-driven MVC controller (ie, @requestmapping, @Controller, supports those though the default behavior), and adds support for declrative authentication through @ valid and message body Group @ requestbody/  Responsebody. Here is my personal opinion: The document mentions the main is the affirmation annotation, @Controller, @RequestMapping but adds a default behavior later, personally thinks that this kind of annotation is the default in the general case, but in some special cases need to manually configure the declaration.  To find out if the results are true, I have done the following 3 tests. 1 general. No load static resource is not configured by default<Mvc:annotation-driven/>In general, when using Sprin MVC, if static resources are not loaded such as (<mvc:resourcesMapping= "/css/**" Location= "/css/" />System by default will help us to bind the road

"Configuration file Node" Java World Configuration file node