BEA Home | Events | Solutions | Partners | Products | Services | Download | Developer Center | WebSUPPORT
| WebLogic Server Doc Home | Release Notes | Previous Topic | Next Topic | Contents | View as PDF

Migrating WebLogic Server 4.5 and 5.1 Applications to 6.x

- The following sections describe how to migrate applications from WebLogic Server Version 4.5 or 5.1 to WebLogic Server 6.x, and provide additional information concerning migration and deployment. Instructions apply to migrations from both WebLogic Server 4.5 and 5.1 to both WebLogic Server 6.0 and 6.1. For a more detailed procedure, see the Migration Tutorial on BEA dev2dev.

- The weblogic.properties File and .xml Files

- WebLogic Server 6.x Application Types

- Migration Main Steps

- Converting the weblogic.properties File to .xml files

- weblogic.properties Mapping Table

- Migrating Web Applications

- Migrating and Converting Enterprise JavaBeans Applications

- Creating an Enterprise Application

- Understanding J2EE Client Applications

- Migrating JMS Applications

- Additional Migration and Deployment Considerations

The weblogic.properties File and .xml Files

Earlier releases of WebLogic Server used a weblogic.properties file to configure applications. In WebLogic Server 6.0 and 6.1, 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.

The 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, and all elements in the Domain are children of the Domain element. The Domain element includes child elements, such as the Server, Cluster, and Application elements. These child elements may have children themselves. Each element has one or more configurable attributes. An attribute defined in config.dtd has a corresponding attribute in the configuration API.

The 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 is defined by the servlet 2.3 specification from Sun Microsystems. This deployment descriptor can be used to deploy a Web Application on any J2EE-compliant application server.

WebLogic Server 6.x Application Types

Applications on J2EE-compliant servers such as WebLogic Server 6.0 and 6.1 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.1, you create the appropriate J2EE deployment units. Web Applications are usually a collection of servlets, JSPs, and HTML files, packaged as .war files. Enterprise JavaBeans (packaged as.jar files) are server-side Java components written according to the EJB specification. Enterprise Archives (.ear files) can 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 in the following sections.

Migration Main Steps

The following steps outline the general migration procedure. Later sections describe these steps in more detail as they apply to particular types of applications. Also see the Migration Tutorial on BEA dev2dev.

1. Convert your weblogic.properties file to .xml files.

2. In WebLogic Server 6.x, specify your new domain. You will migrate applications to this domain.

3. Modify your start and setenv scripts to point to your new domain.

4. Restart WebLogic Server 6.x.

5. Migrate your application.

Converting the weblogic.properties File to .xml files

Note: In order for the conversion to work properly, you need to specify the following in your weblogic.properties file:

weblogic.password.system=gumby1234

Convert your weblogic.properties file to the appropriate .xml files by following these steps:

1. Start the default WebLogic Server 6.1 server and the default WebLogic Server 6.1 Administration Console. For information on starting WebLogic Server 6.1, 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 Console's links to navigate the server's file system and find the root directory 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 of your previous version of WebLogic Server, your global weblogic.properties file will be converted regardless of any additional properties files that you select.

5. Enter a name for your new domain in the provided window in the Console. Click Convert.

The process of converting your weblogic.properties file creates the config.xml file in the wlserver6.1/config/domainName directory. This file contains configuration information specific to your domain. It creates the web application in the wlserver6.1/config/domainName/production_apps/DefaultWebApp_serverName/ directory. The web.xml and weblogic.xml files for the web application are placed inside the wlserver6.1/config/domainName/production_apps/DefaultWebApp_serverName/WEB-INF/ directory.

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.

Throughout this document, the directory of the new domain that has been created is referred to as domainName. The default domain that is provided with the original installation of WebLogic Server 6.1 is called mydomain and is located in the wlserver6.1/config/ directory.

The startup scripts, which are generated when a weblogic.properties file is converted, are named start domainName.cmd (for Windows users) and start domainName.sh (for UNIX users) and exist under the WL6x_HOME/config/domainName directory in your WebLogic Server 6.x distribution. These scripts will start the server in the new domain.

See Starting and Stopping the WebLogic Server for more information on scripts and starting servers.

weblogic.properties Mapping Table

The weblogic.properties mapping table shows which config.xml, web.xml, or weblogic.xml attribute handles the function formerly performed by weblogic.properties properties. If the attribute can be configured in the Administration Console, the table shows the navigation path to the attribute.

weblogic.properties file Property | .xml Configuration Attribute | Console Navigation
--- | --- | ---
weblogic.administrator.email | config.xml: EmailAddress (Administrator element) |
weblogic.administrator.location | config.xml: Notes (freeform, optional) (Administrator element) |
weblogic.administrator.name | config.xml: Name (Administrator element) |
weblogic.administrator.phone | config.xml: PhoneNumber (Administrator element) |
weblogic.cluster.defaultLoadAlgorithm | config.xml: DefaultLoadAlgorithm | Clusters: clustername: Configuration: General: Default Load Algorithm
weblogic.cluster.multicastAddress | config.xml: MulticastAddress | Clusters: clustername: Configuration: Multicast: Multicast Address
weblogic.cluster.multicastTTL | config.xml: MulticastTTL | Clusters: clustername: Configuration: Multicast: Multicast TTL
weblogic.cluster.name | config.xml ClusterAddress | Clusters: clustername: Configuration: General: Cluster Address
weblogic.httpd.authRealmName | config.xml: AuthRealmName (WebAppComponent element) | Deployments: Web Applications: applicationname: Configuration: Other: Auth Realm Name
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) | Servers: servername: Configuration: HTTP: Default Server Name
weblogic.httpd.defaultServlet | web.xml: define a servlet-mapping with the URL pattern of / <servlet-mapping> 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) | Deployments: Web Applications: applicationname: Configuration: Files: Index Directories
weblogic.httpd.keepAlive.enable | config.xml: KeepAliveEnabled | Servers: servername: Configuration: HTTP: Enable Keep Alives
weblogic.httpd.logFileBufferKBytes | config.xml: LogFileBufferKBytes (WebServer element) |
weblogic.httpd.logFileFlushSecs | config.xml: LogFileFlushSecs (WebServer element) |
weblogic.httpd.logFileFormat | config.xml: LogFileFormat (WebServer element) | Services: Virtual Host: Log File Format
weblogic.httpd.logFileName | config.xml: LogFileName | Services: Virtual Host: Log File Name
weblogic.httpd.logRotationPeriodMins | config.xml: LogRotationTimeBegin (WebServer element) |
weblogic.httpd.logRotationPeriodMins | config.xml: LogRotationPeriodMins (WebServer element) |
weblogic.httpd.logRotationType | config.xml: LogRotationType | Servers: servername: Logging: HTTP: Rotation Type
weblogic.httpd.maxLogFileSizeKBytes | config.xml: MaxLogFileSizeKBytes | Servers: servername: Logging: HTTP: Max Log File Size Kbytes
weblogic.httpd.mimeType | web.xml: mime-type <mime-mapping> element |
weblogic.httpd.postTimeoutSecs | config.xml: PostTimeoutSecs | Servers: servername: Configuration: HTTP: Post Timeout Secs
weblogic.httpd.servlet.extensionCaseSensitive | config.xml: ServletExtensionCaseSensitive | Deployments: Web Applications: applicationname: Configuration: Files: Case Sensitive Extensions
weblogic.httpd.servlet.reloadCheckSecs | config.xml: ServletReloadCheckSecs | Deployments: Web Applications: applicationname: Configuration: Files: Reload Period
weblogic.httpd.servlet.SingleThreadedModelPoolSize | config.xml: SingleThreadedServletPoolSize (WebAppComponent element) | Deployments: Web Applications: applicationname: Configuration: Files: Single Threaded Servlet Pool Size
weblogic.httpd.session.cacheEntries | weblogic.xml: CacheSize <param-name>/<param-value> element pair | Servers: servername: Configuration: SSL: Certificate Cache Size
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: TrackingEnabled <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 | Servers: servername: Configuration: HTTP: Post Timeout Secs
weblogic.httpd.session.URLRewriting.enable | weblogic.xml: URLRewritingEnabled <param-name>/<param-value> element pair |
weblogic.httpd.tunneling.clientPingSecs | config.xml: TunnelingClientPingSecs | Servers: servername: Configuration: Tuning: Tunneling Client Ping
weblogic.httpd.tunneling.clientTimeoutSecs | config.xml: TunnelingClientTimeoutSecs (Server element) | Servers: servername: Configuration: Tuning: Tunneling Client Timeout
weblogic.httpd.tunnelingenabled | config.xml TunnelingEnabled (Server element) | Servers: servername: Configuration: Tuning: Enable Tunneling
weblogic.httpd.URLResource | config.xml: URLResource (WebServer element) |
weblogic.iiop.password | config.xml: DefaultIIOPPassword (Server element) | Servers: servername: Configuration: Protocols: Default IIOP Password
weblogic.iiop.user | config.xml: DefaultIIOPUser (Server element) | Servers: servername: Configuration: Protocols: Default IIOP User
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 |
weblogic.jms.connectionFactoryArgs.<<factoryName>> ClientID DeliveryMode TransactionTimeout | config.xml: JMSConnectionFactory element ClientID DefaultDeliveryMode TransactionTimeout UserTransactionsEnabled AllowCloseInOnMessage |
weblogic.jms.connectionFactoryName | config.xml: JMSConnectionFactory element JNDIName |
weblogic.jms.connectionPool | ConnectionPool (JMSJDBCStore element) |
weblogic.jms.queue | config.xml: JNDIName StoreEnabled (JMSDestination element) |
weblogic.jms.queueSessionPool | config.xml: ConnectionConsumer ConnectionFactory ListenerClass AcknowledgeMode SessionsMaximum Transacted (JMSSessionPool element) |
weblogic.jms.tableNamePrefix | config.xml: PrefixName |
weblogic.jms.topic | config.xml JNDIName StoreEnabled (JMSDestination element) | Services: JMS: Connection Factories: JNDI Name
weblogic.jms.topicSessionPool | config.xml: ConnectionConsumer ConnectionFactory ListenerClass AcknowledgeMode SessionsMaximum Transacted (JMSSessionPool element) |
weblogic.jndi.transportableObjectFactories | config.xml: JNDITransportableObjectFactoryList (Server element) | Servers: servername:
weblogic.login.readTimeoutMillisSSL | config.xml LoginTimeoutMillis (SSL element) | Servers: servername:
weblogic.security.audit.provider | config.xml AuditProviderClassName (Security element) | Security: General: Audit Provider Class
weblogic.security.certificate.authority | config.xml ServerCertificateChainFileName (SSL element) | Servers: servername: Configuration: SSL: Server Certificate Chain File Name
weblogic.security.certificate.server | config.xml: ServerCertificateFileName (SSL element) | Servers: servername: Configuration: SSL: Server Certificate File Name
weblogic.security.certificateCacheSize | config.xml: CertificateCacheSize (SSL element) | Servers: servername: Configuration: SSL: Certificate Cache Size
weblogic.security.clientRootCA | config.xml: TrustedCAFileName (SSL element) | Servers: servername: Configuration: SSL: Trusted CA File Name
weblogic.security.disableGuest | config.xml: GuestDisabled (Security element) | Security: General: Guest Disabled
weblogic.security.enforceClientCert | config.xml: ClientCertificateEnforced (SSL element) | Servers: servername: Configuration: SSL: Client Certificate Enforced
weblogic.security.key.export.lifespan | config.xml: ExportKeyLifespan (SSL element) | Servers: servername: Configuration: SSL: Export Key Lifespan
weblogic.security.key.server | config.xml: ServerKeyFileName (SSL element) | Servers: servername: Configuration: SSL: Server Key File Name
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) | Servers: servername: Configuration: SSL: Cert Authenticator
weblogic.security.SSL.ciphersuite | config.xml Ciphersuites (SSL element) |
weblogic.security.ssl.enable | config.xml: Enabled (SSL element) | Servers: servername: Configuration: SSL: Enabled
weblogic.security.SSL.hostnameVerifier | config.xml HostnameVerifier (SSL element) | Servers: servername: Configuration: SSL: Hostname Verifier
weblogic.security.SSL.ignoreHostnameVerification | config.xml HostNameVerificationIgnored (SSL element) |
weblogic.security.SSLHandler.enable | config.xml: HandlerEnabled (SSL element) | Servers: servername: Configuration: SSL: Handler Enabled
weblogic.security.unixrealm.authProgram | config.xml: AuthProgram (UnixRealm element) |
weblogic.system.AdministrationPort | config.xml AdministrationPort (Server element) | Servers: servername: Configuration: General: Administration Port
weblogic.system.AdministrationPort | config.xml: AdministrationPort (Server element) | Servers: servername: Configuration: General: Administration Port
weblogic.system.bindAddr | config.xml: ListenAddress (Server element) |
weblogic.system.defaultProtocol | config.xml: DefaultProtocol (Server element) | Servers: servername: Configuration: Protocols: Default Protocol
weblogic.system.defaultSecureProtocol | config.xml: DefaultSecureProtocol (Server element) | Servers: servername: Configuration: Protocols: Default Secure Protocol
weblogic.system.enableConsole | config.xml: StdoutEnabled (Kernel element) | Servers: servername: Logging: General: Log to Stdout
weblogic.system.enableIIOP | config.xml: IIOPEnabled (Server element) |
weblogic.system.enableReverseDNSLookups | config.xml: ReverseDNSAllowed (Server element) |
weblogic.system.enableSetGID, | config.xml: PostBindGID |
weblogic.system.enableSetUID, | config.xml: PostBindUIDEnabled |
weblogic.system.enableTGIOP | config.xml TGIOPEnabled (Server element) | Servers: servername:
weblogic.system.helpPageURL | config.xml HelpPageURL (Server element) | Servers: servername:
weblogic.system.home | config.xml: RootDirectory (Server element) |
weblogic.system.ListenPort | config.xml ListenPort (Server element) | Servers: servername: Configuration: SSL: Listen Port
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) | Servers: servername: Configuration: Tuning: Enable Native IO
weblogic.system.nonPrivGroup | config.xml PostBindGID (UnixMachine element) |
weblogic.system.nonPrivUser | config.xml PostBindUID (UnixMachine element) |
weblogic.system.percentSocketReaders | config.xml: ThreadPoolPercentSocketReaders (Kernel element) | Servers: servername: Configuration: Tuning: Socket Readers
weblogic.system.readTimeoutMillis | config.xml LoginTimeoutMillis (Server element) | Servers: servername:
weblogic.system.SSL.useJava | config.xml: UseJava (SSL element) | Servers: servername: Configuration: SSL: Use Java
weblogic.system.SSLListenPort | config.xml: ListenPort (SSL element) | Servers: servername: Configuration: SSL: Listen Port
weblogic.system.startupFailureIsFatal | config.xml FailureIsFatal (StartupClass element) |
weblogic.system.user | config.xml: SystemUser (Security element) |
weblogic.system.weight | config.xml ClusterWeight (Server element) | Servers: servername: Configuration: Cluster: Cluster Weight
weblogic.workspace.showUserKeysOnly | config.xml: WorkspaceShowUserKeysOnly (Server element) | Servers: servername: Configuration: Tuning: Show Only Workspace User Keys
weblogic.zac.enable | config.xml: ZACEnabled (Server element) | Servers: servername
weblogic.zac.publishRootProp | config.xml: ZACPublishRoot (Server element) | Servers: servername

Migrating Web Applications

In order to migrate applications into a Web Application deployed on WebLogic Server 6.0 or 6.1, the applications' files 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 a .war file as a single Web Application. For more information on Web Applications see Understanding WebLogic Server Applications and Assembling and Configuring Web Applications.

The following sections provide information you need to know about migrating and deploying Web Applications, including a procedure for migrating a simple servlet from WebLogic Server 5.1 to WebLogic Server 6.1:

- Web Applications Directory Structure

- XML Deployment Descriptors

- WAR Files

- Deploying Web Applications

- Session Migration

- JavaServer Pages (JSPs) and Servlets

- Migrating a Simple Servlet from WebLogic Server 5.1 to WebLogic Server 6.1

Web Applications Directory Structure

Web Applications are organized in 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.1/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

When you convert your weblogic.properties file, the appropriate web.xml and weblogic.xml files are created for you under the directory wlserver6.1/config/domainName/applications/DefaultWebApp_myserver/WEB-INF. Follow the preceding directory structure and place the .xml files in the wlserver6.1/config/domainName/applications/webAppName/WEB-INF directory that you create. All applications must be placed inside a wlserver6.1/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.

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 Assembling and Configuring 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 be bundled together in a Web Application deployed as a .war file. Once you have bundled your applications into a .war file, 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.1/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.1/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.

Session Migration

WebLogic Server 6.0 and later does not recognize cookies from previous versions because cookie format changed with 6.0. WebLogic Server will ignore cookies with the old format, and create new sessions.

The default name for cookies has changed from 5.1, when it was WebLogicSession. Beginning in WebLogic 6.0, cookies are named JSESSIONID by default.

See weblogic.xml Deployment Descriptor Elements at http://e-docs.bea.com/wls/docs61/webapp/weblogic_xml.html for more information.

JavaServer Pages (JSPs) 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 other than 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.3 specification.

Migrating a Simple Servlet from WebLogic Server 5.1 to WebLogic Server 6.1

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

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 before you converted it, the servlet 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-cla
   >     ss>
   >     </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.

3. Move the web.xml file from wlserver6.1/config/domainName/applications/DefaultWebApp_myserver/WEB-INF to C:/hello/WEB-INF/.

4. 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.

5. 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.

6. 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.

7. 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 servlet mapping tags inside the web.xml file.

Migrating and Converting Enterprise JavaBeans Applications

The following sections describe Enterprise Java Beans migration and conversion procedures.

EJB Migration Considerations

Consider the following when migrating Enterprise JavaBeans to WebLogic Server 6.x.

- WebLogic Server Version 6.0 and 6.1 both support the Enterprise JavaBeans 1.1 and 2.0 specifications.

- The XML parser is stricter with XML deployment descriptors in WebLogic 6.0 and 6.1 than it was in WebLogic 5.1. 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 and 6.1. 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.

- You can upgrade EJB 1.0 deployment descriptors to EJB 2.0 using the DDConverter utility, but first those descriptors must be upgraded to 1.1. WebLogic Server 5.1 deployment descriptors can be upgraded to 6.0 or 6.1 to take advantage of new features in WebLogic Server 6.0 and 6.1. 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.

- Deploying beans is described in Programming WebLogic EJB.

- If ejbc has not been run on an EJB, WebLogic Server 6.1 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.

- An EJB deployment includes a standard deployment descriptor in the ejb-jar.xml file. The ejb-jar.xml must conform to either the EJB 1.1 DTD (document type definition) or the EJB 2.0 DTD.

- An EJB deployment needs the weblogic-ejb-jar.xml file, 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 6.0 DTD.

- In order to specify the mappings to the database, Container-Managed Persistence Entity Beans require a CMP deployment descriptor which conforms to either the WebLogic Server 5.1 CMP DTD, the WebLogic Server 6.0 EJB 1.1 DTD, or the WebLogic Server 6.0 EJB 2.0 DTD.

EJB Migration Recommendations

- Use TxDataSource

  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 6.x CMP Deployment Descriptor supports TxDataSources and should be used instead of the WebLogic Server 5.1 CMP Deployment Descriptor which only specifies a connection pool.

- Use a fast compiler with ejbc

  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 follows:

  >     java weblogic.ejbc -compiler sj pre_AccountEJB.jar
  >     AccountEJB.jar

- Correct errors before deploying the EJB on the WeblLogic Server 6.1

  The WebLogic Server 6.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 6.1 finds and complains about the error. These errors must be corrected before the EJB is deployed in WebLogic Server 6.1.

  For instance, WebLogic Server 6.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.

- Look at the WebLogic Server 6.1 examples

  The WebLogic Server distribution contains several EJB examples including their deployment descriptors. The EJB examples can be found in the samples/examples/ejb and samples/examples/ejb20 directories of the WebLogic Server 6.1 distribution.

  The following table shows the descriptor combinations supported by WebLogic Server 6.1.

  EJB Version | WebLogic Server Version | CMP Version
  --- | --- | ---
  Any existing WebLogic Server 5.1 deployment uses the following combination and can be deployed without changing descriptors or code in WebLogic Server 6.1.
  1.1 | 5.1 | 5.1
  The following combination uses a WebLogic Server 6.0 deployment descriptor so that new WebLogic Server 6.x features can be specified in the weblogic-ejb-jar.xml file.
  1.1 | 6.x | 5.1
  The below combinations include a WebLogic Server 6.0 CMP deployment descriptor. The WebLogic Server 6.x EJB 1.1 CMP deployment descriptor allows multiple EJBs to be specified within a single EJB JAR file, and it supports using a TxDataSource which is required when an EJB is enlisted in a two-phase / XA transaction.
  1.1 | 5.1 | 6.x
  1.1 | 6.x | 6.x
  EJB 2.0 beans always use the WebLogic Server 6.x deployment descriptors.
  2.0 | 6.x | 6.x

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

Steps for Migrating a 1.0 EJBean from WebLogic Server 4.5.x to WebLogic Server 6.1

WebLogic Server 3.1.x, 4.0.x, and 4.5.x supported the EJB 1.0 specification. To migrate a 1.0 EJB from WebLogic Server 4.5 to WebLogic Server 6.1:

1. Convert the EJB 1.0 deployment descriptor to either the EJB 1.1 or the EJB 2.0 XML deployment descriptor. You can do this automatically using the DDCreator tool.

2. Package the deployment in a JAR file.

3. Run the WebLogic Server EJB compiler (ejbc) to compile the JAR file. The ejbc tool ensures that when the EJB compiles, it conforms to either the EJB 1.1 or EJB 2.0 specifications.

4. Correct any compliance errors before deploying the EJB in the EJB container.

To ensure EJB 1.1 or 2.0 compliance, make the following changes to the EJB 1.0 beans:

- EJB 1.0 beans referred to the SessionContext or EntityContext transient. When deploying EJB 1.1 or 2.0 beans, the reference cannot be transient. For example:

  >     private transient SessionContext ctx;

  should be:

  >     private SessionContext ctx;

- The ejbCreate method for EJB 1.0 CMP entity beans had a void return type. When deploying EJB 1.1 or 2.0 beans, the return type must be the primary key class which allows you to write a bean-managed persistent entity bean and then sub-class it with a CMP implementation. For example:

  >     public void ejbCreate (String name) {
  >     firstName = name;
  >     }

  should be:

  >     public AccountPK ejbCreate (String name) {
  >     firstName = name;
  >     return null; // required by the EJB specification
  >     }

- In EJB 1.1 or 2.0, entity beans cannot use bean-managed transactions. Instead, they must run with a container-managed transaction attribute (for example, Required, Mandatory, etc.).

Steps for Migrating a 1.1 EJBean from WebLogic Server 5.1 to WebLogic Server 6.1

The WebLogic Server 5.1 deployment descriptor only allows the exclusive or read-only concurrency options. The database concurrency option is available when upgrading to the WebLogic Server 6.x weblogic-ejb-jar.xml file. For more information about this option, see information on database concurrency in weblogic-ejb-jar-xml Deployment Descriptors

The WebLogic Server 6.x CMP deployment descriptor allows multiple EJBs to be specified and it supports using a TxDataSource instead of a connection pool. Using a TxDataSource is required when XA is being used with EJB 1.1 CMP.

To migrate a 1.1 EJB from WebLogic Server 5.1 to WebLogic Server 6.1:

1. Open the Administration Console. From the home page, click on Install Applications under the Getting Started heading.

2. Locate the JAR file you wish to migrate by clicking the Browse button, then click Open and then Upload. Your bean should now be automatically deployed.

3. Run a setEnv script in a client window and set your development environment. (For more information, see Establishing a Development Environment.)

4. 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

5. To run the client, enter this command:

   >     java examples.ejb.basic.statelessSession.Client

Steps for Converting an EJB 1.1 to an EJB 2.0

To convert an EJB 1.1 bean to a EJB 2.0 bean, you can use the WebLogic Server DDConverter utility.

We recommend that you develop EJB 2.0 beans in conjunction with WebLogic Server 6.1. 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.1. 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.

Migrating EJBs from other J2EE Application Servers

Any EJB that complies with the EJB 1.1 or EJB 2.0 specifications may be deployed in the WebLogic Server 6.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/ejb and samples/examples/ejb20 of the WebLogic Server distribution include sample weblogic deployment descriptors.

Creating an Enterprise Application

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

To create an .ear file:

1. Assemble all of the Web Archive and EJB Archives for your application and place them under your staging directory.

2. 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.

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

   >     jar cvf myApp.ear *

4. Click on the Install Applications link under the Getting Started heading in the home page of the console and place the .ear file in the /wlserver6.1/config/domainName/applications directory. For more information on Enterprise Applications, see Staging Enterprise Applications.

Understanding J2EE Client Applications

WebLogic Server supports J2EE client applications, packaged in a jar file with a standard XML deployment descriptor. Client applications in this context are clients that are not Web browsers. They 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 package a client application to this specification. For more information about J2EE client applications, see Staging and Deploying Client Applications.

Migrating JMS Applications

WebLogic Server 6.1 supports the JavaSoft JMS specification version 1.0.2.

In order to use your existing JMS applications, you must first confirm your version of WebLogic Server, and then perform the appropriate migration procedures provided in the "Migrating WebLogic JMS Application" chapter in Programming WebLogic JMS.

Before beginning the migration procedure, you should check the following list to confirm whether migration is supported for your version of WebLogic JMS, and to find out whether special migration rules apply to that release:

- Weblogic Server 4.5.1 — Migration is supported only for SP14. Customers running all service packs should contact BEA Support.

- Weblogic Server 5.1 — Customers running SP07 or SP08 should contact BEA Support before migrating existing JDBC stores to versions 6.0 or 6.1.

  - In order to migrate object messages, the object classes need to be in the Weblogic Server 6.0 or higher server classpath.

  - For destinations that are not configured in Weblogic Server 6.0 or higher, the migrated messages will be dropped and the event will be logged.

Note: 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.

Additional Migration and Deployment Considerations

The following sections provide additional information that may be useful when you deploy applications on WebLogic Server 6.x. Deprecated features, upgrades, and the important changes that have been made in WebLogic Server 6.1 are noted.

- Standalone HTML and JSPs

- Applications and Managed Servers

- Java Transaction API (JTA)

- Java Database Connectivity (JDBC)

- RMI

- Internationalization (I18N)

- Security

- WAP Applications

- Session Migration

- Web Components

- XML 6.0->6.1 Parser

- Deprecated APIs and Features

- Removed APIs and Features

Standalone HTML and JSPs

In the original domain provided with WebLogic Server 6.1, as well as in any domains that have been created using the weblogic.properties file converter, wlserver6.1/config/domainName/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.

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. You should use the Administration Server only for administrative purposes, and define new managed servers and associate the applications with those servers using the Administration Console. For more information, see Configuring WebLogic Servers and Clusters and Domains, the Administration Server, and Managed Servers.

Java Transaction API (JTA)

The following changes in JTA have taken place:

- WebLogic Server 6.1 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 Database Connectivity (JDBC)

The following changes have been made in JDBC:

- The WebLogic T3 API is deprecated in WebLogic Server 6.0 and 6.1; 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 Server 6.1 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.1.

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

- Use java.rmi.*Exception (e.g., import java.rmiRemoteException;). Do not use weblogic.rmi.*Exception.

- Use JNDI instead of *.rmi.Naming.

- Use weblogic.rmic to generate dynamic proxies and bytecode; with the exception of RMI IIOP, stubs and skeletons classes are no longer generated.

Note: For more information, see Programming WebLogic RMI.

- 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.

FileServlet

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 when determining the source filename. This means that it is possible to explicitly only serve files from specific directories by mapping the FileServlet to /dir/* etc.

See Setting Up a Default Servlet.

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 additions to the first line: 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

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.1. WebLogic Server 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.3 specification.

WAP Applications

To run a WAP application on WebLogic Server 6.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, 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 Programming WebLogic Server for Wireless Services. 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>

Session Migration

WebLogic Server 6.0 and later does not recognize cookies from previous versions because cookie format changed with 6.0. WebLogic Server ignores cookies with the old format, and creates new sessions.

The default name for cookies has changed from 5.1, when it was WebLogicSession. Beginning in WebLogic 6.0, cookies are named JSESSIONID by default.

See weblogic.xml Deployment Descriptor Elements at http://e-docs.bea.com/wls/docs61/webapp/weblogic_xml.html for more information.

Web Components

The following tips are for users migrating to WebLogic Server 6.1 who used Web Components in their previous version of WebLogic Server:

- All Web components 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 Server 6.1 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.3 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, precompile compileCommand, 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 6.0->6.1 Parser

The XML 6.0 -> 6.1 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 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

- T3 Driver

- -Dweblogic.management.host

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 Remote

- WorkSpaces

- WebLogic Server Tour

- T3Client

- Jview support

- SSI

- Weblogic Bean Bar

- RemoteT3

- Jview support

- Weblogic COM

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

Copyright © 2001 BEA Systems, Inc. All rights reserved. Required browser: Netscape 4.0 or higher, or Microsoft Internet Explorer 4.0 or higher.