Download Docs   Glossary   Search

Release Notes

• Platform Support and System Requirements

• Migrating Web Services to the Released Version

• Known Limitations

http://www.oracle.com/technology/documentation/index.html

For information on platform support, including hardware and software requirements, see the Supported Platforms page at the following location:

http://download.oracle.com/docs/cd/E13196_01/platform/docs70/support/index.html

Upgrading from WebLogic Server 7.0 Release

This note applies if you are upgrading to the Service Pack 6 release of WebLogic Platform 7.0 from the release of WebLogic Server 7.0 (in which WebLogic Workshop was not included). You must use the upgrade installer, rather than Smart Update, in order to receive all of the components required by the upgrade release.

Migrating Domains Created Using the Configuration Wizard

The Configuration Wizard (introduced in WebLogic Platform 7.0) allows you to create new domains quickly and easily. If you created domains using the Configuration Wizard in WebLogic Platform 7.0, you need to migrate those domains for use with WebLogic Platform 7.0 Service Pack 7.

For most domains, migration is a three-step process:

1. Upgrade the product JAR files in the domain directory. A migration script is provided for this purpose.

Note: You can also revert a domain to its pre-migration state.

2. Update the domain to support Service Pack 6 changes. Depending on the domain template used to generate the domain, you may need to add or modify existing scripts or files.
3. If you installed WebLogic Platform 7.0 Service Pack 7 into a new directory, separate from the WebLogic Platform 7.0 installation, update the domain startup scripts and configuration files to reference the new BEA_HOME directory location.

Note: If you upgraded your existing WebLogic Platform 7.0 installation, you can skip this step.

These steps are explained in detail in the following sections. You will need to repeat this process for each domain that you want to migrate.

Note: This section decribes how to migrate domains specific to WebLogic Workshop. For information about migrating other WebLogic Platform domains, see "Migrating Domains Created Using the Configuration Wizard" in the WebLogic Platform 7.0 Service Pack 7 Release Notes at the following URL:

http://download.oracle.com/docs/cd/E13196_01/platform/docs70/relnotes/relnotes.html#migration

Step 1: Upgrade Product JAR Files

To upgrade product JAR files for a domain that you generated using the Configuration Wizard to Service Pack 7, navigate to the BEA_HOME\weblogic700\server\bin directory and execute one of the following commands:

Windows: migrate.cmd domain mode
UNIX: migrate.sh domain mode

Note: You will be prompted to press any key to start processing.

The following table defines the command-line arguments.

Argument	Description
domain	Full pathname of the domain directory.
mode	Migration mode. The mode can be set to one of the following values: upgrade — Upgrade the product JAR files in the domain directory, as required. The original product JAR files are saved as *.jar.orig. If the timestamp of an existing product JAR file is more recent than the timestamp on the corresponding SP1 installation product JAR file, the file is skipped. This is the default mode. revert — Reverts a domain that was migrated earlier using the backup files (*.jar.orig) generated. If no *.jar.orig files exist, the command is ignore.

For example, the following command upgrades a domain called mydomain located in the default user projects directory (BEA_HOME\user_projects):

Windows: migrate.cmd c:\bea\user_projects\mydomain upgrade
UNIX: migrate.sh c:/bea/user_projects/mydomain upgrade

The following command reverts the changes made to mydomain during the migration:

Windows: migrate.cmd c:\bea\user_projects\mydomain revert
UNIX: migrate.sh c:/bea/user_projects/mydomain revert

Step 2: Update Domain to Support Service Pack 7 Changes

To update a domain that is based on the WebLogic Workshop template to support WebLogic Platform 7.0 Service Pack 7, perform the following steps.

Note: Before adding or modifying any files, it is recommended that you backup the original files.

1. Modify the startWebLogic.cmd (Windows) or startWebLogic.sh (UNIX) command to reflect the appropriate PointBase version (183 versus 172) in the JAR filenames defined in the CLASSPATH. The files for both commands are located in the following directory, by default:

BEA_HOME\user_projects\domain

The following sample excerpt from the startWebLogic.cmd script (Windows) shows the required updates in bold:

Before:

set PB_CLASSPATH=
%POINTBASEDIR%\eval\pointbase\lib\pbserver42ECF172.jar;
%POINTBASEDIR%\eval\pointbase\lib\pbclient42ECF172.jar

After:

set PB_CLASSPATH=.\;
%POINTBASEDIR%\eval\pointbase\lib\pbserver42ECF183.jar;
%POINTBASEDIR%\eval\pointbase\lib\pbclient42ECF183.jar

2. Copy the following files from the BEA_HOME\weblogic700\samples\workshop directory to the BEA_HOME\user_projects\domain directory of your WebLogic Workshop domain. Be careful not to overwrite any files that may have been created using one of these filenames.

   setWorkshopEnv.cmd
   setWorkshopEnv.sh
   startPointBaseConsole.cmd
   startPointBaseConsole.sh
   URLs.dat

Step 3: Update Startup Scripts and Configuration Files to Reference New BEA_HOME Directory Location (Non-Upgrades Only)

Note: This step is only required if you installed WebLogic Platform 7.0 Service Pack 7 into a new directory that is separate from the WebLogic Platform 7.0 installation. If you upgraded your existing WebLogic Platform 7.0 installation, you can skip this step.

The domain startup scripts (such as, startWebLogic) and configuration files (such as config.xml) define the full pathnames to files within the BEA_HOME directory. You need to search for and update these full pathnames to reference the new BEA_HOME directory location. In addition, you must update any custom scripts, such as build scripts, that define full pathnames to the files within the BEA_HOME directory to reflect the new BEA_HOME location.

Note: Many startup scripts set environment variables in your current shell, including variables that reference your BEA_HOME directory. After updating the BEA_HOME references in script files, you should open a new shell to ensure that the latest environment settings are used.

Setting the Maximum Size of Conversation IDs

Conversational web services use a database to store conversation IDs - the unique strings that identify conversations. The database table used to store conversational state is created if it doesn't exist upon the first use of a service. The maximum size for conversation IDs is built into the database schema. The default maximum size allowed for conversation IDs is 768 characters. Ordinarily, 768 works well as a maximum. However, if the design of a particular service requires a different maximum length, you can change it in two ways as described in this note.

First, you must set the weblogic.jws.ConversationMaxKeyLength property. This property can be set in either of the two following ways. Both of these require that you restart the server after making the change:

Edit the startWebLogic command file

1. Locate one of the following files, depending on which operating system you are using: startWebLogic.cmd (on Windows) or startWebLogic.sh (on UNIX or Linux).

   This file is located in the domain directory of your project. For example, for the samples project installed with WebLogic Workshop, this is the samples\workshop directory.

2. Locate the following text in the file:

• On Windows, find the line with the following text: @set JAVA_OPTIONS=%JAVA_OPTIONS% %JAVA_PROPERTIES%
• On Linux or UNIX, find the first line with the following text: JAVA_PROPERTIES=

3. Append the following to the line, replacing <numberOfCharacters> with the new maximum length:

-Dweblogic.jws.ConversationMaxKeyLength=<numberOfCharacters>

Edit the jws-config.properties file

1. Locate the jws-config.properties file.

   This file is located in the domain directory of your project. For example, for the samples project installed with WebLogic Workshop, this is the samples\workshop directory.

2. Change the value of the weblogic.jws.ConversationMaxKeyLength property. The syntax is as follows:

   weblogic.jws.ConversationMaxKeyLength=<numberOfCharacters>

After restarting the server, you must use your service (for example, by calling one of its methods) so that the conversational state table will be recreated with the new maximum conversation ID length. In the event that the conversational state tables already exist, you will need to drop them prior to referencing the service so that they will be recreated. After dropping the tables, and restarting the server, the first reference to your service will cause the tables to be recreated with the new value for the maximum conversation ID length.

Note that a different table is used for each service.

Workshop IDE not available in 7.0 sp7

The Workshop IDE has been removed from 7.0 sp7.

Workaround: Perform WebLogic Workshop development in 7.0 sp6, and copy the source to the 7.0 sp7 server for production.

On UNIX, Starting Managed Server Shuts Down Administration PointBase Server

When you use startManagedWebLogic.sh to start a managed server that is on the same machine as the administration server, the PointBase server that was started with the administration server would be shut down. This is because startManagedWebLogic.sh calls startWebLogic.sh.

Workaround: Edit startWebLogic.sh so that the PointBase server is only restarted if necessary. To do this, move the command to stop the PointBase server beneath the if statement shown below in bold:

  #
  # Start Pointbase
  #
  if [ $POINTBASE_FLAG == true ]; then
  #
  # Kill Pointbase if it's still running
  #
  echo 'SHUTDOWN;' | "$JAVA_HOME/bin/java" -cp "$PB_SHUTDOWN_JARS" com.pointbase.tools.toolsCommander com.pointbase.jdbc.jdbcUniversalDriver jdbc:pointbase:server://localhost:9093/cajun  2> /dev/null > /dev/null
  if [ -z "$POINTBASE_OPTS" ]; then
    #POINTBASE_OPTS=/win
    POINTBASE_OPTS=/noconsole

Working with Databases

Out of Memory Error for Large Result Sets

You may receive an "Out of memory" error when retrieving a large ResultSet using a Database control. This is because the query result is converted to HTML, which more than doubles its size.

Workaround: Try to use queries that return smaller ResultSets or return an Iterator.

"Invalid Transaction State" When Using Pointbase

If you are running Weblogic Workshop with the PointBase database (the default configuration for Workshop), and you encounter an error stating that the database is in an "invalid transaction state", your PointBase database files have become corrupted and you must replace them.

Workaround: Replace cajun.dbn and cajun$1.wal, two PointBase files included with Weblogic Workshop samples. These are located in the WebLogic Workshop samples domain directory. Usually this directory is at /bea/weblogic700/samples/workshop. If you have made back up copies of these two files, you can replace the two files in use with your clean back ups.

You can also download clean copies of the files from the bug fixes section of the resource library at dev2dev Online. On the bug fixes page, look for change request (CR) number CR080632, then click the name of the bug to reach a page from which you can download the files. Note that any information you had stored in your PointBase database will be lost if you replace the files with the clean files downloaded from the web.

Editing Code

CPU Peaks and Computer Hangs When Using the Find Feature

If you are using the Find command to search a file that is 50 KB or larger, you may find that your computer hangs. This can occur if the file contains a very long line of text. For example, if you create a CTRL file from a WSDL file that lacks line breaks (as some do), the WSDL text embedded in the CTRL file will result in a very long line. Using the Find feature on such a file may hang your computer.

Workaround: Ensure that lines of code are properly broken before using the Find feature on a file.

Testing and Debugging

Problems When Using Netscape 6.2

• If you test a JWS file and your browser is Netscape 6.2, the browser may hang in the splash screen when the browser is launched (as when you select "Start" or "Start and Debug" from WebLogic Workshop). This is a bug in Netscape 6.2 that is tracked in Bugzilla bug numbers 54701 and 54716.
• If you test a JWS file in a Netscape 6.2 browser window and try to use the Callback WSDL link on the Overview page, you will get a blank page instead of a generated WSDL.

Workaround: Use a different browser.

WebLogic Server Does Not Respond While Debugging Multiple Service Instances

When debugging a web service using the breakpoints and the Step Into command, WebLogic Server can reach a state in which it no longer responds to commands. This can happen if you run multiple instances of your web service with breakpoints set. For example, you might inadvertently double-click the Test View button corresponding to a method of your service, then use the Step Into command twice (through the Debug menu or toolbar button).

Workaround: If you reach a state in which your project will no longer build, stop and restart WebLogic Server.

Execution Sometimes Moves to Unexpected Locations When Stepping Through Code

In the following situations, you might find that the debugger takes execution to unexpected lines in your code:

• When using the Step Out command, execution moves to the first line of the calling procedure, rather than the line following the call.
• When stepping through a try/catch/finally block, execution moves to the try statement after the catch and finally statements finish executing.
• When stepping through inner class constructors, execution moves to the declaration of the web service class. Doing this repeatedly may cause the debugger to stop responding.

Delay When Attempting to Examine Values While Debugging

You might experience delay when you try to examine variable values while debugging code with large objects. In these cases, WebLogic Workshop will display ... or no value until the value appears.

Cannot Step into Service Control Instance

When debugging, you can't step into a Service control instance. This version of WebLogic Workshop does not allow you to "step into" on a call to a Service control method.

Workaround: If the called web service's source code (JWS file) is available, you can set a breakpoint there.

Test View Does Nothing When Testing with a Large XML Document

When you have a parameter map for a method, the instance of the XML document you enter in the text area for a parameter can exceed the maximum allowable HTTP GET string. When this occurs the browser will appear to accept the button press but will do nothing.

Workaround: Submit a smaller test document or use the Test XML page instead of the Test Form page.

Stopping WebLogic Server While Debugging Can Peak CPU Use

If you are debugging with breakpoints set, then stop WebLogic Server before ending your debugging session, you may find that your CPU usage peaks.

Workaround: End your debugging session by clicking the Stop button or closing the Test View browser window. To avoid this condition, be sure to end your debugging session before stopping WebLogic Server.

Out of Memory Error While Developing on HP-UX

When running WebLogic Workshop for extended periods of time on HP-UX, you may receive an out-of-memory error from WebLogic Server.

Workaround: Increase the maximum Java heap memory allowed. To do this, open startWebLogic.sh and find the section beginning "HP-UX)". In that section edit the JAVA_OPTIONS variable to increase the maximum Java heap memory to 256 megabytes (the default on installation is 128 megabytes). The following illustrates the line in the script you must edit to increase memory. The edited value is in bold text.

JAVA_OPTIONS="-Xms64m -Xmx256m $JAVA_OPTIONS"

WebLogic Workshop on RedHat Linux

Required Environment Setting on Linux 7.1 and Earlier

In order to use WebLogic Workshop on on versions of RedHat Linux prior to 7.2, you must include the following among your environment settings:

export LD_ASSUME_KERNEL=2.2.5

Asynchrony and Callbacks

Client Callbacks Can Fail Silently

When a callback is invoked on a client that has not provided a callback URL, a RuntimeException is generated but no error is reported automatically in Test View or in workshop.log. You are not required to handle RuntimeExceptions, so the error is completely silent by default. If you want to catch occurrences of this situation, you must implement a handler for the JwsContext.onException callback in your JWS file. For more information on the callback, see How Do I: Handle Errors In a Web Service? in the WebLogic Workshop documentation.

Client Proxy Code

XML Maps Must Be Namespace-Qualified In Order to Produce Valid Client Proxy JAR Files

If your web service has XML maps that do not have namespace declarations, the client proxy JAR file generated for that service will be empty. This is due to constraints of the underlying proxy generation code.

Workaround: Add a namespace declaration to the root element of the XML maps, as with the red text in the following example:

/**
* @jws:operation
* @jws:parameter-xml xml-map::
* <person xmlns="http://www.openuri.org/">
* <lastname><xm:value obj="String lastName"/></lastname>
* <firstname>{firstName}</firstname>
* </person>
* ::
*
* @return the string "Received person: '{name}'"
*/
public String acceptPerson(String lastName, String firstName)

Deployment

WebLogic Workshop Uses a Single JMS Server for Certain Messaging Needs

WebLogic Workshop applications can easily be deployed on WebLogic Server cluster environments using the instructions provided in the WebLogic Workshop documentation in Clustering Workshop Web Services.

In WebLogic Workshop, however, applications that use a JMS message queue rely on the services of a single JMS server and connection factory. This includes applications that use JMS as a transport protocol, the message-buffer property, or Timer controls. Future versions of WebLogic Workshop will use the distributed JMS destination capability in WebLogic Server to reduce the dependency on a single JMS server in a clustered environment.

"Unexpected Exception" When Deploying Secure Web Service

When developing a secure web service, you may see the following error message:

An unexpected exception occurred while attempting to deploy the Enterprise JavaBean for this Web Service.

This can happen if there are syntax errors in the web.xml or weblogic.xml files edited to include security information. To confirm that this is the cause of the error message, look in the workshop.log file, which contains exception information logged by a web service. There, you may find specific information about configuration errors.

The workshop.log file is located in the root of the domain in which your web service is deployed. For example, for samples installed with WebLogic Workshop, this is the samples\workshop folder.

Callback Interface Must Be Public on Production Server

Callback interfaces must be declared as "public" in production mode. If you don't declare callback interfaces as public, dynamic proxy generation fails with "IllegalAccessException" in production mode.

UDDI Explorer

UDDI Overview Page Not Rendered in Mozilla on Linux

On Linux, when using the UDDI Explorer to browse for web services, the Mozilla web browser may not render the content of the service's overview page. Note that the page's source code is there, but does not render in Mozilla.

Documentation

Netscape 4.76 May Not Launch from WebLogic Workshop

If your browser is Netscape 4.76, launching Help from WebLogic Workshop may not work. This is a bug in Netscape 4.76 related to launching the browser from another application.

Workaround: Upgrade to at least Netscape 4.78.

Documentation Unusable in Mozilla Version 1.0 on Linux

In the Mozilla 1.0 browser, script used to present navigation panes does not work correctly.

Workaround: Use a different browser.