The following describes problems you might see after upgrading from version 8.1, but which aren't tied to particular component types or technologies. For upgrade-related issues associated with specific technologies, see the topics listed under Related Topics.
Upgrade of a version 8.1 application might fail if the .workshop directory is not present in the application during upgrade. In particular, upgrade of the weblogic-application.xml file might fail if the file references build artifacts in the .workshop directory, but the directory does not exist.
To help ensure successful upgrade, be sure to build your version 8.1 application before upgrading.
Generally speaking, the upgrade process will present a warning message when a precompiled library must be recompiled to be used in the version 10.x environment. However, there might be cases when the library should be recompiled but no message is presented. In other words, consider recompiling these libraries when you see compile errors in a project that you can't otherwise account for.
Unlike version 8.1, version 10.x enforces the line length size limit in JAR file manifests when the JAR is used as an application library. Upgraded applications containing JARs with lines exceeding the limit will generate errors at build time. To work around this change, either reduce the size of the lines or remove the manifest from the JAR.
The use of internal APIs is not supported and the version 10.x classpath does not (and should not) include weblogic.jar. Public APIs that used to be in weblogic.jar have been moved into wls-api.jar. The workaround for breakage due to the absence of weblogic.jar from the classpath is to rewrite code to use public APIs.
In addition, code that uses third-party APIs is not supported for upgrade to version 10.x.
New language features in Java 5 and the JSP 2.0 expression language (which is used by the NetUI tag libraries) might make it necessary to rewrite portions of upgraded code.
For example, new features reserve words that were not reserved for code written in version 8.1. Workshop upgrade tools do not upgrade the use of these words, so code that uses them will not compile until you rewrite it so that it accounts for the new language features.
In particular, Java 5 adds the
enum keyword. For more information, see Enums at the Sun web site.
JSP 2.0 reserved words are listed in Reserved Words Can Not Be Used as Identifiers.
In addition, upgraded code might encounter many changes in the Java APIs. With the addition of generics to the Java language, method signatures that took Object parameters in Java 1.4 have become more strongly typed. This enables Workshop version 10.x to detect many errors at compile time that would only appear at run time in version 8.1. For example, if you wrote:
String s; Thing t; s.compareTo(t);
you would see no compilation error in version 8.1, but a ClassCastException would occur at run time. In version 10.x, compareTo(t) will be flagged as an compile time error because String.compareTo() actually expects a String parameter in version 10.x, but only requires an Object in 8.1.
As a general rule, debugged code will not contain these types of errors. But when they appear during post-upgrade compilation, you must fix the code before the project will build successfully.
During the upgrade process, Workshop upgrade tools update package import statements to support the movement of key libraries. In some cases, this might break code that uses a class from the version 8.1 package that is still in that package. For example, upgrade tools will make the following changes:
... would be changed to...
without an import because it is still in the older package. You can easily
repair the code by using the Workshop quick fix feature to
import required packages. Another, more thorough fix would be to remove
wildcards and explicitly import classes in the version 8.1 code before
Version 8.1 includes APIs provided with the Pointbase database. These are not supported in version 10.x.
Version 8.1 of the IDE allowed the use of schemas that were not standards-compliant; version 10.x does not. As a result, invalid schemas will generate errors during upgrade. Note, however, that while errors will appear in the IDE, the errors should not effect runtime behavior.
If you want to continue using the schemas in their invalid state but don't want errors displayed in the IDE, you can turn off schema validation. If you turn off validation, it will be off for all schemas, even though you may want to have validated. To turn off schema validation:
When you create a new server as described in Creating a Server Definition for Use Within the IDE, you can upgrade a WebLogic Workshop version 8.1 domain.
An older version domain is detected. Click here to upgrade it with the Upgrade Wizard.
During upgrade from version 8.1, upgrade tools will copy CLASS files from the version 8.1 PROJECT_ROOT/WEB-INF/classes directory (which is intended for CLASS files from artifacts not in the project) to the version 10.x's PROJECT_ROOT/WebContent/WEB_INF/classes directory (the default location for project artifact build output). If your 8.1 project bypasses the default build output locations (such as with an Ant script) to put CLASS files from project artifacts in PROJECT_ROOT/WEB-INF/classes, you might see errors from duplicate CLASS files in the version 10.x output directory.
To correct this situation, after upgrading delete the contents of the PROJECT_ROOT/WebContent/WEB_INF/classes directory and rebuild the project.