WebLogic Server 8.1 Upgrade Guide
Upgrading WebLogic Server 5.1 to version 8.1 is a multi-step process that involves, among other tasks, using a utility to convert your
weblogic.properties file(s) into a new XML file format. There are also several specification changes that affect the upgrade process. The following sections address most known upgrade issues, but may omit issues that are unique to a specific environment.
The following sections provide procedures and other information you need to upgrade your system from WebLogic Server 5.1 to WebLogic Server 8.1; to upgrade your applications from WebLogic Server 5.1 to WebLogic Server 8.1; and deploy these applications. Instructions apply to upgrades from both WebLogic Server 5.1 to WebLogic Server 8.1.
To see an example of an application being upgraded from WebLogic Server 5.1 to WebLogic Server 8.1, see Upgrading the Banking Application from WebLogic Server 5.1 to WebLogic Server 8.1.
When you upgrade to WebLogic Server 8.1, your servers and applications will be managed in WebLogic Server domains. For a full description of WebLogic Server domains see Overview of WebLogic Server Domains in Configuring and Managing WebLogic Server.
BEA WebLogic recommends that you locate domain directories outside the WebLogic Server installation directory. Domain directories can be in any location that can access the WebLogic Server installation and the JDK.
If you change the location of your domain directory, remember to update any custom tools or scripts relative to the new directory structure. Similarly, if you use a scripted tool for creating domains, change its scripts. The Configuration Wizard is the recommended tool for creating domains, and it can be scripted.
The configuration of a domain is stored in the
config.xml file of the domain directory on the Administration Server (for information about Administration Servers and Managed Servers, see Overview of WebLogic Server Domains in Configuring and Managing WebLogic Server).
config.xml stores the name of the domain and the configuration parameter settings for each server instance, cluster, resource, and service in the domain.
These general steps are a checklist of issues to consider when upgrading from version 5.1 to version 8.1. For a detailed example of such an upgrade, see Upgrading the Banking Application from WebLogic Server 5.1 to WebLogic Server 8.1.
To upgrade a cluster of server instances, you must install WebLogic Server 8.1 on each computer that hosts server instances. If you are upgrading a server cluster, refer to Setting Up WebLogic Clusters in Using WebLogic Server Clusters for WebLogic Server cluster configuration guidelines.
WebLogicLicense.XMLlicense file before installing WebLogic Server 8.1. See Upgrading WebLogic Server License Files.
Prior to WebLogic Server 6.0, a separate download was required if you wanted to use 128-bit encryption instead of 56-bit encryption. WebLogic Server 8.1 has a single download for both 56-bit encryption and 128-bit encryption. For details about how to enable 128-bit encryption see Enabling 128-Bit Encryption in the Installation Guide.
For example, if you compile an upgraded application with WebLogic Server 8.1, 8.1 dependencies on JDK 1.4 require that your 8.1 domain reference JDK 1.4 or an equivalent such as JRockit. For more information on upgrading to JRockit, see Upgrading Your JVM to JRockit.
The Java format license file (
WebLogicLicense.class) and the XML-format license file (
WebLogicLicense.XML) are no longer supported. These files were used with earlier releases of WebLogic Server and must be converted to a new format. The new license file is called
WebLogicLicense.classlicense file to a
WebLogicLicense.XMLfile using the licenseConverter utility.
WebLogicLicense.XMLfile as described in Converting a WebLogicLicense.XML License.
To convert a
WebLogicLicense.XML file to a
license.bea file (compatible with WebLogic Server 8.1), complete the following steps. Be sure the
WebLogicLicense.XML license file is available on the machine on which you perform this procedure.
.beafile through e-mail. To update the
license.beafile on your system, see "Installing and Updating WebLogic Platform License Files" in Installing WebLogic Platform.
Prior to WebLogic Server 6.0, WebLogic Server releases used a
weblogic.properties file to configure applications. In WebLogic Server 8.1, configuration is handled by a domain configuration file,
config.xml, and by deployment descriptor files. Converting a
weblogic.properties file to the
config.xml file creates a WebLogic Server 8.1 domain for your applications and generates the XML files that define how your applications are set up.
config.xml file is an XML document that describes the configuration of an entire Weblogic Server domain. The
config.xml file consists of a series of XML elements. The
domain element is the top-level element. The
domain element includes child elements, such as the
application elements. These child elements often have children themselves. Each element has one or more configurable attributes.
weblogic.xml file contains WebLogic-specific attributes for a Web application. You define the following attributes in this file: HTTP session parameters, HTTP cookie parameters, JSP parameters, resource references, security role assignments, character set mappings, and container attributes.
The deployment descriptor
web.xml file is defined by the Servlet 2.3 specification from Sun Microsystems. The
web.xml file defines each servlet and JSP page and enumerates enterprise beans referenced in the Web application. This deployment descriptor can be used to deploy a Web application on any J2EE-compliant application server.
For information on starting the WebLogic Server 8.1 examples server, see Starting and Stopping Servers: Quick Reference.
http://localhost:7001/console/index.jsp) click on the "Convert weblogic.properties" link under the heading Helpful Tools.
weblogic.propertiesconverter will convert the application directories into a WebLogic Server 8.1 domain.
When you convert your
weblogic.properties file, the
web.xml and weblogic.xml files for the default Web application are created for you and placed inside the
domain\applications\DefaultWebApp_myserver\WEB-INF directory. Converting your
weblogic.properties file also creates the
config.xml file located in
domain. This file contains configuration information specific to your domain.
Note: The conversion utility described above specifies the Java home location in the
weblogic.xml file. It reads this location using the
System.getProperty(java.home), which means that it will specify the Java home location on which WebLogic Server was started for the conversion.
config.xmlfile directly. Access the configuration through the Administration Console, a command line utility, or programmatically through the configuration API. For details on editing
config.xml, see WebLogic Server Configuration Reference.
fileRealm.propertiesfile located in domain.
weblogic.common.ConfigServicesDefAPI, which provided methods to get properties out of the
weblogic.propertiesfile, has been removed from this version.
For more procedures for converting your
weblogic.properties file, see the Console Help documentation.
For a list of which
config.xml, web.xml, or weblogic.xml attribute handles the function formerly performed by
weblogic.properties properties, see Mapping weblogic.properties to 6.x config.xml Configuration Attributes.
These scripts exist under the domain directory in your WebLogic Server 8.1 distribution and start the Administration Server in the new domain. You may need to edit this startup script to further specify your startup preferences for the domain.See Modifying Startup Scripts.
Before WebLogic Server 6.0, WebLogic Server used the WebLogic classpath property (
weblogic.class.path) to facilitate dynamic classloading. In WebLogic 6.0 and later, the
weblogic.class.path is no longer needed. You can now load classes from the Java system classpath.
To include the classes that were formerly specified in
weblogic.class.path in the standard Java system classpath, set the
CLASSPATH environment variable, or use the
-classpath option on the command line as in the following example:
weblogic.properties converter created a new startup script (called
.sh) for your new WebLogic Server 8.1 domain. If you need to edit this script to specify your domain startup preferences, keep the following in mind.
In order to convert an application to a Web application and upgrade it to WebLogic Server 8.1, the application's files must be placed within a directory structure that follows a specific pattern. For more information on Web applications see Developing Web Applications for WebLogic Server.
The Web application Deployment Descriptor (
web.xml) file is a standard J2EE descriptor used to register your servlets, define servlet initialization parameters, register JSP tag libraries, define security constraints, and define other Web application parameters.
There is also a WebLogic-specific Web application deployment descriptor (
weblogic.xml). In this file you define JSP properties, JNDI mappings, security role mappings, and HTTP session parameters. The WebLogic-specific deployment descriptor also defines how named resources in the
web.xml file are mapped to resources residing elsewhere in WebLogic Server. For detailed instructions on creating the WebLogic-specific deployment descriptor, see weblogic.xml Deployment Descriptor Elements in Developing Web Applications for WebLogic Server. This file may not be required if you do not need the preceding properties, mappings, or parameters.
weblogic.xml files, in conjunction with the Administration Console, to configure your applications. The XML files can be viewed through any text editor. To edit them, simply make your changes and save the file as
weblogic.xml. See Developing Web Applications for WebLogic Server for more information. If you do not want to deploy your applications together as a single Web application, you need to split up the XML files that have been created for you, creating the appropriate XML files specific to each Web application. Each Web application needs a
weblogic.xml file and a
web.xml file as well as whichever files you choose to put in it.
A WAR file is a Web application archive. Use the following command line from the root directory containing your Web application to create a WAR file, replacing `webAppName' with the specific name you have chosen for your Web application:
WebLogic Server 8.1 does not recognize cookies from previous versions because cookie format changed with WebLogic Server 6.0. WebLogic Server will ignore cookies with the old format and create new sessions. Be aware that new sessions are created automatically.
weblogic.propertiesfile to XML elements and attributes in
weblogic.xml. For information on this process, see Converting the weblogic.properties File to config.xml.
web.xmlfile should use:
The following procedure upgrades the Hello World Servlet provided with WebLogic 5.1 Server to WebLogic Server 8.1. The procedures assume that you have both 5.1 and 8.1 installed on a single server, and only 8.1 is running.
C:\hello, as well as a
C:\hello\WEB-INFdirectory and a
HelloWorld.Servlet.javafile (located in the
WL_HOME\examples\servletsdirectory of your 5.1 installation) inside the
web.xmlfile for this servlet. If you converted your
web.xmlfile has already been created for you. If you registered HelloWorldServlet in your
weblogic.propertiesfile before you converted it, the servlet will be configured in your new
web.xmlfile. An XML file can be created with any text editor. The following is an example of a basic
web.xmlfile that could be used with the HelloWorldServlet.
<!DOCTYPE web-app (View Source for full doctype...)>
For more information on
web.xml files, see web.xml Deployment Descriptor Elements in Developing Web Applications for WebLogic Server. A
weblogic.xml file is not necessary with such a simple, stand-alone servlet as HelloWorld.
For more information on
weblogic.xml files, see weblogic.xml Deployment Descriptor Elements in Developing Web Applications for WebLogic Server.
In this case
/hello/ is the context path of the servlet. This is determined by the naming of the WAR file, in this case
hello.war. The second
/hello was mapped in the servlet mapping tags inside the
EJB 1.1 beans can be converted to 2.0 using the DDConverter utility. For more information, see DDConverter in Programming WebLogic Enterprise Java Beans.
ejbchas not been run on an EJB, WebLogic Server 8.1 will run
ejbcautomatically when the bean is deployed. You do not need to compile beans with
ejbcbefore deploying. If you wish to run
ejbcduring startup, you may do so. See EJB Development Task Guide in Programming WebLogic Enterprise Java Beans.
ejb-jar.xmlmust conform to either the EJB 1.1 DTD (document type definition) or the EJB 2.0 DTD.
weblogic-ejb-jar.xmlfile, a WebLogic Server-specific deployment descriptor that includes configuration information for the WebLogic Server EJB container. This file must conform to the WebLogic Server 5.1 DTD or the WebLogic Server 8.1 DTD.
max-beans-in-cacheparameter controls the maximum number of beans in the cache for Database concurrency. In earlier WebLogic Server versions,
max-beans-in-cachewas ignored; the size of the cache was unlimited. You may need to increase the size of this parameter.
The WebLogic Server EJB compiler (
weblogic.ejbc) generates Java code that is then compiled by the Java compiler. By default, WebLogic Server uses the
javac compiler included with the bundled JDK. The EJB compiler runs much faster when a faster Java compiler is used. Use the
-compiler option to specify an alternate compiler as in the following example:
The WebLogic Server 8.1 EJB compiler (
ejbc) includes additional verification that was missing from earlier WebLogic Server releases. It is possible that an EJB deployed in a previous WebLogic Server version without error, but WebLogic Server 8.1 finds and complains about the error. These errors must be corrected before the EJB is deployed in WebLogic Server 8.1.
For instance, WebLogic Server 8.1 ensures that a method exists if a transaction attribute is set for that method name. This helps identify a common set of errors where transaction attributes were mistakenly set on non-existent methods.
EJBs should always get their database connections from a
TxDataSource. This allows the EJB container's transaction management to interface with the JDBC connection, and it also supports XA transactions.
The WebLogic Server 8.1 CMP deployment descriptor (
TxDataSources and should be used instead of the WebLogic Server 5.1 CMP deployment descriptor which only specifies a connection pool.
The following combinations include a WebLogic Server 8.1 CMP deployment descriptor. The WebLogic Server 8.1 EJB 1.1 CMP deployment descriptor allows multiple EJBs to be specified within a single EJB JAR file, and it supports using a
The WebLogic Server 5.1
weblogic.properties file only allows the exclusive or read-only concurrency options. The database concurrency option is available when upgrading to the WebLogic Server 8.1
weblogic-ejb-jar.xml file. See Choosing a Concurrency Strategy in Programming WebLogic Enterprise Java Beans.
The WebLogic Server 8.1 CMP deployment descriptor,
weblogic-cmp-rdbms-jar.xml, allows multiple EJBs to be specified and supports using a
TxDataSource instead of a connection pool. Using a
TxDataSource is required when XA is being used with EJB 1.1 CMP.
BEA Systems recommends that you develop EJB 2.0 beans in conjunction with WebLogic Server 8.1. For 1.1 beans already used in production, it is not necessary to convert them to 2.0 beans. EJB 1.1 beans are deployable with WebLogic Server 8.1.
EJB 1.1 beans declare CMP fields in the bean. CMP 2.0 beans use abstract
setXXX methods for each field. For instance, 1.1 beans will use
public String name. EJB 2.0 beans should use
public abstract String getName() and
public abstract void setName(String n). With this modification, the bean class should now read the container-managed fields with the
getName method and update them with the
java.util.Enumerationshould now use
java.util.Collection.CMP 2.0 finders cannot return
java.util.Enumeration. Change your code to reflect this:
Any EJB that complies with the EJB 1.1 or EJB 2.0 specifications can be deployed in the WebLogic Server 8.1 EJB container. Each EJB JAR file requires an
ejb-jar.xml file, a
weblogic-ejb-jar.xml deployment descriptor, and a CMP deployment descriptor if CMP entity beans are used. The WebLogic Server EJB examples located in
samples\examples\ejb20 of the WebLogic Server distribution include sample weblogic deployment descriptors.
WebLogic Server 8.1 supports the JavaSoft JMS specification version 1.0.2.
To upgrade your WebLogic Server JMS applications, see the procedures in Porting WebLogic JMS Applications in Programming WebLogic JMS. Note that WebLogic Events are deprecated and are replaced by JMS messages with NO_ACKNOWLEDGE or MULTICAST_NO_ACKNOWLEDGE delivery modes. Each of these delivery modes is described in WebLogic JMS Fundamentals in Programming WebLogic JMS.
BEA Systems, mirroring Oracle's support policy, supports the Oracle releases listed in the Platform Support for WebLogic jDriver JDBC Drivers on the WebLogic Server Certifications page. BEA no longer supports the following Oracle client versions: 7.3.4, 8.0.4, 8.0.5, and 8.1.5.
For detailed documentation on the WebLogic jDriver and Oracle databases, see Configuring WebLogic jDriver for Oracle in Installing and Using WebLogic jDriver for Oracle.
For supported platforms, as well as DBMS and client libraries, see the BEA Certifications Page. The most current certification information will always be posted on the Certifications page.
The conversion utility writes the properties in your WebLogic Server 5.1
weblogic.properties file to a WebLogic Server 8.1 domain configuration file,
config.xml. For more information about domains in WebLogic Server, see WebLogic Server Configuration Reference.
WL_HOMEis your WebLogic Server installation directory.
setExamplesEnv.cmd. In Unix, use
weblogic.properties conversion utility generated a script called
startmigrationdomain for starting up the banking application's domain. Edit this script to specify additional variables needed to run the upgraded banking application in this new 8.1 domain.
startmigrationdomainscript, making sure to add it before the final
The following sections provide additional information that may be useful when you deploy applications on WebLogic Server 8.1. Deprecated features, upgrades, and the important changes that have been made in WebLogic Server 8.1 are noted.
By default, applications are deployed to the Administration Server. However, in most cases, this is not good practice. You should use the Administration Server only for administrative purposes. Use the Administration Console to define new Managed Servers and associate the applications with those servers. For more information, see Using WebLogic Server Clusters and Overview of WebLogic System Administration in the Administration Guide.
By default, WebLogic Server version 8.1 uses a two-phase deployment model includes a prepare phase and an activate phase, which helps prevent inconsistent server states by allowing deployments to be validated before being committed to the server. For more information on this deployment model and other 8.1 deployment features, see Deploying WebLogic Server Applications. If you deploy a 5.1 application in WebLogic Server 8.1 without specifying the deployment model, the server will use the two-phase deployment. For more information, see the WebLogic Server 8.1 Release Notes.
In WebLogic Server 6.1 Service Pack 2 and later, the behavior of FileServlet, which is the default servlet for a Web Application, has changed. FileServlet now includes the SERVLET_PATH setting for determining the source filename. This setting makes it possible to explicitly only serve files from specific directories by mapping the FileServlet to
See Setting Up a Default Servlet in Developing Web Applications for WebLogic Server.
LogServicesDefis deprecated. Instead, use the internationalized API or
weblogic.logging.NonCatalogLogger(when internationalization is not required).
For details on internationalization in this version, see the Internationalization Guide.
WebLogic Server 8.1 has dependencies on JDK 1.4. If you compile an application after putting the 8.1 weblogic.jar in your classpath, the classes must be built under JDK 1.4. This means that your server start script (or
config.xml, or environment setting) must reference JRockit or JDK 1.4.x.
jdbc:weblogic:jts:..) has been replaced by a JTA JDBC/XA driver. Existing properties are available for backward compatibility, but you should change the class name and properties to reflect the JTS to JTA name change.
weblogic.jdbc20.*packages are being replaced with
weblogic.jdbc.*packages. All WebLogic JDBC drivers are now compliant with JDBC 2.0.
preparedStatement, and the stored procedure gets dropped in the DBMS, use a new name to create the stored procedure. If you recreate the stored procedure with the same name, the
preparedStatementwill not know how to access the newly created stored procedure—it is essentially a different object with the same name.
When you upgrade a domain to WebLogic Server 8.1, consider upgrading your JVM to JRockit. WebLogic JRockit is a JVM designed for running server-side applications in Windows and Linux running on Intel architectures. For server-side applications, JRockit has these advantages over other virtual machines:
JAVA_HOME(or equivalent) shell variables to point to the JRockit root directory. For example, change:
For JRockit platform and user information, see the appropriate version of the JRockit User Guide.
The behavior of the JSP include directive has changed between WebLogic Server 5.1 and the current version. In versions through WebLogic Server 5.1, the JSP include directive logged a Warning-level message if it included a non-existent page. In WebLogic Server 6.0 and later, it reports 500 Internal Server Error in that case.You can avoid the error by placing an empty file at the referenced location.
Due to a change in the JSP specification, null request attributes now return the string "null" instead of an empty string. WebLogic Server versions since 6.1 contain a new flag in
printNulls which is true by default, meaning that returning "null" is the default. Setting
printNulls to false ensures that expressions with "null" results are printed as an empty string, not the string "null."
WebLogic Server 8.1 installs both the Java Virtual Machine (JVM), JDK 1.4.1, and the JRockit JVM with the server installation. The
setenv.sh scripts provided with the server all point to the JDK 1.4.1 JVM. The latest information regarding certified JVMs is available at the Certifications Page. For information about upgrading to JRockit, see Upgrading Your JVM to JRockit.
The communication between the proxy Plug-In and WebLogic Server 5.1 is clear text. WebLogic Server 8.1 supports SSL communication between the plug-ins (Apache, Microsoft IIS, and Netscape) and the back-end WebLogic Server.
For more information about 8.1 proxy Plug-Ins, see Using Web Server Plug-Ins With WebLogic Server.
Default names for execute queues have changed in WebLogic Server 8.1. If you upgrade a configuration that specifies execute queues, the default queue names will automatically alias the new queue names.
weblogic.rmic, on any existing code to regenerate the wrapper classes so they are compatible with WebLogic Server 8.1.
java.rmi.Remoteto tag interfaces as remote. Do not use
import java.rmiRemoteException;). Do not use
weblogic.rmicto generate dynamic proxies and bytecode; with the exception of RMI IIOP, stubs and skeletons classes are no longer generated.
Note: For more information, see Using the WebLogic RMI Compiler in Programming WebLogic RMI.
weblogic.rmi.server.UnicastRemoteObject.exportObject()to get a stub instance.
java.rmi.*and JNDI in a future release.
Upgrading WebLogic Server 5.1 to WebLogic Server 8.1 with the WebLogic Server 8.1 security functionality is a two-step process involving first upgrading to the WebLogic Server 6.x security functionality and then upgrading from WebLogic Server 6.x to WebLogic Server 8.1.
See also the security section of the WebLogic Server Frequently Asked Questions.
In WebLogic 6.x, WebLogic Server provides a new management architecture for security realms. The management architecture implemented through MBeans allows you to manage security realms through the Administration Console. If you have a security realm from a previous release of WebLogic Server, use the following information to upgrade to the new architecture:
weblogic.propertiesoption under Information and Resources in the Administration Console to convert the security realm to the 6.1 architecture. Note that you can view users, groups, and ACLs in a Windows NT, UNIX, or LDAP security realm in the Administration Console. However, you still need to use the tools in the Windows NT, UNIX, or LDAP environments to manage users and groups.
\samples\server\src\examples\security\rdbmsrealmdirectory as a guide to converting your RDBMS security realm. Once you have converted your RDBMS security realm to MBeans, follow the instructions in Configuring the RDBMS Security Realm in the section called Specifying a Security Realm in the Administration Guide to define information about the JDBC driver being used to connect to the database and the schema used by the security realm.
WLPropertyRealmto the File realm. Realm attributes are now stored in the
fileRealm.propertiesfile instead of the
Once you have configured WebLogic Server to use the 6.1 security functionality, see Upgrading WebLogic Server 6.x to Version 8.1 to read about how to upgrade to the WebLogic Server 8.1 security functionality.
In the original domain provided with WebLogic Server 8.1, as well as in any domains that have been created using the
weblogic.properties file converter,
domain\applications\DefaultWebApp_myserver directory is created. This directory contains files made available by your Web server. You can place HTML and JSP files here and make them available, separate from any applications you install. If necessary, you can create subdirectories within the
DefaultWebApp_myserver directory to handle relative links, such as image files.
weblogic.propertiesfile contained in earlier versions.
weblogic.xml. This reorganization allows a third-party Web application based strictly on Servlet 2.3 to be deployed without modifications to its J2EE standard deployment descriptor (
web.xml). WebLogic Server 5.1 style settings made in the
<context-param>elements are supported for backward compatibility, but you should adopt the new way of deploying. The following sets of parameters previously defined in
web.xmlare now defined in
keepgenerated, precompile compileCommand, verbose, packagePrefix, pageCheckSeconds, encoding)
CookieDomain, CookieComment, CookieMaxAgeSecs, CookieName, CookiePath, CookiesEnabled, InvalidationIntervalSecs, PersistentStoreDir, PersistentStorePool, PersistentStoreType, SwapIntervalSecs, IDLength, CacheSize, TimeoutSecs, JDBConnectionTimeoutSecs, URLRewritingEnabled)
For more information, see Deploying Web Applications in Developing Web Applications for WebLogic Server.
To run a Wireless Application Protocol (WAP) application on WebLogic Server 8.1, you must now specify the MIME types associated with WAP in the
web.xml file of the Web application. In WebLogic Server 5.1, MIME types were defined in the
weblogic.properties file. For information on required MIME types see Programming WebLogic Server for Wireless Services. For information on creating and editing a
web.xml file, see web.xml Deployment Descriptor Elements in Developing Web Applications for WebLogic Server.
The built-in parser and transformer in WebLogic Server 8.1 have been updated to Xerces 1.4.4 and Xalan 2.2, respectively. If you used the APIs that correspond to older parsers and transformers that were shipped in previous versions of WebLogic Server, and if you used classes, interfaces, or methods that have been deprecated, you might receive deprecation messages in your applications .
WebLogic Server 8.1 also includes the WebLogic FastParser, a high-performance XML parser specifically designed for processing small to medium size documents, such as SOAP and WSDL files associated with WebLogic Web services. Configure WebLogic Server to use FastParser if your application handles mostly small to medium size (up to 10,000 elements) XML documents.
WebLogic Events are deprecated and should be replaced by JMS messages with NO_ACKNOWLEDGE or MULTICAST_NO_ACKNOWLEDGE delivery modes. See Non-transacted session in Programming WebLogic JMS for more information.
weblogic.deployis deprecated in this release of WebLogic Server 8.1 and is replaced by
weblogic.Deployer. For more information, see Deploying WebLogic Server Applications.
weblogic.refreshare both deprecated in this release of WebLogic Server 8.1. They have been replaced by
weblogic.httpd.servlet.reloadCheckSecs(has been replaced with the
weblogic.httpd.servlet.classpath(instead use the manifest classpath, or WEB-INF/lib or WEB-INF/classes, or virtual directories).
weblogic.httpd.clientCertProxy(not yet replaced in
weblogic.httpd.defaultServlet(instead define a
servlet-mappingwith pattern=/ in
For more information about
weblogic.xml, see weblogic.xml Deployment Descriptor Elements in Developing Web Applications for WebLogic Server.