Review
In the previous section, we have discussed the Spring Security-related configurations. In this section we will discuss the remaining configuration of our application.Table of Contents
Click on a link to jump to that section:
- Functional Specs
- Generate OAuth keys
- Spring Social configuration
- Spring Security configuration
- JavaConfig
- ApplicationInitializer.java
- ApplicationContext.java
- DataConfig.java
- ThymeleafConfig.java
- spring.properties
- View with Thymeleaf
- Layers
- Domain
- Repository
- Service
- Controller
- Running the application
- Clone from GitHub
- Create the Database
- Run with Maven and Tomcat 7
- Run with Maven and Jetty 8
- Import to Eclipse
- Validate with W3C
JavaConfig
As stated in the introduction, we will be using JavaConfig-based configuration instead of the usual XML config. However, I don't want to alienate our readers who are used to XML. As a result, I've decided to provide both implementations. However, our focus here is still on JavaConfig.Note: With JavaConfig, we can now omit the ubiquitous web.xml. But in order to that, we need to run a Servlet 3.0 web container. For this tutorial, I have tested the application with Tomcat 7.0.30 (Maven plugin), 7.0.33 (standalone Tomcat), and Jetty 8.1.5.v20120716 (Maven plugin).
ApplicationInitializer.java
The ApplicationInitializer.java is the equivalent of web.xml. Here's where we declare the DispatcherServlet and also we've registered two filters: one for Spring Security and another for Spring Social.
Here's the equivalent XML configuration:
ApplicationContext.java
The ApplicationContext.java contains our main configuration. It's responsible for loading other configurations, either as JavaConfig or XML config.
Let's describe each annotation:
@Configuration
- Marks a class as a JavaConfig@ComponentScan(basePackages = {"org.krams"})
- Configures scanning of Spring components
This is equivalent in XML as:@EnableWebMvc
- Activates Spring's MVC support
This is equivalent in XML as:@Import({DataConfig.class, ThymeleafConfig.class, SocialConfig.class, SecurityConfig.class})
- This allows us to import JavaConfig-based config. Notice we have imported four configuration classes@ImportResource("classpath:trace-context.xml")
- This allows us to import XML-based config files. (As a side note why can't we just declare this as a JavaConfig? It turns out there's no direct translation for the trace-context.xml, so we'll have to import it as XML).
This is equivalent in XML as:@PropertySource("classpath:spring.properties")
- This allows us to import property files@Bean
- Declares a Spring bean
Here's the equivalent XML configuration:
DataConfig.java
The DataConfig.java contains our Spring Data configuration. This is where we declare our data source, transaction manager, and JPA entity manager.
Here's the equivalent XML configuration:
ThymeleafConfig.java
The ThymeleafConfig.java contains our Thymeleaf configuration. This is where we declare our Thymeleaf view resolver.
We've declared some special settings on our Thymeleaf configuration:
// Declare virtual paths
resolver.addTemplateAlias("connect/facebookConnect","facebook/connect");
resolver.addTemplateAlias("connect/twitterConnect","twitter/connect");
resolver.addTemplateAlias("connect/facebookConnected","facebook/connected");
resolver.addTemplateAlias("connect/twitterConnected","facebook/connected");
// Disable cache for testing purposes
resolver.setCacheable(false);
These allows to redirect virtual path requests to specific templates within our application. We need to do this because the ConnectController from Spring Social has its own built-in controller path requests. And we need to redirect the resulting views that matches our template path.
For example, when connecting to Facebook, ConnectController will use the connect/facebookConnect path and you are required to provide a view. Using the addTemplateAlias() method, we can provide a custom view, in this case, the view points to the directory in the WEB-INF/templates/facebook/connect.
Also, we've disabled the caching feature so that we can easily update and test our html pages.
Here's the equivalent XML configuration:
SecurityConfig.java
The SecurityConfig.java contains a single bean DelegatingFilterProxy. This is required for Spring Security.
spring.properties
spring.properties contains the property settings of our application. You need to declare your Facebook and Twitter OAuth settings here. Here's also where you declare your database.
messages_en.properties
This is for internationalization of messages. The default language is English. If you need to provide custom language, create a new properties file and replace the values according to the language you've chosen. Please see the Spring documentation for more info on internationalization.
0 komentar:
Post a Comment