Process migration from tomcat to websphere changes
Because customers use the web application server software used by different what tomcat5, tomcat6, websphere5.1, websphere6.1, weblogic8, and so on, and the software used inconsistent standards, ibm's was even jdk are used their own, are suffering ah developers.
tomcat developed under the general rarely has any problems, but really on the line, customers seldom used tomcat, generally was (both websphere), which deployed to the required procedure was put under. Of course, not a lot of things the project manager would say that this is very simple (because you have not done is that you do not), and put into the development of this work to go after, but in fact, there are still places a lot of attention should be paid to , preferably in the development of the former to make it clear that the deployment would be reduced when a lot of trouble.
The following put out about my experience:
1, include the documents necessary to pay attention to:
Copy the contents to the clipboard
Code:
<% @ Page contentType = "text / html; charset = UTF-8"%>
This should not be repeated under was5 settings, include the document has to be removed if,
But more than was6.0 it.
2, web.xml in serlvet standard
Supporting was5.1 only 2.3 standard, was6.0 can support more than 2.4, if the procedures required across different versions of the application server, preferably using the standard 2.3.
2.3 at the beginning of set as follows:
Copy the contents to the clipboard
Code:
<? 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 are as follows:
Copy the contents to the clipboard
Code:
<? 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">
Useful if you spring, then you definitely enjoy the following configuration:
Copy the contents to the clipboard
Code:
<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 I am sorry to say, under the standards in 2.3 are not used, this is so that I am郁闷,还好spring also provides a servlet for initialization
Copy the contents to the clipboard
Code:
<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 be able to set up a contextConfigLocation parameters (perhaps there are I have not found), so, if there are multiple configuration files, such as:
applicationContext-struts.xml, applicationContext-hibernate.xml and so on,
Then they put me on the synthesis of a necessary document, on the web-inf \ applicationContext.xml, attention, not web-inf \ classes Medium.
Call 3.ajax coding problem:
Ajax useful if you go mass some Chinese, then the server-side from the hair to the client, you may
response.setCharacterEncoding ( "GBK"), to solve the garbage problem, but again I am sorry to say,
This method is not supported, you can use:
response.setContentType ( "text / xml; charset = GBK");
To replace, I would recommend this approach. In addition, request.setCharacterEncoding method can still be used.
4. According to my attempt, it would be best put into the servlet-api.jar packages go, this package can be found inside tomcat
5. Absolute standard to use jdk1.4 to compile, not to you use the 1.4 jdk, just put the standard changed to 1.4 to build it.
If the compiler does not last, then you go to process it honestly, do not think what a waste of time to go outside the door evil ways, such as to effect a change was the jdk act crazy and so on.
Therefore, jdk5.0 and later add some new stuff, if you can not determine the use of client server software to support it, it might be advisable not to use.
6. Do not write files to the server, otherwise, when deployed in the cluster will have a problem.
Because customers use the web application server software used by different what tomcat5, tomcat6, websphere5.1, websphere6.1, weblogic8, and so on, and the software used inconsistent standards, ibm's was even jdk are used their own, are suffering ah developers.
tomcat developed under the general rarely has any problems, but really on the line, customers seldom used tomcat, generally was (both websphere), which deployed to the required procedure was put under. Of course, not a lot of things the project manager would say that this is very simple (because you have not done is that you do not), and put into the development of this work to go after, but in fact, there are still places a lot of attention should be paid to , preferably in the development of the former to make it clear that the deployment would be reduced when a lot of trouble.
The following put out about my experience:
1, include the documents necessary to pay attention to:
Copy the contents to the clipboard
Code:
<% @ Page contentType = "text / html; charset = UTF-8"%>
This should not be repeated under was5 settings, include the document has to be removed if,
But more than was6.0 it.
2, web.xml in serlvet standard
Supporting was5.1 only 2.3 standard, was6.0 can support more than 2.4, if the procedures required across different versions of the application server, preferably using the standard 2.3.
2.3 at the beginning of set as follows:
Copy the contents to the clipboard
Code:
<? 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 are as follows:
Copy the contents to the clipboard
Code:
<? 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">
Useful if you spring, then you definitely enjoy the following configuration:
Copy the contents to the clipboard
Code:
<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 I am sorry to say, under the standards in 2.3 are not used, this is so that I am郁闷,还好spring also provides a servlet for initialization
Copy the contents to the clipboard
Code:
<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 be able to set up a contextConfigLocation parameters (perhaps there are I have not found), so, if there are multiple configuration files, such as:
applicationContext-struts.xml, applicationContext-hibernate.xml and so on,
Then they put me on the synthesis of a necessary document, on the web-inf \ applicationContext.xml, attention, not web-inf \ classes Medium.
Call 3.ajax coding problem:
Ajax useful if you go mass some Chinese, then the server-side from the hair to the client, you may
response.setCharacterEncoding ( "GBK"), to solve the garbage problem, but again I am sorry to say,
This method is not supported, you can use:
response.setContentType ( "text / xml; charset = GBK");
To replace, I would recommend this approach. In addition, request.setCharacterEncoding method can still be used.
4. According to my attempt, it would be best put into the servlet-api.jar packages go, this package can be found inside tomcat
5. Absolute standard to use jdk1.4 to compile, not to you use the 1.4 jdk, just put the standard changed to 1.4 to build it.
If the compiler does not last, then you go to process it honestly, do not think what a waste of time to go outside the door evil ways, such as to effect a change was the jdk act crazy and so on.
Therefore, jdk5.0 and later add some new stuff, if you can not determine the use of client server software to support it, it might be advisable not to use.
6. Do not write files to the server, otherwise, when deployed in the cluster will have a problem.