Benx Blog

八月 10, 2014

Diigo Diary 08/10/2014

Filed under: Diigo Diary — benxshen @ 8:30 上午
    • public @interface PropertySource

       

      Annotation providing a convenient and declarative mechanism for adding a  PropertySource to Spring’s  Environment. To be used in  conjunction with @Configuration classes.  

      Example usage

       

      Given a file app.properties containing the key/value pair  testbean.name=myTestBean, the following @Configuration class  uses @PropertySource to contribute app.properties to the  Environment‘s set of PropertySources.  

       @Configuration  @PropertySource("classpath:/com/myco/app.properties")  public class AppConfig {      @Autowired      Environment env;       @Bean      public TestBean testBean() {          TestBean testBean = new TestBean();          testBean.setName(env.getProperty("testbean.name"));          return testBean;      }  }
    • How then does one switch to the JNDI lookup when actually in production? Of course it’s necessary to activate the “production" profile. It’s fine to do this programmatically for the purpose of a unit test as above, but this approach won’t be practical once the WAR file has been created and the application is ready for deployment. For this reason, profiles may also be activated declaratively through the spring.profiles.active property which may be specified through system environment variables, JVM system properties, servlet context parameters in web.xml or even as an entry in JNDI [2]. For example, you might configure web.xml as follows:

       

        <servlet>       <servlet-name>dispatcher</servlet-name>       <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>       <init-param>           <param-name>spring.profiles.active</param-name>           <param-value>production</param-value>       </init-param>   </servlet>
    • How then does one switch to the JNDI lookup when actually in production? Of course it’s necessary to activate the “production" profile.
    • Note that profiles are not an “either-or" proposition; it is possible to activate multiple profiles at once. Programmatically, simply provide multiple profile names to the setActiveProfiles() method, which accepts String... varargs:

       

          ctx.getEnvironment().setActiveProfiles("profile1", "profile2"); 

       

      Declaratively, spring.profiles.active may accept a comma-separated list of profile names:

       

          -Dspring.profiles.active="profile1,profile2" 

       

      Bean definition files may be marked as candidates for more than one profile in a similar fashion:

       

          <beans profile="profile1,profile2">         ...     </beans>
    • <beans profile=“dev">  <jdbc:embeddeddatabase id=“dataSource">  <jdbc:script location=“classpath:com/bank/config/sql/schema.sql"/>  <jdbc:script location=“classpath:com/bank/config/sql/test-data.sql"/>  </jdbc:embeddeddatabase>  </beans>
    • Do not use profiles if a simpler approach can get the job done. If the only thing changing between profiles is the value of properties, Spring’s existing PropertyPlaceholderConfigurer / <context:property-placeholder/> may be all you need.
    • public interface HandlerAdapter

       

      MVC framework SPI, allowing parameterization of the core MVC workflow.  

      Interface that must be implemented for each handler type to handle a request. 

    • public interface HandlerAdapter

       

      MVC framework SPI, allowing parameterization of the core MVC workflow.  
    • Note that a handler can be of type Object. This is to enable  handlers from other frameworks to be integrated with this framework without  custom coding, as well as to allow for annotation-driven handler objects that  do not obey any specific Java interface.
    • This interface is not intended for application developers. It is available  to handlers who want to develop their own web workflow.
    • 4.17.1 BeanFactory or ApplicationContext?

        

      Use an ApplicationContext unless you have a good reason for not doing so.

    • The following table lists features provided by the BeanFactory and ApplicationContext interfaces and implementations.

       

      Table 4.8. Feature Matrix

        
      Feature BeanFactory ApplicationContext

      Bean instantiation/wiring

      Yes

      Yes

      Automatic BeanPostProcessor registration

      No

      Yes

      Automatic BeanFactoryPostProcessor registration

      No

      Yes

      Convenient MessageSource access (for i18n)

      No

      Yes

      ApplicationEvent publication

    • The following table lists features provided by the BeanFactory and ApplicationContext interfaces and implementations.

       

      Table 4.8. Feature Matrix

        
      Feature BeanFactory ApplicationContext

      Bean instantiation/wiring

      Yes

      Yes

      Automatic BeanPostProcessor registration

      No

      Yes

      Automatic BeanFactoryPostProcessor registration

      No

      Yes

      Convenient MessageSource access (for i18n)

      No

      Yes

      ApplicationEvent publication

    • The following table lists features provided by the BeanFactory and ApplicationContext interfaces and implementations.

       

      Table 4.8. Feature Matrix

        
      Feature BeanFactory ApplicationContext

      Bean instantiation/wiring

      Yes

      Yes

      Automatic BeanPostProcessor registration

      No

      Yes

      Automatic BeanFactoryPostProcessor registration

      No

      Yes

      Convenient MessageSource access (for i18n)

      No

      Yes

      ApplicationEvent publication

      No

      Yes

       


        

      To explicitly register a bean post-processor with a BeanFactory implementation, you must write code like this:

       

      ConfigurableBeanFactory factory = new XmlBeanFactory(...);  // now register any needed BeanPostProcessor instances MyBeanPostProcessor postProcessor = new MyBeanPostProcessor(); factory.addBeanPostProcessor(postProcessor);  // now start using the factory

        

    • Note: When chaining ViewResolvers, an InternalResourceViewResolver  always needs to be last, as it will attempt to resolve any view name,  no matter whether the underlying resource actually exists.
    • As a special feature, redirect URLs can be specified via the “redirect:"  prefix. E.g.: “redirect:myAction.do" will trigger a redirect to the given  URL, rather than resolution as standard view name. This is typically used  for redirecting to a controller URL after finishing a form workflow.  

      Furthermore, forward URLs can be specified via the “forward:" prefix. E.g.:  “forward:myAction.do" will trigger a forward to the given URL, rather than  resolution as standard view name. This is typically used for controller URLs;  it is not supposed to be used for JSP URLs – use logical view names there.  

    • Note: When chaining ViewResolvers, a UrlBasedViewResolver will check whether  the specified resource actually exists.  However, with InternalResourceView, it is not generally possible to  determine the existence of the target resource upfront. In such a scenario,  a UrlBasedViewResolver will always return View for any given view name;  as a consequence, it should be configured as the last ViewResolver in the chain.

Posted from Diigo. The rest of my favorite links are here.

發表迴響 »

仍無迴響。

RSS feed for comments on this post. TrackBack URI

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 變更 )

Twitter picture

You are commenting using your Twitter account. Log Out / 變更 )

Facebook照片

You are commenting using your Facebook account. Log Out / 變更 )

Google+ photo

You are commenting using your Google+ account. Log Out / 變更 )

連結到 %s

在WordPress.com寫網誌.

%d 位部落客按了讚: