WDO to SDO migration
If you created code in a Web project targeted at WebSphere Application Server V5.1 that used WebSphere Data Objects (WDO) relational records or relational record lists, when you target these applications to WebSphere Application Server V6.0 you will now use Service Data Objects (SDO) relational records and relational record lists. The migration from WDO to SDO happens automatically when you change the target server of your application from WebSphere Application Server V5.1 to WebSphere Application Server V6.0.
The target server can be changed in two ways:
- You can modify the target server using the project's properties dialog. Right-click on the project in the Project Explorer view, and select Properties > Server > Target runtime.
- During J2EE migration using the J2EE Migration Wizard you can re-target the application to use another server.
Note: You can only migrate to a higher J2EE specification level.
Help topics on changing your target server and using the J2EE Migration Wizard can be found in the online help for Rational Web Developer.
Compatibility considerations
- Any code written to the public application programming interfaces (APIs) for the WDO access beans will be supported in V6.0 (although the implementation classes have changed to target the SDO runtime).
- New code generated for WebSphere Application Server V6.0 will not use the WDO access beans, but will instead generate code for the pure SDO APIs.
- Any code generated to a project while targeted at V6.0 will not run on a V5.1 server even if migrated back by re-targeting the server.
- Code written for V5.1 can be migrated forward and backwards by targeting a V5.1 server.
Type collision errors may occur following migration from WDO to SDO
After a project utilizing WDO is migrated to an SDO-based project, if you add SDO data to an existing JSP page that has existing WDO data, type collision errors may occur. This arises due to the mixing of existing WDO access beans and stand-alone SDO APIs. For example, you may see a compilation error on the Java source file of the JSP similar to the following:
The import com.ibm.websphere.sdo.mediator.exception.MediatorException collides with another imported typeThese type collision errors can be corrected as follows:
- Remove the colliding import statement from the Java source file. Using the example above, you would remove the following import statement from the source file:
import com.ibm.websphere.wdo.mediator.exception.MediatorException;- Modify the Java source file that references that type to use the fully qualified class name. Based on the example above, the type MediatorException must be changed to com.ibm.websphere.wdo.mediator.exception.MediatorException. For instance, source code written as
catch ( MediatorException e1 ) {must be changed tocatch ( com.ibm.websphere.wdo.mediator.exception.MediatorException e1 ) {
Changes to a Web project after changing the target server from V5.1 to V6.0 (WDO to SDO)
The following changes are made automatically when the target server is changed from V5.1 to V6.0:
- The Java archive (JAR) files wdo_web.jar and wdo_jdbc_access.jar are removed from the project.
- The following JAR files are removed from the project's class path:
- emf-runtime.jar
- emf-event.jar
- wdo-interface.jar
- wdo.jar
- jdbcmediator.jar
- wdo.xmlmediator.jar
- The files sdo_web.jar and sdo_access_beans.jar are added to the project (SDO runtime JAR files are automatically added to any V6.0 project's classpath).
- Any JavaServer Pages Standard Tag Library (JSTL) 1.0 JAR files are removed from the project. (JSTL 1.1/JSP 2.0 JAR files are automatically added to any V6.0 project's class path).
- The following import statements are changed in any Java sourcre files:
- com.ibm.websphere.wdo.access.connections.ConnectionManager changes to com.ibm.websphere.sdo.access.connections.ConnectionManager.
- com.ibm.websphere.wdo.mediator.rdb.ConnectionWrapper changes to com.ibm.websphere.sdo.mediator.jdbc.ConnectionWrapper.
Changes to a Web project after changing the server target from V6.0 to V5.1 (SDO to WDO)
The following changes are made automatically when the target server is changed from V6.0 to V5.1:
- The JAR files sdo_web.jar and sdo_access_beans.jar are removed from the project.
- The JAR files wdo_web.jar and wdo_jdbc_access.jar are added to the project.
- The following JAR files are added to the project's classpath:
- emf-runtime.jar
- emf-event.jar
- wdo-interface.jar
- wdo.jar
- jdbcmediator.jar
- wdo.xmlmediator.jar
- JSTL 1.0 JAR files are added to the project. (JSTL 1.1/JSP 2.0 JARs are removed from the project's class path).
- The following import statements are changed in any Java source files:
- com.ibm.websphere.sdo.access.connections.ConnectionManager becomes com.ibm.websphere.wdo.access.connections.ConnectionManager.
- com.ibm.websphere.sdo.mediator.jdbc.ConnectionWrapper becomes com.ibm.websphere.wdo.mediator.rdb.ConnectionWrapper.
Changes to a Web project after changing the J2EE level of your application from 1.3 to 1.4
In addition to the changes that occur to migrate from WDO to SDO by changing the server target to WebSphere Application Server V6.0, changing the J2EE specification level of your application from 1.3 to 1.4 updates any tag library (taglib) references in your JavaServer Pages (JSPs) from using WDO, JSTL 1.0 tag libraries to SDO, JSTL 1.1/jsp 2.0 tag libraries. The following table shows the changes in the JSP taglib references when you move from J2EE 1.3 to J2EE 1.4.
Table 1. JSP taglib references in J2EE 1.3 and J2EE 1.4. J2EE 1.3 taglib (WDO) J2EE 1.4 taglib (SDO) http://www.ibm.com/websphere/wdo/core http://www.ibm.com/websphere/sdo/core http://java.sun.com/jstl/core http://java.sun.com/jsp/jstl/core http://java.sun.com/jstl/fmt http://java.sun.com/jsp/jstl/fmt http://java.sun.com/jstl/xml http://java.sun.com/jsp/jstl/xml http://java.sun.com/jstl/sql http://java.sun.com/jsp/jstl/sql
Parent topic
Migrating from WebSphere Studio V5.1, 5.1.1, or 5.1.2
Related concepts
Compatibility with WebSphere Studio V5.1.x
Related tasks
Migrating from WebSphere Studio V5.1, 5.1.1, or 5.1.2