Hints and tips for migrating web services

Migration hints

If you are migrating your web service or web service components from earlier versions of this product, refer to the following hints and tips to improve your success.
JAX-RS jar locations

JAX-RS web services created in earlier versions of the product are affected by WebSphere Application Server v8.0 supporting Feature Pack for Web 2.0 v1.0.x and v1.1.0 coexistence. This results in Rational Application Developer supporting the four JAX-RS 1.1. library providers as well as the four deprecated JAX-RS 1.0.x library providers.

If you are migrating a project referencing the Feature Pack for Web 2.0 v1.0.x JAX-RS libraries into a newer version of Rational Application Developer, your project will only work if you still have Feature Pack for Web 2.0 v1.0.x installed. If you have migrated to Feature Pack for Web 2.0 v1.1, you will need to migrate your project to use the newer JAX-RS libraries. This can be done by right-clicking the project and selecting Properties > Project Facets > JAX-RS and selecting a new library type.

Secure web services not migrated
Secure web services are not migrated by the J2EE Migration Wizard when web services are migrated from J2EE 1.3 to J2EE 1.4. The migration of secure web services requires manual steps. After the J2EE migration, the secure binding and extension files must be migrated manually to J2EE 1.4 as follows:
  1. Double click on the webservices.xml file to open the web services editor.
  2. Select the Binding Configurations tab to edit the binding file.
  3. Add all the necessary binding configurations under the new sections Request Consumer Binding Configuration Details and Response Generator Binding Configuration Details.
  4. Select the Extension tab to edit the extension file.
  5. Add all the necessary extension configurations under the new sections Request Consumer Service Configuration Details and Response Generator Service Configuration Details.
  6. Save and exit the editor.
Migrated EARs have build error due to JDK compliance level
Web service EARs generated in earlier versions of the product may have a build error due to the Java™ compiler using J2SE 5.0 as its default JDK compliance level. The Java code generated by the older web service wizards used enum as a package identifier which is a reserved keyword in J2SE 5.0. To resolve this issue:
  1. Select the affected web service project, right-click and select Properties.
  2. Select Java Compiler from the list of properties.
  3. In the JDK Compliance section, change the Compiler compliance level to 1.4 or later. Click OK.
EAR fails to deploy due to JDK level

Exception thrown: com.ibm.etools.webservice.deploy.core.WebserviceXMLException: Compilation error in *.jar

Problem: An EAR file created and exported from the workspace fails to deploy on WebSphere® Application Server 6.1.x resulting in the following error: class file has wrong version 49.0, should be 48.0 Please remove or make sure it appears in the correct subdirectory of the classpath

Cause: When creating a project, the default JDK compiler is JDK 5.0. The WebSphere Application Server 6.1.x JDK level is 1.4. Java 1.4 creates class files labeled with version 48.0. Java 1.5 creates class files labeled with version 49.0. Java 1.4 cannot run class files labeled with version 49.0.

Solution: Recompile the project containing the class using JDK 1.4 compiler by doing the following:
  1. Right click on the project and select Properties > Project Facets.
  2. Click Add/Remove Project Facets.
  3. Double-click Version for the second Java entry.
  4. Select 1.4 from the drop-down list.
  5. Click Finish > OK.
  6. Right click the project and select Properties > Java Compiler.
You will see the complier compliance level has been changed to 1.4 7. Export the compiled EAR file and deploy on WebSphere Application Server 6.1.x - the deployment should be successful.
Migrating a Client application with some Policy set configuration from Rational® Application Developer v7.0.0.x to Rational Application Developer v7.5

When migrating a client application with some policy set configuration from WebSphere Application Server 6.1.0.9 ( the version installed with Rational Application Developer v7.0.0.x) or older to an environment that uses a later WebSphere Application Server level (such as in WebSphere Application Server v7.5), the client side policy set binding configuration need to be updated. In WebSphere Application Server v6.1.0.9 and older, the tools generated a custom client binding configuration to compliment the Server Side Default Binding. When migrating this client application and its service to a more recent WebSphere Application Server level, you need to change to use the client side default binding as well.

Steps for migrating the client side application:
  1. Run the Manage Policy Set Attachment wizard for the client application.
  2. Select the Endpoint in the application table.
  3. Select Edit, and in the Endpoint Configuration Dialog, modify the binding field, by selecting <Default Binding> from the drop down.
  4. Select OK, and click Finish.
  5. Wait for the application to republish on the WebSphere server before testing it.
If you are migrating from a policy set which is no longer recognized (such as when you move a web service from WebSphere Application Server v6.1.x to WebSphere Application Server v7) run the Manage Policy Set Attachment wizard and you will be informed if the policy set is supported and provided with the opportunity to migrate to a supported policy set.

Feedback