Advanced Configuration of spring MVC Framework

This article provides you with spring MVC Framework configuration skills to help you manage multiple instances of spring-based Web applications. This configuration governance topic is often ignored by academia, but this is especially important for practical web development. This topic is not directly related to any specific technology. Therefore, we will describe this issue from the very basic concept. Next, we will provide a series of solutions for projects based on the spring MVC framework.

Spring Configuration

People often configure a web application on more than one host. For example, in production, a website may only have one instance. With this exception, developers can configure other (Development) instances on the machine used for development. You can also maintain other application devices on local development servers within your company (institution), which will benefit you a lot. The purpose of this instance is to enable web designers to obtain quality assurance materials and provide access to those who need to provide document materials for applications.

We all know that, even in the simplest scenario, three instances need to be installed, configured, and maintained. For teams located in different geographic locations, it is more difficult to engage in such projects. For any non-trivial web application project, multiple developers are required to install the project device and local setup, as well as to run the unit test device.

Many organizations use their own products as Web applications. We can find this situation in many products, such as e-commerce systems, content governance systems (CMS), and blog publishing platforms. Such products can be deployed on multiple servers. For successful multi-purpose Web applications, their developers must ensure that their applications are easy to install and can be perfectly integrated with other web applications. After the above discussion, we should understand that application configuration, as the topic of this article, is one of the important issues that developers of general web application programs need to solve.

Version control systems such as CVS or subversion are a standard tool used by development organizations. This tool represents the central source code version libraries of some organizations, which are used to keep the source code in order. You can track application source code changes, display the differences between different versions, and determine the project branch. Moreover, they make it possible to perform partial updates during application deployment.

Obviously, version control system software is necessary for tracking source code, which is very helpful for solving application configuration problems. In this article, we will not focus on version control systems, because there are a lot of related materials. Here, we will focus on a small topic in version control: How to make web application configuration more convenient (especially Web applications written using spring MVC Framework ).

Question: What kind of configuration is discussed here? All Web applications require some resources. These resources are generally unique to the servers they run, such as database URLs and SMTP servers that send emails, and folders containing private software files. This setting should be centralized to make the application configuration easier.

However, this is only the simplest version of the problem. Sometimes, more complex configurations are required in application development. This means that different beans in each deployment must be connected, which makes the problem more complicated.

The solution to these application configuration problems has many advantages, including simplifying the installation and configuration process of the application, making source code version control easier, and reducing conflicts in the source code version library. Next, we will discuss this topic through examples.

Problem

First, let's demonstrate the simplest version mentioned above. In this scenario, what we want to change in application deployment is simple configuration parameters, such as links and passwords. If you have used spring MVC framework to develop Web applications, you should know the two configuration files used here:

◆/WEB-INF/applicationcontext. XML, which allows you to configure beans or display application context. With this file, you can define your own business logic beans, resources, and all other beans that can be associated with Web ports.

◆/WEB-INF/[servlet-name]-servlet. XML, which is used to configure the necessary beans in the web layer, view parser, controller, checker, and all other MVC frameworks. [Servlet-name] refers to the name of the spring dispatcher servlet defined in the web. xml deployment descriptor.

So where is the problem? The problem is that applicationcontext. xml includes some host-specific bean definitions. Among them, the most obvious example is the bean that contains JDBC connection information, but a dozen similar beans exist in any slightly more complicated application. See the following example in detail:

<Bean id = "datasource"

Class = "org. springframework. JDBC. datasource. drivermanagerdatasource"> "〉

<Property name = "driverclassname"> "〉

<Value> org. PostgreSQL. Driver </value> 〉

</Property> 〉

<Property name = "url"> "〉

<Value> JDBC: PostgreSQL: // localhost/test </value> 〉

</Property> 〉

<Property name = "username"> "〉

<Value> S </value> 〉

</Property> 〉

<Property name = "password"> "〉

<Value> </value> 〉

</Property> 〉

</Bean> 〉

The problem with this solution lies in the maintenance of the applicationcontext. xml file. For beginners, imagine that the project is placed in the source code version control system, such as CVS. Next, if you want to add new functions to your website, you need to add additional bean definitions to the application context definition. The problem is how to reflect these changes on production servers.

Generally, the local instance of the application does not use the same database as the active site. Therefore, the applicationcontext. xml file includes settings that allow you to access the local database. When you want to submit changes in the source code version library, you need to pay attention to the synchronization of these specific host attributes. Files in the version library may eventually use the configuration in local settings. To update the configuration on the production server, you must manually synchronize the values of these attributes. This is a very boring task, and it is very easy to make mistakes.

This issue is even more important for every instance of the application. Assume that three developers are using the code snippet base address and they are using a local database. When you submit changes, each of them must be cautious when updating the source code on the local server. They will manually synchronize these changes and then submit their work. In this way, the version control system is useless for these configuration files. If you have used spring MVC, you should know that applicationcontext. XML is a key component in the application, because it binds everything together. Therefore, it is important that we need a mechanism to help keep the items in the application in order.

As mentioned above, this is a simple configuration problem that you may encounter. The more difficult problem occurs when different bean connections need to be performed on different servers. Such problems often occur in routine software development tasks. For example, if your product has a customer authentication module, you can perform identity verification for users from relational databases or LDAP servers. Naturally, this authentication module can be configured using bean abstracted from a specific version library. If you want to change the way users are verified in different application deployments, You need to perform different bean connections in the applicationcontext. xml file. This configuration problem is common in all applications with configurable features during deployment.

 

This article from: http://webservices.ctocio.com.cn/wsare/13/8692013.shtml