Application Server-JBoss to WebSphere migration

*** Reprint

* Reprinted URL: http://www.chinaitpower.com/2006Aug/2006-09-19/215409.html

 

Recently, we have migrated the JBoss server to the WebSphere server. At the beginning, we were too optimistic. We thought it was an application server in the J2EE architecture, which should be 1 ~ It took us nearly two weeks to complete the work within two days. There are many typical problems encountered during the migration process, so I think it is necessary to summarize:

 

Environment: JBoss-Tomcat 3.2.6, database Oracle9i, workflow part to EJB, Struts + hibernate architecture, presentation layer using jstl,

 

Migration environment: wsad 5.1.2 and WebSphere 5.1 (updated to 5.1.0.4)

 

The entire application is basically an ear package consisting of XXX. War (Web Application) + yyy. Jar (EJB module)

• 1. Oracle lob Field Type Problems in WebSphere

In our EJB module, an entity bean contains a field that uses the Oracle long raw type (long and row long data types are not recommended after 8 I ), this field type cannot be well supported on WebSphere (this problem exists in both 5.1 and the latest 6.0 versions). The actual result is that pmgr6031e is thrown when the field is read: sqlexception when trying to get resultset column X as a byte.

 

The solution is to convert the database's long raw to the Blob field type and update the WebSphere version to 5.1.0.4 (Reference 2) or later, it is best not to Update to the latest version 5.1.1 or above, because there are some strange problems when we update Websphere to version 5.1.1.4 during the migration process, for example, if Chinese characters are garbled and the length of the inserted value is too large during database writing (these problems do not exist in 5.1.0.4 or 5.1.0.5 ).

 

Tip: On oralce, convert the Data Type of long raw to blob.

 

1. Back up the table to be converted. See command: EXP user name/password @ service name file = backup file name tables = table name

 

2. Clear the existing table (delete from table name)

 

3. Use alter to change the long raw type of an existing table to blob (alter table table name modify (column name BLOB ))

 

4. import database data. Run the IMP command in cmd to import the data backed up earlier. Add the ignore = y parameter to ignore the error of table creation. For details, refer to the command: IMP username/password @ service name file = backup file name tables = table name ignore = y

 

Conclusion: Do not use lob fields in CMP.

 

 

 

• 2. The error message "wtrn0062e" is returned when sessionbean calls entitybean in EJB: An error occurred while trying to use multiple resources with only one stage of capability in a global transaction.

Solution (Reference 3 ):

 

1. if the EJB module uses the same data source, use the same method to reference their JNDI. Otherwise, all of them are directly referenced by JNDI, or Java: COMP/ENV /... In the deployment description Editor (ejb-jar.xml)-> overview-> WebSphere binding-> JNDI-CMP connection factory binding Replace the container authorization type with per_connection_factory.

 

2. if your EJB module references different data sources and you use these different data sources in some ways, the above method may not be suitable for you. You should replace it with the Xa data source driver. The Code may also be changed. See references later

 

• 3. The page contenttype of JSP in Web applications cannot be repeated.

In tomcat, if. JSP contains B. JSP, then. JSP and B. <% @ page contenttype = "text/html; charset = GBK" %> must be added to both JSP files. Otherwise, Chinese characters may be garbled on the JSP page. However, in WebSphere, if. JSP and B. if <% @ page contenttype = "text/html; charset = GBK" %> exists on JSP, an exception is thrown: Multiple contenttypes are not allowed,

 

Solution: Remove <% @ page contenttype = "text/html; charset = GBK" %> from B. jsp.

 

If you use the above solution, your web application code is inconsistent with WebSphere in JBoss. if you want to maintain compatibility with WebSphere in JBoss, you can use the following method. In the servlet2.4 specification, JSP-config is used to set pageencoding to GBK (Reference 3). In this case, <% @ page contenttype = "text/html; charset = GBK" %> does not need to be added to JSP pages. In tomcat4.1 or later versions, servlet2.4 is supported, however, only j2ee1.3 is supported on WebSphere 5.1, servlet is supported to 2.3, and 2.4 is not supported. The latest WebSphere 6 supports j2ee1.4 (servlet supports to 2.4 ), if you want to maintain compatibility between applications and JBoss on WebSphere 5.1, you can apply different Web applications in two versions. XML, that is, the specifications of servlet2.3 and servlet2.4 are used in Tomcat of JBoss in WebSphere 5.1.

 

New question: if it is only used on WebSphere 5.1,. JSP uses static methods to include B. for JSP files. <% @ page contenttype = "text/html; charset = GBK" %>, B. this line of statements cannot be added to JSP. If the B. jsp file needs to be accessed separately, the B. jsp file will be garbled.

 

Solution: Because B. JSP can be accessed separately, so B. JSP can be independent. JSP exists, so static inclusion should not be used (<% @ include ...) a. change JSP to dynamic include B. JSP method (<JSP: include... />)

 

• 4. Tag Problems

1. in webspehre5.1, tags with the same descriptor cannot be contained on the same page, such as. JSP uses <% include .. methods include B. JSP file, and both files contain the same label description, for example, all contain <% @ taglib uri = "/WEB-INF/TLD/C. TLD "prefix =" C "%>. WebSphere will throw the org. xml. Sax. saxparseexception: the attribute "xmlns: C" has been specified for the element "JSP: Root.

 

But on Tomcat, this method is acceptable.

 

The solution is to remove duplicate tag references.

 

2. the XML Parser of JBoss is different from the XML Parser of Websphere, causing errors in the use of some taglib.

 

Example: <C: When>

 

.........

 

</C: When> (there is a space in it)

 

This code is normal on JBoss, but an exception occurs in WebSphere. Remove the spaces in </C: When> to exclude exceptions.

 

• 5. Inconsistent servlet API implementation

Since sun only releases Servlet implementation standards, the specific implementation is done by the application server, so the implementation standards on different application servers are different.

 

For example, the request. getrequesturl () method

 

We map test. Action to the test. jsp file through the configuration file. The content of test. jsp is:

 

<% Request. getrequesturl () %>

 

If you enter the address http: // localhost: 8080/test. action. The returned value in JBoss is http: // localhost: 8080/test. action, and the actual JSP address: http: // localhost: 8080/test. JSP

 

The servlet API documentation is also ambiguous. Therefore, application server vendors can implement the API documentation based on their different understandings.

 

This problem can only be implemented by changing the program.

 

• 6. Good ear package structure should be selected for WebSphere

WebSphere has strict load on class libraries. It is best not to include the same class library packages of different versions in an application. Check the jar packages under the WEB-INF/lib.

 

To deploy an application on websphere, you must release the application in the ear mode. Therefore, if your attachments are managed as files on the web application, you should consider the configurability of the attachment storage address in the program design, it is best not to place it under the Web Container. Otherwise, it may be difficult to maintain and upgrade it in the future, because the Web can be deployed only after being packaged, therefore, you need to obtain the latest attachment information from the customer side, and then package and deploy it.

 

Solution:

 

1. Use an absolute address (configurable), but it seems that this is not beautiful enough.

 

2. Use a database to save the attachment information. This changes the original program design and may require many modifications.

 

3. (not tested) use a separate war package to save the variable application data. In this way, do not update the war package during deployment.

 

Summary:

 

WebSphere basically strictly complies with J2EE specifications, so it sacrifices some compatibility. For example, you cannot re-specify WebSphere JDK, but you can only use its own version, in addition, different versions of Websphere are based on the J2EE version. was5.1 only supports j2ee1.3 and was6.0 only supports j2ee1.4. If you want to use j2ee1.4, you must use was6.0. In terms of deployment, WebSphere has a certain degree of penetration to the program. wsad needs to generate a large amount of deployment Code. For example, rmic code will be generated for EJB, which is arranged under your package, I personally think.

 

If you encounter problems during deployment, go to the http://www-128.ibm.com/developerworks/cn site to find most of the problems found on it.

 

References:

 

1. Port the J2EE application to the WebSphere Application Server

 

Http://www.128.ibm.com/developerworks/cn/websphere/library/techarticles/0408_baigang/part1.html

 

Http://www.128.ibm.com/developerworks/cn/websphere/library/techarticles/0408_baigang/part2.html

 

Http://www.128.ibm.com/developerworks/cn/websphere/library/techarticles/0408_baigang/part3.html

 

2. http://www.1.ibm.com/support/docview.wss? Rs = 180 & uid = swg27004980

 

3. http://www.developer.ibm.com/isv/tech/faq/individual? Oid = 2: 84043.

 

4. Tomcat include Chinese problem solution

 

Http://www.matrix.org.cn/thread.shtml? Forum_id = 14 & view_id = 21142

 

5. Use WebSphere Studio to map the CMP Entity Bean field to the clob Column

 

Http://www.28.ibm.com/developerworks/cn/websphere/library/techarticles/0405_beaton/0405_beaton.html