Migrating WebLogic Server Applications to Version 6.0

 

The following sections describe a list of issues you need to consider when migrating your applications from WebLogic Server Version 4.5 or 5.1 to WebLogic Server Version 6.0. For a more detailed procedure, see the Migration Tutorial on BEA dev2dev. Where indicated, additional details are provided in the feature-specific documents:

• Java2 Enterprise Edition (J2EE)

• Converting weblogic.properties to .xml files

• Setting Up Your New Domain

• Migrating Applications

• Other J2EE Services

• Deprecated APIs and Features

• Removed APIs and Features

Java2 Enterprise Edition (J2EE)

The following sections discuss migration issues for each of the J2EE services. In conformance with the J2EE specification, WebLogic 6.0 deploys applications as one or more of the following types:

• Web Applications that may contain servlets, JSPs, and HTML

• EJB Applications containing Enterprise Java Beans

• Enterprise Applications containing a combination of EJB components and Web Application components

• Client Applications which are Java classes that connect to WebLogic Server using Remote Method Invocation (RMI)

Each of the above application types have their own deployment descriptors and directory format. If you are using legacy applications that were used with WebLogic Server 4.5 or WebLogic Server 5.1, you may need to make changes in order to migrate them successfully to WebLogic Server 6.0. This includes creating XML deployment descriptors and arranging resources according to a prescribed directory format. There is no longer a weblogic.properties file in WebLogic Server 6.0. The configuration of your applications is handled through the WebLogic Server Administration Console and configuration information is stored in an XML file.

The following sections contain information on converting your existing weblogic.properties files to the new XML format and converting your existing applications to the appropriate J2EE application type.

Converting weblogic.properties to .xml files

Earlier releases of WebLogic Server used a weblogic.properties file to configure applications. In WebLogic 6.0, configuration of applications is handled through XML descriptor files and the Administration Console. Converting a weblogic.properties file from an earlier version of WebLogic Server creates a new domain for your applications and adds .xml files that define how your applications are set up. Convert your weblogic.properties file to the appropriate .xml files by following these steps:

1. Start the default WebLogic Server 6.0 server and the default WebLogic 6.0 Administration Console. For information on starting WebLogic Server 6.0, see Post-Installation Tasks.

2. At the home page for the WebLogic Administration Console (for example: http://localhost:7001/console/index.jsp) click on the Convert weblogic.properties link under the heading Getting Started.

3. Use the links to navigate the server's file system and find the root of your previous version of WebLogic Server (For example: C:/weblogic). When you have found the correct directory, click on the icon next to it to select it.

4. If you have additional per server weblogic.properties files or clustering weblogic.properties files select them using the provided windows. If you have chosen the correct root directory, your global weblogic.properties file will be converted regardless of any additional properties files that you select.

5. Select a name for your new domain. When you have chosen a new name for your domain, click Convert.

Throughout this document, the directory of the new domain you have created is referred to as domainName. The default domain that is provided with the original installation of WebLogic Server 6.0 is called mydomain and is located in the wlserver6.0/config/ directory. It is necessary to set up your new domain before migrating any applications.

WebLogic Properties Mapping

The weblogic.properties file is no longer supported. Earlier releases of WebLogic Server used a weblogic.properties file to configure applications. In WebLogic Server 6.1, configuration of applications is handled through XML descriptor files and the Administration Console. If the attribute can be configured in the Administration Console, the table shows the navigation path to the attribute

The table below shows which config.xml attribute handles the function formerly performed by which weblogic.properties property. weblogic.properties Mapping Table

"weblogic.properties" file Property	Configuration Attribute	Console Navigation
weblogic.administrator.email	config.xml: EmailAddress (Administrator element)
weblogic.administrator.location	config.xml: Notes (freeform, optional) (Administrator element)999
weblogic.administrator.name	config.xml: Name (Administrator element)
weblogic.administrator.phone	config.xml: PhoneNumber (Administrator element)
weblogic.cluster.defaultLoadAlgorithm	config.xml: DefaultLoadAlgorithm (Cluster element)	Cluster: General: Default Load Algorithm
weblogic.cluster.multicastAddress	config.xml: MulticastAddress (Cluster element)	Cluster: General: Multicast Address
weblogic.cluster.multicastTTL	config.xml: MulticastTTL (Cluster element)	Cluster: Multicast: MulticastTTL
weblogic.cluster.name	config.xml ClusterAddress (Cluster element)	Cluster:General: Name
weblogic.httpd.authRealmName	config.xml: AuthRealmName (WebAppComponent element)
weblogic.httpd.charsets	config.xml: Charsets (WebServer element)
weblogic.httpd.clustering.enable	config.xml: ClusteringEnabled (WebServer element)
weblogic.httpd.defaultServerName	config.xml DefaultServerName (WebServer element)
weblogic.httpd.defaultWebApp	config.xml: DefaultWebApp (WebServer element)
weblogic.httpd.enable	config.xml: HttpdEnabled (Server element)
weblogic.httpd.enableLogFile	config.xml: LoggingEnabled (WebServer element)
weblogic.httpd.http.keepAliveSecs	config.xml: KeepAliveSecs (WebServer element)
weblogic.httpd.https.keepAliveSecs	config.xml: HttpsKeepAliveSecs (WebServer element)
weblogic.httpd.indexDirectories	config.xml: IndexDirectoryEnabled (WebAppComponent element)
weblogic.httpd.keepAlive.enable	config.xml: KeepAliveEnabled (WebServer element)
weblogic.httpd.logFileBufferKBytes	config.xml: LogFileBufferKBytes (WebServer element)
weblogic.httpd.logFileFlushSecs	config.xml: LogFileFlushSecs (WebServer element)
weblogic.httpd.logFileFormat	config.xml: LogFileFormat (WebServer element)
weblogic.httpd.logFileName	config.xml: LogFileName (WebServer element)
weblogic.httpd.logRotationPeriodMins	config.xml: LogRotationTimeBegin (WebServer element)
weblogic.httpd.logRotationPeriodMins	config.xml: LogRotationPeriodMins (WebServer element)
weblogic.httpd.logRotationType	config.xml: LogRotationType (WebServer element)
weblogic.httpd.maxLogFileSizeKBytes	config.xml: MaxLogFileSizeKBytes (WebServer element)
weblogic.httpd.mimeType	web.xml: mime-type <mime-mapping> element
weblogic.httpd.postTimeoutSecs	config.xml: PostTimeoutSecs (WebServer element)
weblogic.httpd.servlet.extensionCaseSensitive	config.xml: ServletExtensionCaseSensitive (WebAppComponent element)
weblogic.httpd.servlet.reloadCheckSecs	config.xml: ServletReloadCheckSecs (WebAppComponent element)
weblogic.httpd.servlet.SingleThreadedModelPoolSize	config.xml: SingleThreadedServletPoolSize (WebAppComponent element)
weblogic.httpd.session.cacheEntries	weblogic.xml: CacheSize <param-name>/<param-value> element pair
weblogic.httpd.session.cookie.comment	weblogic.xml: CookieComment <param-name>/<param-value> element pair
weblogic.httpd.session.cookie.domain	weblogic.xml: CookieDomain <param-name>/<param-value> element pair
weblogic.httpd.session.cookie.maxAgeSecs	weblogic.xml: CookieMaxAgeSecs <param-name>/<param-value> element pair
weblogic.httpd.session.cookie.name	weblogic.xml: CookieName <param-name>/<param-value> element pair
weblogic.httpd.session.cookie.path	weblogic.xml: CookiePath <param-name>/<param-value> element pair
weblogic.httpd.session.cookies.enable	weblogic.xml: CookiesEnabled <param-name>/<param-value> element pair
weblogic.httpd.session.debug	weblogic.xml: SessionDebuggable<param-name>/<param-value> element pair
weblogic.httpd.session.enable	weblogic.xml: SessionTrackingEnabled <param-name>/<param-value> element pair
weblogic.httpd.session.invalidationintervalSecs	weblogic.xml: InvalidationIntervalSecs <param-name>/<param-value> element pair
weblogic.httpd.session.jdbc.connTimeoutSecs	weblogic.xml: JDBCConnectionTimeoutSecs <param-name>/<param-value> element pair
weblogic.httpd.session.persistentStoreDir	weblogic.xml: PersistentStoreDir <param-name>/<param-value> element pair
weblogic.httpd.session.persistentStorePool	weblogic.xml: PersistentStorePool <param-name>/<param-value> element pair
weblogic.httpd.session.persistentStoreShared	weblogic.xml: SessionPersistentStoreShared <param-name>/<param-value> element pair
weblogic.httpd.session.persistentStoreType	weblogic.xml: PersistentStoreType <param-name>/<param-value> element pair
weblogic.httpd.session.sessionIDLength	weblogic.xml: IDLength <param-name>/<param-value> element pair
weblogic.httpd.session.swapintervalSecs	weblogic.xml: SwapIntervalSecs <param-name>/<param-value> element pair
weblogic.httpd.session.timeoutSecs	weblogic.xml: TimeoutSecs<param-name>/<param-value> element pair
weblogic.httpd.session.URLRewriting.enable	weblogic.xml: URLRewritingEnabled <param-name>/<param-value> element pair
weblogic.httpd.tunneling.clientPingSecs	config.xml: TunnelingClientPingSecs (Server element)	Servers: Tuning: Tunneling Client Ping
weblogic.httpd.tunneling.clientTimeoutSecs	config.xml: TunnelingClientTimeoutSecs (Server element)	Servers: Tuning: Tunneling Client Timeout
weblogic.httpd.tunnelingenabled	config.xml TunnelingEnabled (Server element)	Servers: Tuning: Enable Tuneling
weblogic.httpd.URLResource	config.xml: URLResource (WebServer element)
weblogic.iiop.password	config.xml: DefaultIIOPPassword (Server element)	Servers: servername: Configuration: Protocols: Default IIOPPassword
weblogic.iiop.user	config.xml: DefaultIIOPUser (Server element)	Servers: servername: Configuration:Protocols: Default IIOPUser
weblogic.jdbc.connectionPool url=URL for JDBC Driver driver=full package name for JDBC driver loginDelaySecs=seconds between connections initialCapacity=initial number of JDBC connections maxCapacity=maximum number of JDBC connections capacityIncrement=increment interval allowShrinking=true to allow shrinking shrinkPeriodMins=interval before shrinking testTable=name of table for autorefresh test refreshTestMinutes=interval for autorefresh test testConnsOnReserve=true to test connection at reserve testConnsOnRelease=true to test connection at release props=props for JDBC connection	config.xml JDBCConnectionPool Element ConnLeakProfilingEnabled ACLName URL DriverName Properties LoginDelaySeconds InitialCapacity MaxCapacity CapacityIncrement CapacityEnabled ShrinkPeriodMinutes RefreshMinutes TestTableName TestConnectionsOnRelease SupportsLocalTransaction KeepLogicalConnOpenOnRelease Password
weblogic.jdbc.enableLogFile	config.xml: JDBCLoggingEnabled (Server element)
weblogic.jdbc.logFileName	config.xml: JDBCLogFileName (Server element)
weblogic.jms.ConnectionConsumer	config.xml JMSConnectionConsumer element MessagesMaximum Selector Destination	Services: JMS
weblogic.jms.connectionFactoryArgs.<<factoryName>> ClientID DeliveryMode TransactionTimeout	config.xml: JMSConnectionFactory element ClientID DefaultDeliveryMode TransactionTimeout UserTransactionsEnabled AllowCloseInOnMessage	Services: JMS: Connection Factories
weblogic.jms.connectionFactoryName	config.xml: JMSConnectionFactory element JNDIName	Services: JMS: Connection Factories
weblogic.jms.connectionPool	ConnectionPool (JMSJDBCStore element)	Services: JMS: JMSJDBCStores
weblogic.jms.queue	config.xml: JNDIName StoreEnabled (JMSDestination element)	Services: JMS:Connection Factories
weblogic.jms.queueSessionPool	config.xml: ConnectionConsumer ConnectionFactory ListenerClass AcknowledgeMode SessionsMaximum Transacted (JMSSessionPool element)	Services: JMS: Servers: Session Pools
weblogic.jms.tableNamePrefix	config.xml: PrefixName
weblogic.jms.topic	config.xml JNDIName StoreEnabled (JMSDestination element)	Services: JMS: Servers: JMSServer-0: Destinations: JMS Queus, JMS Topics
weblogic.jms.topicSessionPool	config.xml: ConnectionConsumer ConnectionFactory ListenerClass AcknowledgeMode SessionsMaximum Transacted (JMSSessionPool element)	Services: JMS: Servers: JMSServer-0: JMS Session Pools
weblogic.jndi.transportableObjectFactories	config.xml: JNDITransportableObjectFactoryList (Server element)
weblogic.login.readTimeoutMillisSSL	config.xml LoginTimeoutMillis (SSL element)
weblogic.security.audit.provider	config.xml AuditProviderClassName (Security element)	Security: Audit Provider Class
weblogic.security.certificate.authority	config.xml ServerCertificateChainFileName (SSL element)
weblogic.security.certificate.server	config.xml: ServerCertificateFileName (SSL element)
weblogic.security.certificateCacheSize	config.xml: CertificateCacheSize (SSL element)
weblogic.security.clientRootCA	config.xml: TrustedCAFileName (SSL element)
weblogic.security.disableGuest	config.xml: GuestDisabled (Security element)	Security: Guest Disabled
weblogic.security.enforceClientCert	config.xml: ClientCertificateEnforced (SSL element)
weblogic.security.key.export.lifespan	config.xml: ExportKeyLifespan (SSL element)
weblogic.security.key.server	config.xml: ServerKeyFileName (SSL element)
weblogic.security.ldaprealm.authentication	config.xml: AuthProtocol (LDAPRealm element)
weblogic.security.ldaprealm.credential	config.xml: Credential (LDAPRealm element)
weblogic.security.ldaprealm.factory	config.xml LdapProvider (LDAPRealm element)
weblogic.security.ldaprealm.groupDN	config.xml: GroupDN (LDAPRealm element)
weblogic.security.ldaprealm.groupIsContext	config.xml: GroupIsContext (LDAPRealm element)
weblogic.security.ldaprealm.groupNameAttribute	config.xml: GroupNameAttribute (LDAP Realm element)
weblogic.security.ldaprealm.groupUsernameAttribute	config.xml: GroupUsernameAttribute (LDAPRealm element)
weblogic.security.ldaprealm.principal	config.xml: Principal (LDAPRealm element)
weblogic.security.ldaprealm.ssl	config.xml: SSLEnable (LDAPRealm element)
weblogic.security.ldaprealm.url	config.xml: LDAPURL (LDAPRealm element)
weblogic.security.ldaprealm.userAuthentication	config.xml: UserAuthentication (LDAPRealm element)
weblogic.security.ldaprealm.userDN	config.xml: UserDN (LDAPRealm element)
weblogic.security.ldaprealm.userNameAttribute	config.xml: UserNameAttribute (LDAPRealm element)
weblogic.security.ldaprealm.userPasswordAttribute	config.xml: UserPasswordAttribute (LDAPRealm element)
weblogic.security.net.connectionFilter	config.xml: ConnectionFilter (Security element)
weblogic.security.ntrealm.domain	config.xml: PrimaryDomain (NTRealm element)
weblogic.security.realm.cache.acl.enable	config.xml: ACLCacheEnable (CachingRealm element)
weblogic.security.realm.cache.acl.size	config.xml: ACLCacheSize (CachingRealm element)
weblogic.security.realm.cache.acl.ttl.negative	config.xml: ACLCacheTTLNegative (CachingRealm element)
weblogic.security.realm.cache.acl.ttl.positive	config.xml: ACLCacheTTLPositive (CachingRealm element)
weblogic.security.realm.cache.auth.enable	config.xml: AuthenticationCacheEnable (CachingRealm element)
weblogic.security.realm.cache.auth.size	config.xml: AuthenticationCacheSize (CachingRealm element)
weblogic.security.realm.cache.auth.ttl.negative	config.xml: AuthenticationCacheTTLNegative (CachingRealm element)
weblogic.security.realm.cache.auth.ttl.positive	config.xml: AuthenticationCacheTTLPositive (CachingRealm element)
weblogic.security.realm.cache.caseSensitive	config.xml: CacheCaseSensitive(CachingRealm element)
weblogic.security.realm.cache.group.enable	config.xml: GroupCacheEnable (CachingRealm element)
weblogic.security.realm.cache.group.size	config.xml: GroupCacheSize (CachingRealm element)
weblogic.security.realm.cache.group.ttl.negative	config.xml: GroupCacheTTLNegative (CachingRealm element)
weblogic.security.realm.cache.group.ttl.positive	config.xml: GroupCacheTTLPositive (CachingRealm element)
weblogic.security.realm.cache.perm.enable	config.xml: PermissionCacheEnable (CachingRealm element)
weblogic.security.realm.cache.perm.size	config.xml: PermissionCacheSize (CachingRealm element)
weblogic.security.realm.cache.perm.ttl.negative	config.xml: PermissionCacheTTLNegative (CachingRealm element)
weblogic.security.realm.cache.perm.ttl.positive	config.xml: PermissionCacheTTLPositive (CachingRealm element)
weblogic.security.realm.cache.user.enable	config.xml: UserCacheEnable (CachingRealm element)
weblogic.security.realm.cache.user.size	config.xml: UserCacheSize (CachingRealm element)
weblogic.security.realm.cache.user.ttl.negative	config.xml: UserCacheTTLNegative (CachingRealm element)
weblogic.security.realm.cache.user.ttl.positive	config.xml: UserCacheTTLPositive (CachingRealm element)
weblogic.security.realm.certAuthenticator	config.xml: CertAuthenticator (SSL element)
weblogic.security.SSL.ciphersuite	config.xml Ciphersuites (SSL element)
weblogic.security.ssl.enable	config.xml: Enabled (SSL element)
weblogic.security.SSL.hostnameVerifier	config.xml HostnameVerifier (SSL element)
weblogic.security.SSLHandler.enable	config.xml: HandlerEnabled (SSL element)
weblogic.security.unixrealm.authProgram	config.xml: AuthProgram (UnixRealm element)
weblogic.system.AdministrationPort	config.xml AdministrationPort (Server element)
weblogic.system.AdministrationPort	config.xml: AdministrationPort (Server element)
weblogic.system.bindAddr	config.xml: ListenAddress (Server element)
weblogic.system.defaultProtocol	config.xml: DefaultProtocol (Server element)
weblogic.system.defaultSecureProtocol	config.xml: DefaultSecureProtocol (Server element)
weblogic.system.enableConsole	config.xml: StdoutEnabled (Kernel element)
weblogic.system.enableIIOP	config.xml: IIOPEnabled (Server element)
weblogic.system.enableReverseDNSLookups	config.xml: ReverseDNSAllowed (Server element)
weblogic.system.enableSetGID	config.xml: PostBindGIDEnabled (UnixMachine element)
weblogic.system.enableSetUID	config.xml: PostBindUIDEnabled (UnixMachine element)
weblogic.system.enableTGIOP	config.xml TGIOPEnabled (Server element)
weblogic.system.helpPageURL	config.xml HelpPageURL (Server element)
weblogic.system.home	config.xml: RootDirectory (Server element)
weblogic.system.ListenPort	config.xml ListenPort (Server element)
weblogic.system.logFile	config.xml: FileName (Log element)
weblogic.system.MagicThreadBackToSocket	config.xml: MagicThreadDumpBackToSocket (ServerDebug element)
weblogic.system.MagicThreadDumpFile	config.xml: MagicThreadDumpFile (ServerDebug element)
weblogic.system.MagicThreadDumpHost	config.xml: MagicThreadDumpHost (ServerDebug element)
weblogic.system.magicThreadDumps	config.xml: MagicThreadDumpEnabled (ServerDebug element)
weblogic.system.maxLogFileSize	config.xml: FileMinxSize (Log element)
weblogic.system.nativeIO.enable	config.xml: NativeIOEnabled (Server element)
weblogic.system.nonPrivGroup	config.xml PostBindGID (UnixMachine element)
weblogic.system.nonPrivUser	config.xml PostBindUID (UnixMachine element)
weblogic.system.percentSocketReaders	config.xml: ThreadPoolPercentSocketReaders (Kernel element)
weblogic.system.readTimeoutMillis	config.xml LoginTimeoutMillis (Server element)
weblogic.system.readTimeoutMillis	config.xml: LoginTimeoutMillis (Server element)
weblogic.system.SSL.useJava	config.xml: UseJava (SSL element)
weblogic.system.SSLListenPort	config.xml: ListenPort (SSL element)
weblogic.system.startupFailureIsFatal	config.xml FailureIsFatal (StartupClass element)
weblogic.system.user	config.xml: SystemUser (Security element)	Security: Users
weblogic.system.weight	config.xml ClusterWeight (Server element)	Server: servername: Cluster: Cluster Weight
weblogic.workspace.showUserKeysOnly	config.xml: WorkspaceShowUserKeysOnly (Server element)
weblogic.zac.enable	config.xml: ZACEnabled (Server element)
weblogic.zac.publishRootProp	config.xml: ZACPublishRoot (Server element)

Setting Up Your New Domain

A domain is an interrelated collection of WebLogic Server resources and configuration files that occupy a single specific namespace. Only one domain can be active at a time. For more information on domains, see Domains, the Administration Server and Managed Servers. To use your new domain you must start your server with the correct domain and copy the WebLogic Server Administration Console into the appropriate location. The WebLogic Server Administration Console is a sophisticated Web Application and an essential tool in managing your server.

Restarting the Server

In order to use your new domain you must restart the server, specifying before startup your new domain name. To do so, startup scripts have been provided. These scripts, which are generated when a weblogic.property file is converted, are named startdomainName.cmd (for Windows users) and startdomainName.sh (for UNIX users) and exist under the wlserver6.0/config/domainName directory. These scripts will start the server in the new domain.

These startup scripts make it easier to start instances of WebLogic Server. You may need to modify them to fit your environment and applications. See Starting and Stopping the WebLogic Server for more information on scripts and starting servers. More information is also available in the Administrator's Guide, under Migrating from Earlier Versions of WebLogic Server.

Copying the Administration Console to Your New Domain

Before restarting your server, it is also necessary to copy the Adminstration Console Web Application into the newly created domain. The Administration Console is a Web Application with its own .war file and can be treated as any other Web Application.

To copy it into your new domain, follow these steps:

1. After converting your properties file, shut down the server by closing the window where the server is running.

2. Navigate to wlserver6.0/config/mydomain/applications.

3. Copy the console.war file.

4. Proceed to wlserver6.0/config/domainName/applications

5. Place the copy of console.war inside the new wlserver6.0/config/domainName/applications directory.

6. Restart your server and refresh the browser window that contains your console.

At the top middle of the main console window as well as the top of the left hand pane, you should see your new domain displayed as the active domain. Now you can begin to migrate your applications.

Migrating Applications

Applications on a J2EE-compliant server such as WebLogic Server 6.0 are created and deployed as one of the following four types: Web Applications, Enterprise JavaBeans, Enterprise Archives, and Client Applications. To migrate your existing components to WebLogic Server 6.0, create the appropriate J2EE deployment units. Web Applications are usually a collection of servlets, JSPs, and HTML files. Enterprise JavaBeans are server-side Java components written according to the EJB specification. Enterprise Archives may contain a combination of EJB components and Web Application components. Client Applications are Java classes that connect to WebLogic Server using Remote Method Invocation (RMI). Each of the aforementioned J2EE deployment units are discussed in greater detail within the following sections.

Web Applications

A Web Application is created by correctly packaging into a single unit the servlets, JSPs and HTML pages that make up an application.

In order to deploy an application as a Web Application it is necessary to create certain .xml files that contain configuration information on that application. If you have converted your properties file, these .xml files (web.xml and weblogic.xml) have been created for you and placed inside a wlserver6.0/config/domainName/applications/DefaultWebApp_myserver/WEB-INF directory. The process of converting your weblogic.properties file also creates the config.xml file located in wlserver6.0/config/domainName/. This file contains configuration information specific to your server.

In order to migrate applications into a Web Application deployed on WebLogic Server 6.0, the files of your application must be placed within a directory structure that follows a specific pattern. For development, these files can be left in an exploded directory format. However, for production situations, it is highly recommended that you bundle your applications into the appropriate .war file as a singular Web Application. For more information on Web Applications see Understanding WebLogic Server Applications and Deploying and Configuring Web Applications.

Directory Structure

Web Applications are organized within a specified directory structure so that they can be archived and deployed on WebLogic Server. All servlets, classes, static files, and other resources belonging to a Web Application are organized under a directory hierarchy. The root of this hierarchy defines the document root of your Web Application. All files under this root directory can be served to the client, except for files under the special directories WEB-INF and META-INF located in the root directory. The root directory should be named with the name of your Web Application and placed inside the wlserver6.0/config/domainName/applications directory.

The following diagram illustrates the directory structure of any Web Application.

WebApplicationRoot/(Publically available files such as
                    |  .jsp, .html, .jpg, .gif)
                    | 
                    +WEB-INF/-+
                              |
                              + classes/(directory containing
                              |         Java classes including
                              |         servlets used by the
                              |         Web Application)
                              |
                              + lib/(directory containing
                              |       jar files used by the
                              |       Web Application)
                              |
                              + web.xml 
                              |
                              + weblogic.xml

If you have already converted your properties file, the appropriate web.xml and weblogic.xml files have already been created for you under the directory wlserver6.0/config/domainName/applications/DefaultWebApp_myserver/WEB-INF. Follow the above directory structure and place the .xml files in the wlserver6.0/config/domainName/applications/webAppName/WEB-INF directory that you create. All applications must be placed inside a wlserver6.0/config/domainName/applications directory in order to be deployed. For more information see Developing WebLogic Server Applications.

XML Deployment Descriptors

The Web Application Deployment Descriptor (web.xml) is a standard J2EE descriptor used to register your servlets, define servlet initialization parameters, register JSP tag libraries, define security constraints, and other Web Application parameters. For detailed instructions on creating the deployment descriptor, see Writing the Web Application Deployment Descriptor.

There is also a WebLogic-specific 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 Writing the WebLogic-specific Deployment Descriptor. This file may not be required if you have no need for any of the above mentioned properties, mappings, or parameters.

If you have converted your weblogic.properties file, a web.xml and weblogic.xml file have already been created for you. Use the web.xml and weblogic.xml files, in conjunction with the 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 web.xml or weblogic.xml with the appropriate path as specified by the prescribed directory structure. See Configuring your Web Applications 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.

WAR Files

A .war file is a Web Application archive. If you have correctly followed the prescribed directory structure of a Web Application and created the appropriate web.xml and weblogic.xml files, it is strongly recommended that in production environments your applications are bundled together in a Web Application deployed as a .war file. Once you have done so, it is important to remove the previously existing directory structure so that WebLogic Server only has one instance of each application.

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:

jar cvf webAppName.war *

You now have created a .war file that contains all the files and configuration information for your Web Application.

Deploying Web Applications

To deploy your bundled Web Applications properly, place the appropriate .war file in the c:/wlserver6.0/config/domainName/applications directory. You can also install the application through the Administration Console. To do so, go to the console home and choose Install Applications under the Getting Started menu. Select the correct .war file and it will be installed automatically. Note that it is necessary to have your applications reside in a c:/wlserver6.0/config/domainName/applications directory in order for them to work.

Web Applications should be deployed automatically after they have been installed. Check to see that they are deployed under the Deployments node in the left hand pane of the Administration Console.

You can configure certain deployment attributes for your Web Application using the Administration Console. Select the Web Applications node under the Deployments heading. Select your Web Application. Click on the appropriate tab to configure. For more information on setting attributes in the console, see the Web Application section of the Console Help.

JavaServer Pages (JSP) and Servlets

This section contains information specific to JSPs and servlets that may be pertinent to your applications.

• Some changes will be necessary in code (both Java and HTML) where the code refers to URLs, which may be different when servlets and JSPs are deployed in a Web Application that is not the default Web Application. See the Servlet Documentation for more information. If relative URLs are used and all components are contained in the same Web Application, these changes are not necessary.

• Only serializable objects may be stored in a session if your application is intended to be distributable.

• You must convert your weblogic.properties to XML attributes in web.xml and/or weblogic.xml. For additional information on this process, see the conversion section of the Console Help.

• ACLs are now defined as security constraints in web.xml.

• Server-Side-Includes are not supported. You must use JSP to achieve this functionality.

• This version of WebLogic Server is now fully compliant with the Servlet 2.2 specification.

Example Steps to Migrate a Simple Servlet

The following procedure migrates the simple Hello World Servlet that was provided with WebLogic 5.1 Server to WebLogic Server 6.0.

1. Create the correct directory structure, as described in Programming HTTP Servlets. This involves creating a root application directory, such as C:/hello, as well as a C:/hello/WEB-INF directory and a C:/hello/WEB-INF/classes directory. Place the HelloWorld.Servlet.java file inside the C:/hello/WEB-INF/classes directory.

2. Create a web.xml file for this servlet. If you have converted your weblogic.properties file, a web.xml file has already been created for you. If you registered HelloWorldServlet in your weblogic.properties file, it will be properly configured in your new web.xml file. An .xml file can be created with any text editor. The following is an example of a basic web.xml file that could be used with the HelloWorldServlet.

   <!DOCTYPE web-app (View Source for full doctype...)> 
   - <web-app> 
   - <servlet> 
   <servlet-name>HelloWorldServlet</servlet-name> 
   <servlet-class>examples.servlets.HelloWorldServlet</servlet-class> 
   </servlet> 
   - <servlet-mapping> 
   <servlet-name>HelloWorldServlet</servlet-name> 
   <url-pattern>/hello/*</url-pattern> 
   </servlet-mapping> 
   </web-app>

   For more information on web.xml files, see Writing the Web Application Deployment Descriptor. A weblogic.xml file is not necessary with such a simple, stand-alone servlet as HelloWorld.

   For more information on weblogic.xml files, see Writing the WebLogic-Specific Deployment Descriptor. If you registered the HelloWorldServlet in Weblogic 5.1 and have converted your weblogic.properties file into .xml, simply move the web.xml file from wlserver6.0/config/domainName/applications/DefaultWebApp_myserver/WEB-INF to C:/hello/WEB-INF/. If you did not convert your weblogic.properties file, or did not register the HelloWorldServlet in your earlier version of WebLogic, create a web.xml file like the above example and place it inside the C:/hello/WEB-INF/ directory.

3. Set up your development environment (see Establishing a Development Environment for more information) and compile the HelloWorldServlet with a command like the following:

   C:\hello\WEB-INF\classes>javac -d  . HelloWorldServlet.java

   This should compile the file and create the correct package structure.

4. The servlet can now be bundled into an archive .war file with the following command:

   jar cvf hello.war *

   This command will create a hello.war file and place it inside the C:/hello directory.

5. To install this Web Application, start your server and open the Administration Console. Under the Getting Started menu, choose Install Applications. Browse to the newly created .war file and click Upload. The servlet should now be deployed and appear under the Web Applications node under Deployments, in the left-hand pane of the console.

6. To call the servlet, type the following in your browser URL window: http://localhost:7001/hello/hello. 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 the servlet mapping tags inside the web.xml file.

Enterprise JavaBeans Applications

To migrate a 1.1 EJB from your WebLogic Server 5.1 installation to WebLogic Server 6.0, first open the Administration Console. From the home page click on Install Applications under the Getting Started heading. Locate the .jar file you wish to install by clicking the Browse button. Once you have located it, click Open and then Upload. Your bean should now be automatically deployed.

To check your output, run a setEnv script on a client window and set your development environment (for more information see Establishing a Development Environment). Then compile all the needed client classes. For example, using the Stateless Session Bean sample that was provided with WebLogic Server 5.1, you would use the following command:

javac -d %CLIENTCLASSES% Trader.java TraderHome.java TradeResult.java Client.java

Then reference the EJB interfaces in your client's classpath:

java -classpath %CLIENTCLASSES%;%CLASSPATH% examples.ejb.basic.statelessSession.Client

To run the client, enter this command:

java examples.ejb.basic.statelessSession.Client

In order to convert an EJB 1.1 bean to a EJB 2.0 bean, WebLogic provides a DDConverter. It is recommended that you develop EJB 2.0 beans in conjunction with WebLogic server 6.0. However, 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 6.0. If you do wish to convert 1.1 beans to 2.0 beans, see the DDConverter documentation for more information.

The basic steps required to convert a simple CMP 1.1 bean to a 2.0 bean are as follows:

1. Make the bean class abstract. EJB 1.1 beans declare CMP fields in the bean. CMP 2.0 beans use abstract getXXX and setXXX methods for each field. For instance, 1.1 Beans will use public String name. 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 setName method.

2. Any CMP 1.1 finder which used java.util.Enumeration should now use java.util.Collection. Change your code to reflect this. CMP 2.0 finders cannot return java.util.Enumeration.

The following list includes further information that may be pertinent to users migrating their Enterprise JavaBeans to use WebLogic Server 6.0.

• WebLogic Server Version 6.0 supports the Enterprise JavaBeans 1.1 and 2.0 specifications.

• The XML parser is stricter with XML deployment descriptors in WebLogic 6.0. Some errors allowed in earlier versions are no longer permitted. This is described in Programming WebLogic EJB.

• EJB 1.1 beans are deployable in WebLogic Server 6.0. However, if you are developing new beans, it is recommended that you use EJB 2.0. EJB 1.1 beans can be converted to 2.0 using the DDConverter utility. For more information see the DDConverter.

• EJB 1.0 deployment descriptors can be upgraded to EJB 2.0 using the DDConverter utility also, but first must be upgraded to 1.1 beans. WebLogic Server 5.1 deployment descriptors may be upgraded to 6.0 to take advantage of WebLogic Server 6.0's new features. Details on the DDConverter utility are provided in Programming WebLogic EJB.

• The finder expressions feature of EJB 1.1 is no longer supported. This is the only non-supported feature of EJB 1.1.

• The weblogic.deploy utility is no longer supported. Deploying beans is described in Programming WebLogic EJB.

• If ejbc has not been run on an EJB, WebLogic Server 6.0 will run ejbc automatically when the bean is deployed. You do not need to compile beans with ejbc before deploying. If you wish to run ejbc during startup, you may do so. See details in Programming WebLogic EJB.

For more information on Enterprise JavaBeans, see Enterprise JavaBeans Components and Programming WebLogic EJB.

Enterprise Applications

An Enterprise Application consists of assembled components, and is a .jar file with an .ear extension. An .ear file contains all of the .jar and .war component archive files for an application and an XML descriptor that describes the bundled components. The META-INF/application.xml deployment descriptor contains an entry for each Web and EJB module, and additional entries to describe security roles and application resources such as databases.

EnterpriseApplicationStagingDirectory/
                                     |
                                     + .jar files
                                     |
                                     + .war files
                                     |
                                     +META-INF/-+
                                                |
                                                + application.xml
                                             

When you have assembled all of the Web Archive and EJB Archives for your application and placed them under your staging directory, you can bundle them together in an Enterprise Archive (.ear) file so that you can deploy all of the dependent components together. Copy the .war and EJB .jar files into the staging directory and then create a META-INF/application.xml deployment descriptor for the application. Follow the directory structure depicted above. The application.xml file contains a descriptor for each component in the application, using a DTD supplied by Sun Microsystems. For more information on the application.xml file, see Client Application Deployment Descriptor Elements. Note that if you are using JSPs and want them to compile at run time you must have the home and remote interfaces of the bean included in the classes directory of your .war file.

Create the Enterprise Archive by executing a jar command like the following in the staging directory:

jar cvf myApp.ear *

The .ear file can be installed through the console by clicking on the Install Applications link under the Getting Started heading in the home page of the console. The .ear file needs to be in the c:/wlserver6.0/config/domainName/applications directory. For more information on Enterprise Applications, see Staging Enterprise Applications.

Client Applications

WebLogic Server also supports J2EE client applications, packaged in a jar file with a standard XML deployment descriptor. Client applications (meaning: when the client is not a Web browser) are Java classes that connect to WebLogic Server using Remote Method Invocation (RMI). A Java client can access Enterprise JavaBeans, JDBC connections, JMS messaging, and other services using RMI. Client applications range from simple command line utilities that use standard I/O to highly interactive GUI applications built using the Java Swing/AWT classes.

To execute a WebLogic Server Java client, the client computer needs the weblogic_sp.jar file, the weblogic.jar file, the remote interfaces for any RMI classes and Enterprise Beans that are on WebLogic Server, as well as the client application classes. To simplify maintenance and deployment, it is a good idea to package a client-side application in a jar file that can be added to the client's classpath along with the weblogic.jar and weblogic_sp.jar files. The weblogic.ClientDeployer command line utility is executed on the client computer to run a client application packaged to this specification. For more information about J2EE client applications, see Staging and Deploying Client Applications.

Standalone HTML and JSP PAGES

In the original domain provided with WebLogic Server 6.0, as well as in any domains that have been created using the weblogic.properties file converter, there is a wlserver6.0/config/domainName/applications/DefaultWebApp_myserver directory that has been created. This directory can be used to contain files made available by your web server. HTML and JSP files may be placed here and be made 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.

Applications and Managed Servers

By default, applications are deployed on the administration server's config.xml block and JVM. However, in most cases, this is not good practice. The administration server should just be used for administrative purposes. Users should define new managed servers and associate the applications with those servers. This is done via the Administration Console. For more information, see Configuring WebLogic Servers and Clusters and Domains, the Administration Server, and Managed Servers.

Other J2EE Services

What follows is a list of different components that can be used by applications. Deprecated features, upgrades, and the important changes that have been made in WebLogic Server 6.0 are noted.

Java Transaction API (JTA)

The following changes in JTA have taken place:

• WebLogic Server 6.0 supports the JTA 1.0.1 specification. Updated JTA documentation is provided in Programming WebLogic JTA.

• Based on the inclusion of support for JTA, the JTS JDBC driver (with properties in weblogic.jts.* and URL 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.

Java Message Service (JMS)

For specific details on migrating JMS, see Migrating WebLogic JMS Applications in Programming WebLogic JMS.

WebLogic Server 6.0 supports the JavaSoft JMS specification version 1.0.2. In order to use your existing JMS applications, perform the following steps:

1. Upgrade the WebLogic Server environment, as described in the Installation Guide.

2. Migrate configuration information using the Configuration Conversion Facility . Once your configuration information is converted, the JMS administrator needs to review the resulting configuration to ensure that the conversion meets the needs of the application, and adjust the values, if necessary.

3. Prepare for automatic migration of existing JDBC database stores, as described in Migrating WebLogic JMS Applications in Programming WebLogic JMS.

   In WebLogic Server 5.1, the WebLogic JMS data for JMS messages and durable subscribers was kept in five database tables that were accessible via JDBC. In WebLogic Server 6.0, JMS queues are defined during configuration, and no longer saved within database tables. Message data and durable subscriptions are stored either in two JDBC tables or via a directory within the file system. The current JDBC database store content format is not compatible with the format in WebLogic Server 6.0 Beta.

4. Update any existing code, as required, to reflect the feature functionality changes described in Migrating WebLogic JMS Applications in Programming WebLogic JMS. For example, the createQueue() and createTopic() methods do not create destinations dynamically, only references to destinations that already exist given the vendor-specific destination name.

5. When you initially boot up the WebLogic Server, the existing JDBC database stores will be migrated automatically. If the automatic migration fails for any reason, the automatic migration will be re-attempted the next time the WebLogic Server boots.

For more information on migrating your WebLogic JMS applications, see Migrating WebLogic JMS Applications in Programming WebLogic JMS. Note that WebLogic Events are being deprecated and being replaced by JMS messages with NO_ACKNOWLEDGE or MULTICAST_NO_ACKNOWLEDGE delivery modes. Each of these delivery modes is described in Programming WebLogic JMS.

Java Database Connectivity (JDBC)

The following changes have been made in JDBC:

• The WebLogic T3 API is deprecated in WebLogic Server 6.0; use the RMI JDBC driver in its place. This also applies to users migrating from WebLogic Server 4.5.x.

• The weblogic.jdbc20.* packages are being replaced with weblogic.jdbc.* packages. All WebLogic JDBC drivers are now compliant with JDBC 2.0.

• If you have a current connection and are using a 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 preparedStatement will not know how to access the newly created stored procedure-it is essentially a different object with the same name.

RMI

The following tips are for users migrating to WebLogic 6.0 who used RMI in their previous version of WebLogic Server:

• Re-run the WebLogic RMI compiler, weblogic.rmic, on any existing code to regenerate the wrapper classes so they are compatible with WebLogic Server 6.0.

• Use java.rmi.Remote to tag interfaces as remote. Do not use weblogic.rmi.Remote.

• Use java.rmi.*Exception. Do not use the weblogic.rmi counterparts.

• Use JNDI instead of *.rmi.Naming.

• You may use weblogic.rmic to generate stubs and skeletons.

• Use weblogic.rmi.server.UnicastRemoteObject.exportObject() to get a stub instance.

• The RMI examples have not currently been updated to use java.rmi.* and JNDI. The examples will be revised to reflect java.rmi.* and JNDI in a future release.

Internationalization (I18N)

Several internationalization and localization changes have been made in this version:

• Changes have been made to the log file format that affect the way that messages are localized. The new message format also has additional things in the first line that were not present in earlier versions of WebLogic Server. New entries are: begin marker, machine name, server name, thread id, user id, tran id, and message id.

• There is a new internationalized logging API through which users can log messages in the server and clients.

• Clients log to their own logfiles which are in the same format as the server logfiles, with the exception of the servername and threadid fields.

• LogServicesDef is deprecated. Instead, use the internationalized API or weblogic.logging.NonCatalogLogger (when internationalization is not required).

For details on internationalization in this version, see BEA WebLogic Server Internationalization Guide.

Security

Existing WebLogic Server customers may have private keys that are unprotected in Definite Encoding Rules (DER) format. For those private keys to work with this version of WebLogic Server, you need to convert the private keys to a PKCS#5/PKCS#8 Privacy Enhanced Mail (PEM) format. Use the protectkey conversion tool to convert your private keys. The protectkey tool takes a private key in DER format and a password and converts them to a PKCS#5/PKCS#8 PEM format. For more information about the protectkey tool, see Managing Security in the Administration Guide.

It is highly recommended that users read our documentation on Programming WebLogic Security for the most detailed information on using security with WebLogic Server 6.0. WebLogic users migrating from earlier releases should read the following list of tips and issues:

• A large portion of implementing security in the WebLogic Server environment is configuration. To migrate a current security configuration, convert the weblogic.properties file to XML attributes in config.xml using the Administration Console. Details on converting weblogic.properties files are described in the Console Help documentation. For a complete mapping of the security properties to XML attributes, see "Managing Security" in the Administration Guide .

• The name of the default security realm changed from WLPropertyRealm to the File realm. Realm attributes are now stored in the fileRealm.properties file instead of the weblogic.properties file.

• At some point, redefine your realm and authorization attributes through the Administration Console. The resulting information is stored in the fileRealm.properties file. For information about creating a custom realm in WebLogic Server 6.x, see Writing a Custom Security Realm.

• It is highly recommended that at the end of installation, you check all security settings to make sure they are the appropriate ones for their environment.

• ACLs can no longer be used to specify security for stand-alone servlets because stand-alone servlets have been completely replaced by web applications. Web applications can only be secured using the web app's deployment descriptors as defined in the Servlet 2.2 specification.

• The Delegating security realm is no longer supported in WebLogic Server 6.0. If you are using the Delegating security realm, you must use another type of security realm to store Users, Groups, and ACLs. For details, see "http://download.oracle.com/docs/cd/E13222_01/wls/docs60/adminguide/cnfgsec.html".

WAP Applications

To run a WAP application on WebLogic Server 6.0, you must now specify the MIME types associated with WAP in the web.xml file of the web application. In WebLogic Server 5.1, the default mime-type can be set using weblogic.httpd.defaultMimeType in weblogic.properties where its default value is "text/plain". WebLogic Server 6.0, WebLogic Server 6.1, and WebLogic Server 7.0 do not have a default mime-type. You must explicitly specify mime-type for each extension in the web.xml file. For information on required MIME types see Using Wireless Application Protocol (WAP) with WebLogic Server. For information on creating and editing a web.xml file, see Writing Web Application Deployment Descriptors.

An example configuration of the mime-types in the web.xml file:

<web-app>

<mime-mapping>

<extension>tiff</extension>

<mime-type>image/tiff</extension>

</mime-mapping>

<mime-mapping>

<extension>tif</extension>

<mime-type>image/tiff</extension>

</mime-mapping>

</web-app>

Web Services

The following tips are for users migrating to WebLogic 6.0 who used Web Services in their previous version of WebLogic:

• All of the Web services in WebLogic Server now use Web Applications as the mechanism for defining how WebLogic Server serves up JSPs, servlets, and static HTML pages. In a new installation of WebLogic Server, the server will configure a default Web Application. Customers upgrading to WebLogic 6.0 should not need to perform any registrations because this default Web Application closely approximates the document root, the JSPServlet, and servlet registrations performed using the weblogic.properties file contained in earlier versions.

• Convert your existing weblogic.properties file to .xml files using the Administration Console. See Console Help for more details.

• SSI is no longer supported.

• URL ACLs are deprecated. Use Servlet 2.2 features instead.

• Some information has moved from web.xml to weblogic.xml. This reorganization allows a third-party Web application based strictly on Servlet 2.2 to be deployed without modifications to its J2EE standard deployment descriptor (web.xml). WebLogic Server 5.1 style settings made in the web.xml file using <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.xml are now defined in weblogic.xml:
  
  JSP Parameters (keepgenerated, verbose, packagePrefix, pageCheckSeconds, encoding)
  
  HTTP sessionParameters (CookieDomain, CookieComment, CookieMaxAgeSecs, CookieName, CookiePath, CookiesEnabled, InvalidationIntervalSecs, PersistentStoreDir, PersistentStorePool, PersistentStoreType, SwapIntervalSecs, IDLength, CacheSize, TimeoutSecs, JDBConnectionTimeoutSecs, URLRewritingEnabled)

• For more information, see Writing Web Application Deployment Descriptors.

XML

The XML parser has been updated and is now based on the Apache Xerces parser. The parser implements version 2 of the SAX and DOM interfaces. Users who made use of older parsers that were shipped in the weblogicaux.jar (such as Sun's Project X parser) may receive deprecation messages.

Deprecated APIs and Features

The following APIs and features are deprecated in anticipation of future removal from the product:

• weblogic.security.acl

• -Dweblogic.management.host

• WebLogic Events

  WebLogic Events are deprecated and should be replaced by JMS messages with NO_ACKNOWLEDGE or MULTICAST_NO_ACKNOWLEDGE delivery modes. See Programming WebLogic JMS for more information.

• WebLogic HTMLKona

• T3Client

• T3 Driver

• Delegating security realm

  The Delegating security realm is no longer supported in WebLogic Server 6.0. If you are using the Delegating security realm, you will have to use another type of security realm to store Users, Groups, and ACLs. For details, see "http://download.oracle.com/docs/cd/E13222_01/wls/docs60/adminguide/cnfgsec.html".

Removed APIs and Features

The following APIs and features have been removed:

• The old administrative console GUI.

  Use the new Administration Console.

• The Deployer Tool.

• WebLogic Beans

• WebLogic jHTML

• weblogic.logging.LogOutputStream; use weblogic.logging.NonCatalogLogger

• WebLogic Remote

• WorkSpaces

• WebLogic Tour

• Jview support

• SSI

• Weblogic Bean Bar

• RemoteT3

• Jview support

• Weblogic COM

  This feature relied on the Microsoft JVM (Jview) which is no longer supported.

• WebLogic Tour