Migrating WebLogic Server 6.0 Applications to WebLogic Server 6.1


	BEA Home \| Events \| Solutions \| Partners \| Products \| Services \| Download \| Developer Center \| WebSUPPORT
	http://www.oracle.com/technology/documentation/index.html \| Site Map \| Search \| Download Documentation \| Contact \| Glossary

\| WebLogic Server Doc Home \| Release Notes \| Previous Topic \| Next Topic \| Contents \| View as PDF

The following sections describe steps for migrating applications from 6.0 to 6.1, as well as migration issues to keep in mind.

Migrating an Application from 6.0 to 6.1

Use the following steps to migrate applications from WebLogic Server 6.0 to WebLogic Server 6.1:

Install WebLogic Server 6.1.
Note: Installing the new version directly over the old version is explicitly prohibited by the installer.
For each configuration domain that you wish to migrate to WebLogic Server 6.1, copy the domain directory to the WL_HOME\config directory. This directory will be used to store all of your configuration domains for WebLogic Server 6.1. If your 6.0 config directory is not located in the WebLogic Server 6.0 distribution, you may re-use your WebLogic 6.0 configuration in WebLogic Server 6.1.
1. Identify all external files referenced in config.xml. WebLogic Server configurations rely on a number of files that may be stored on the file system. Typically, these files are persistence repositories (logs files, file-based repositories, etc.) or utilities (Java compiler). These files can be configured using fully qualified or relative paths.
  If all external files are defined using relative paths and are located in or below the domain directory, skip to Step 3.b.
  
  For external files that are defined using relative paths that are located outside the domain directory, re-create the directory structure relative to the new config directory and copy the associated files into the new directories. For external files that are defined using fully qualified paths, determine whether it is appropriate to re-use these files in the WebLogic Server 6.1 deployment.
  
  For example, logs files and persistence store can be re-used; however, you may want to update utilities such as the Java compiler to use the latest version. For files that should be updated, reconfigure the appropriate attribute using the WebLogic Server 6.0 console to use the new file or utility before proceeding to the next step.
  
  Also consider deployment descriptors (web.xml and/or weblogic.xml) because those files may contain file paths to items such as the Java compiler.
2. Copy the appropriate domain directory and all sub-components (directories and files) except console.war into the config directory created in Step 2.
  Make sure to move all transaction logs (*.tlog) and any bloated message queues with the domain.
Edit the server start script for the new domain to use the WebLogic Server 6.1 libraries:
CLASSPATH -

Must include the weblogic.jar from the WebLogic Server 6.1 distribution

java.security.policy property -

Must point to the weblogic.policy file from the WebLogic Server 6.1 distribution

bea.home property -

Must point to your BEA home directory containing the license.bea file for WebLogic Server 6.1.

JMS

Consider the following issues when migrating from WebLogic 6.0 to WebLogic Server 6.1.

In WebLogic Server 6.0, the JMS documentation correctly specifies "default," "true," and "false" for the StoreEnabled attribute of the JMSDestinationMBean, but the software allowed for mixed case characters. WebLogic Server 6.1, however, requires all lowercase characters for the StoreEnabled settings.
For the Acknowledge Policy attribute in the JMS Connection Factory, the default value of "All" is a workaround to accommodate a change in the JMS 1.0.2 specification. The Acknowledge Policy default setting represents a change from prior versions of JMS, which defaulted to "Previous" internally, as it did not appear as an option in the Administration Console.
- All - acknowledge all messages ever received by a given session, regardless of which message calls the acknowledge method.
- Previous - acknowledge all messages received by a given session, but only up to and including the message that calls the acknowledge method. Note that although the default message driven bean (MDB) connection factory already does this, foreign connection factories may differ.

For detailed instructions on migrating previous versions of WebLogic JMS applications, see the "Migrating WebLogic JMS Application" chapter in Programming WebLogic JMS.

EJB 2.0

Sun Microsystem's EJB 2.0 specification has changed between the 6.0 and 6.1 version of WebLogic Server, and therefore we no longer support some deployment descriptor directives. This has caused an exception to the WebLogic Server 6.0 to 6.1 migration rule that WebLogic Server 6.0 applications should work unaltered in the WebLogic Server 6.1 server. (EJB1.1 beans that worked in WebLogic Server 6.0 should work just as well in WebLogic Server 6.1 with no alteration.)

In Weblogic 6.1 a new interface, EJBComponentMBean, extends both ComponentMBean and EJBContainerMBean. Any custom MBeans that implement EJBComponentMBean (for example, getVerboseEJBDeploymentEnabled) have to be changed to support the additional interface when you migrate from WebLogic Server 6.0 to 6.1. When EJBContainerMBean is extended, EJBComponentMBean supplies the same methods that EJBContainerMBean does even though EJBComponentMBean is not an EJB container.

Upgrading EJB 2.0 Session Beans and BMP Entity Beans

There have not been any major changes in the EJB 2.0 session bean or BMP entity bean model. Re-running the WebLogic EJB Compiler (ejbc) in WebLogic Server 6.1 ensures that your ejb-jar.xml file conforms to the latest EJB 2.0 DTD.

Upgrading EJB 2.0 Message-Driven Beans (MDB)

The EJB 2.0 deployment descriptor elements in the ejb-jar.xml file have changed for Message-Driven beans. The <jms-acknowledge-mode> should be changed to <acknowledge-mode>, and <jms-destination-type> is now <destination-type>.

WebLogic Server 6.0 Message-Driven bean users may have a tag named <run-as-specified-identity> in their deployment descriptor. This tag was not supported in WebLogic Server 6.0, and its name has changed to <run as> in the latest EJB 2.0 changes. Since WebLogic Server 6.0 did not support this feature, most 6.0 Message-Driven bean users probably do not need a run-as deployment and can remove this element from their ejb-jar.xml file. If you need a run-as identity, you must change the element to <run-as> in the ejb-jar.xml file.

Upgrading EJB 2.0 CMP Entity Beans

The EJB 2.0 specification contains a number of changes to the CMP 2.0 model.

The first step is to ensure that your ejb-jar.xml file conforms to the latest EJB 2.0 DTD. There have been some changes in the element names. The <role-source> tag is now named <relationship-role-source>. The <run-as-specified-identity> tag is now <run-as>.

The latest EJB 2.0 specification introduces the concept of a local interface. EJB relationships are now based on the local interface. Any EJB that participates in a relationship must have a local interface.

Remote Relationships were removed from the EJB 2.0 specification. Relationships in WebLogic Server are now only between EJB 2.0 CMP entity beans, and the related beans must be deployed within the same EJB JAR file.

JMX

All public WebLogic Server 6.0 MBeans and attributes are supported in WebLogic Server 6.1. However, if you are employing internal MBeans or attributes, you may encounter migration issues.

Apache XML Parser

The XML WebLogic Server 6.0 -> 6.1 parser has been updated and is now based on the Apache Xerces 1.3.1 parser. The parser implements version 2 of the SAX and DOM interfaces. Users who used older parsers that were shipped in previous versions may receive deprecation messages.

The parsers provided in the the xmlx.jar file have been deprecated but are included for backward compatibility. Users who prefer to use external parsers should do so through JAXP. Migration of non-JAXP code to JAXP code may involve some code adjustments.

Xalan XML Parser

The Xalan APIs are deprecated. If you are still using those APIs and encounter difficulties, you are advised to use the JAXP API to use XSLT.

Changes were made to Apache's Xalan code to enable Xerces and Xalan to work together. You may encounter problems if you use Xalan from Apache, because it will not include these changes.

In general, it is best to use JAXP and to migrate any vendor-specific code to a neutral API such as JAXP for SAX, DOM and XSL processing.

Web Applications

The weblogic.management.descriptors.webapp.ServletMBean.getName() API (in WebLogic Server 6.0) has changed to weblogic.management.descriptors.webapp.ServletMBean.getServletName() in WebLogic Server 6.1. You will have to update your source code and recompile if you are using this interface.

With Java Servlet Specification 2.3, authorization on forward is no longer default behavior. To obtain authorization when you forward to a secure resource, add <check-auth-on-forward> to weblogic.xml.

Servlet Request and Response objects have a new API. Some serializable, lightweight implementations of these may no longer compile without implementing the new API. It is strongly recommended that you use the new Servlet 2.3 model and substitute your implementations of Servlet Request and Response objects. If you did this in WebLogic Server 6.0, you were probably relying on the undocumented, internal implementations of these objects. WebLogic Server 6.1 supports Servlet 2.3, so you should be able to take advantage of the new ServletRequest/ResponseWrapper objects.

Security

The default condition of the server is to impose the tightest access control list (ACL) on all MBeans. Therefore, if you are making programmatic MBean changes as any non-system user you will be denied access unless you relax the restriction.

config\applications Directory

WebLogic Server 6.1 introduces a division between runtime modes. The two modes are "development" and "production." The runtime mode is selected using a command line parameter when starting the Weblogic Admin Server (-Dweblogic.ProductionModeEnabled=true | false). If this parameter is not set, the server runs in development mode. In development mode the server behavior is consistent with WebLogic Server 6.0. In production mode, however, the auto-deployment feature is disabled. Deployment units in the applications directory that are not explicitly deployed in the configuration repository (config.xml) will not be automatically deployed. Note that in WebLogic Server 6.1 the default (mydomain) and Pet Store configurations are shipped in production mode. The examples configuration is shipped in development mode. This feature only works on the Admin Server, because the AppManager thread that polls the applications directory for changes is only created on Admin servers.

WebLogic Server Clusters on Solaris

Certain applications (heavy EJB apps) deployed in a WebLogic Server cluster on Solaris will perform better using the client JVM rather than the server JVM. This is especially true under heavy loads.

Thread Pool Size

In WebLogic Server 6.0, the number of worker threads was specified via the ThreadPoolSize parameter on the server MBean. Starting in WebLogic Server 6.1, the number of worker threads is defined via an ExecuteQueue on the Server MBean.

WebLogic Server 6.1 provides a migration path for this parameter, so that if it is specified in the config.xml, or if it is passed to the client or server on the command line (-Dweblogic.ThreadPoolSize=<xx>), WebLogic Server migrates your ThreadPoolSize to the ThreadCount setting automatically.

In WebLogic Server 6.1 Service Pack 1, there was a bug in the console that displayed an incorrect value (the default value) for the ThreadCount. However, this was only a bug in the console, and the correct number of threads was being used by the client/server.

Setting the number of worker threads :

In WebLogic Server 6:0
<Server
Name="myserver"
ThreadPoolSize="23"
...
/Server>

Starting in WebLogic Server 6.1:

<Server
Name="myserver"
... >
<ExecuteQueue
Name="default"
ThreadCount="23" />
/Server>

To change the thread count value via the console:

In the console, select Servers > myServer > Monitoring > .
2. Click on Monitor all Active Queues.

3. Click on "default" queue (a list of threads and what they are doing appears).

4. Click on Configure Execute Queues (at the top of the page).

5. Click on "default" queue.

6. Enter the number of threads associated with this server.

7. Restart the server to make changes take effect.