Considerations for migrating programs from Tomcat to WebSphere

Because the Web application servers that customers use are different in software, TOMCAT5, Tomcat6, Websphere5.1, Websphere6.1, Weblogic8, and so on, and the standards used by these software are inconsistent, IBM was's JDK used its own, the pain is the developer.

Tomcat development generally rarely encounters any problems, and when the real online, customers rarely use tomcat, usually is, this need to deploy the program to be under. Of course, a lot of project leaders who don't do real things will say it's easy (because you didn't do it or you didn't), and put this work after the development of the turn, but in fact, there are many places to pay attention to, preferably before the development of a clear, deployment will reduce a lot of trouble.

Here's a list of my experiences:

1, Include files to note: Copy content to the Clipboard

The following is a reference fragment: <%@ page contenttype= "text/html; Charset=utf-8 "%>

This in WAS5 can not be set several times, include files if there is to be removed, but WAS6.0 above on it.

2, the Serlvet standard in Web.xml

was5.1 only supports 2.3 standards, was6.0 above can support 2.4, if the program needs to cross different versions of the application server, it is best to use 2.3 standard.

The beginning of 2.3 is set as follows: Copy content to clipboard

The following is a reference fragment: <?xml version= "1.0" encoding= "UTF-8"?> <! DOCTYPE Web-app Public "-//sun Microsystems, INC.//DTD Web Application 2.3//en" "Http://java.sun.com/dtd/web-app_2_3. DTD ">

<web-app>2.4 is as follows: Copy content to clipboard

The following is a reference fragment: <?xml version= "1.0" encoding= "UTF-8"?> <web-app xmlns= "HTTP://JAVA.SUN.COM/XML/NS/J2EE" Xmlns:xsi= "Http://www.w3.org/2001/XMLSchema-instance" version= "2.4" xsi:schemalocation= "Http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" >

If you use spring, then you certainly prefer the following configuration: Copy content to clipboard

The following is a reference fragment: <listener> <listener-class> Org.springframework.web.context.ContextLoaderListener </listener-class> </listener> <context-param> <param-name>contextConfigLocation</param-name> <param-value> /web-inf/classes/applicationcontext*.xml </param-value> </context-param>

But unfortunately, in 2.3 of the standard is not used, this really makes me very depressed, but fortunately spring also provides a servlet for initializing copied content to the Clipboard

The following is a reference fragment: <servlet> <servlet-name>SpringContextServlet</servlet-name> <servlet-class> Org.springframework.web.context.ContextLoaderServlet </servlet-class> <load-on-startup>1</load-on-startup>

</servlet> but this will not set the Contextconfiglocation parameter (maybe, I haven't found it yet), so if there are multiple profiles, such as: Applicationcontext-struts.xml, Applicationcontext-hibernate.xml and so on, then I need to synthesize them into a file, web-inf/applicationcontext.xml, notice, not web-inf/classes.

The encoding problem for the 3.AJAX call:

If you use Ajax to pass some Chinese, then when sending to the client from the server, you may be using response.setcharacterencoding ("GBK") to solve the garbled problem, but again sadly, this method is not supported, You can use: Response.setcontenttype ("TEXT/XML;CHARSET=GBK") to replace, I also recommend this way. In addition, the Request.setcharacterencoding method is still available.

4. According to my attempt, it is best to put the Servlet-api.jar bag in, this bag can be found from Tomcat

5. Absolutely to use the jdk1.4 standard to compile, not to you use 1.4 jdk, but to build the standard to 1.4 on it.

If the compilation is not over, then you go to the correct program, do not waste time thinking about what the external door Shandao, such as to change the JDK and so crazy.

So, jdk5.0 and later versions of some new gadgets, if you are not sure that the customer's use of server software support, it is best not to use.

6. Do not write files to the server, or in the cluster deployment will be a problem.

Considerations for migrating programs from Tomcat to WebSphere