B WebLogic Server 12.2.1.4.0 Compatibility with Previous Releases
See also:
-
WebLogic Server Compatibility in Understanding Oracle WebLogic Server. This section provides general information about WebLogic Server compatibility goals and how they apply to this WebLogic Server release.
-
What's New in Oracle WebLogic Server 12.2.1.4.0 for this and prior releases. These documents provide information about new features that are available to you as well as behavior changes that may impact your applications.
Compatibility considerations are provided in the following sections. The sections that apply to your situation depend on the WebLogic Server version from which you are upgrading to WebLogic Server 12.2.1.4.0. See Table B-1for a list of sections to which you should refer based on your current WebLogic Server version.
Table B-1 Sections Applying to Upgrades From Each WebLogic Server Version
About WebLogic Server Cluster Messaging
In 12.2.1.4.0, WebLogic Server cluster messaging has been enhanced. If all of the servers in a cluster are running the same installation version of WebLogic Server, no changes are required.
When you perform a rolling upgrade from 12.2.1.3.0 to 12.2.1.4.0 or a downgrade from 12.2.1.4.0 to 12.2.1.3.0, the newer 12.2.1.4.0 servers must be explicitly set, to temporarily allow the older protocol. You can do this by setting the system property weblogic.upgradeExpirationDate
with an expiration date, which enables the 12.2.1.4.0 server to allow communication on the cluster until that expiration date and time is reached. For example:
-Dweblogic.upgradeExpirationDate=2020-01-05T08:47
If you want the clusters that are at different versions, to continue to communicate for an extended period of time, you must set the value to a preferred future upgrade date.
Note:
The system property-Dweblogic.upgradeExpirationDate
must be used in the Server Start arguments for each of the Managed Servers, and not in the JAVA_OPTIONS
environment variable in the startWebLogic.sh
or startWebLogic.cmd
scripts.
Upgraded Version of Apache Ant
clientgen
Ant task. The clientgen
Ant task generates, from an existing WSDL file, the client component files that client applications use to invoke both WebLogic and non-WebLogic web services. Note the following when using the <binding>
child element of this Ant task:
-
You use the
<binding>
element the same way as the standard Ant FileSet data type, using the same attributes. -
In Apache Ant 1.9.8, the Ant FileSet data type is changed so that it may specify either a single file, or a single directory. Therefore, if you use the
<binding>
element to specify multiple files or directories, theclientgen
Ant task might fail.
For more information about specifying the <binding>
child element, see binding
in WebLogic Web Services Reference for Oracle WebLogic Server.
Removed the Option to Limit Run-Time Footprint When Starting WebLogic Server
When you start a WebLogic Server instance, all services are started including EJB, JMS, Connector, Clustering, Deployment, Management, and so forth. WebLogic Server provides a startup option that you can use to run the lighter weight run-time instance in any WebLogic domain.
This startup mode can result in quicker startup times for WebLogic Server and a smaller resource footprint on the host machine. You can start a lighter weight run-time instance by specifying the following weblogic.Server
command option:
java weblogic.Server -DserverType= {"wlx" | "wls"}
As of Oracle WebLogic Server version 12.2.1.0.0, this startup option is removed.
Random Number Generator
Oracle WebLogic Server 12.2.1.4.0 uses a more secure random number generator algorithm than in previous releases. This can result in slow startup of Managed Servers, Configuration Wizard, Node Manager, and WebLogic Java utilities such as utils.ImportPrivateKey
on low-entropy systems. Therefore, you should take steps to increase system entropy.
On UNIX systems, you use rng-tools
to replace system entropy. To configure it, edit /etc/sysconfig/rngd
and add the following line:
EXTRAOPTIONS="-i -r /dev/urandom -o /dev/random -b"
You can also use the -t 60
and -W 2048
parameters. These parameters add bits to the entropy pool every 60 seconds until the pool reaches the size of 2048.
Use the following command to generate entropy manually:
rngd -r /dev/urandom -o /dev/random -b
Use the following command to check current entropy:
cat /proc/sys/kernel/random/entropy_avail
Partitions, Applications, and Container Context Root Assumptions
Java EE applications that make assumptions concerning the context root of their web container may need to be modified if they are deployed to a virtual target that has a uriPrefix
set. In this case, the context path of the application includes the uriPrefix
of the virtual target.
Note:
WebLogic Server Multitenant domain partitions, resource groups, resource group templates, virtual targets, and Resource Consumption Management are deprecated in WebLogic Server 12.2.1.4.0 and will be removed in the next release.Some examples of this are:
-
The application parses the incoming URL to construct another URL. If this parsing assumes that the URL root ends at
host:port
, the application needs to be updated because the URL root will behost:port/
prefix
with URI-based routing.The MedRec sample application is one example of this. MedRec used to parse the incoming URL to construct another URL, and assumed that the root URL consisted of only
host:port
. To address this, the following changes were made to the MedRec application:-
The original code in the
JaxWsProperties.java
file for the physician application was:public final static String WSURL = "http://" + ServerPropertiesUtils.getServerAddress("physician", "localhost") + ":" + ServerPropertiesUtils.getServerPort("7001") + "/medrec-jaxws-services/";
This was changed to the following code.
ServerPropertiesUtils.getRegion()
accounts for the possibility of a partition URI prefix in the URL:public final static String WSURL = "http://" + ServerPropertiesUtils.getRegion() + "medrec-jaxws-services/";
-
The original code in the
GettingHostFilter.java
file for the physician web application was:ServerPropertiesUtils.setAddress(request.getServerName()); ServerPropertiesUtils.setPort(String.valueOf(request.getServerPort())); chain.doFilter(request, response);
This was changed to the following code to preserve
host:port
or, if using MT URI-based routing,host:port/partition
for the web service client:if (ServerPropertiesUtils.getRegion() == null || ServerPropertiesUtils.getRegion().equals("")) { StringBuilder builder = new StringBuilder(); builder.append(request.getServerName()); builder.append(":"); builder.append(String.valueOf(request.getServerPort())); builder.append(partition); ServerPropertiesUtils.setRegion(builder.toString());
-
-
The application links to "/" in HTML/JSP code. In a non-MT environment, the application may make an assumption about the context root to which it is deployed. For example, consider an application that is deployed with the context root
/fruits
and that includes a page that refers to:<a href="/fruits/index.html">Back to Fruits List</a>
This type of absolute reference does not work if the application is deployed to a partition with a virtual target that uses a URI prefix. The preceding link will try to go to
host:port
/fruits/index.html
instead ofhost:port
/partition1/fruits/index.html
. The safest approach is to use relative URLs in links, such as:<a href="index.html">Back to Fruits List</a>
Automatic Binding of the Default CommonJ Work Manager Has Been Removed
The Work Manager API, commonj.work
, provides a set of interfaces that allows an application to execute multiple work items concurrently within a container. Automatic binding of the default CommonJ Work Manager to java:comp/env/wm/default
has been removed in WebLogic Server 12.2.1 because it is not in compliance with the Java EE 7 platform specification.
If you have an application that attempts to use the default CommonJ Work Manager, you can do either of the following:
-
Add a resource-ref entry for
wm/default
in a deployment descriptor. For example:<resource-ref> <res-ref-name>wm/default</res-ref-name> <res-type>commonj.work.WorkManager</res-type> <res-auth>Container</res-auth> </resource-ref>
-
Have the CommonJ Work Manager injected into the application component. For example:
@Resource commonj.work.WorkManager myWorkManager;
Parallel Deployment
WebLogic Server 12.2.1 adds support for parallel deployment of applications and modules, which improves startup and post-running deployment time.
By default, in WebLogic domains that are created with, or upgraded to, WebLogic Server 12.2.1 (or later):
-
Parallel deployment of applications is enabled.
-
Parallel deployment of modules for all applications in the domain is disabled.
In WebLogic Server 12.1.3 and earlier versions, applications are always deployed serially. The default deployment order is the natural order that is defined in the domain configuration (that is, as established in the config.xml
file). However, in those earlier WebLogic Server releases, you can explicitly control deployment order by setting the DeploymentOrder
attribute of the AppDeploymentMBean
, using the WebLogic Server Administration Console or programmatically as explained in Changing the Deployment Order for Applications and Standalone Modules in Deploying Applications to Oracle WebLogic Server. The use of this feature with older releases is important if specific dependencies exist between applications.
If you create a new domain in WebLogic Server 12.2.1.4.0, or upgrade an existing domain to 12.2.1.4.0, you can restore the WebLogic Server 12.1.3 deployment order behavior by disabling the following attributes of the DomainMBean
:
-
ParallelDeployApplications
: Determines whether applications are deployed in parallel. (This attribute is enabled by default.) -
ParallelDeployApplicationModules
: Determines whether the modules of applications are deployed in parallel. (This attribute is disabled by default.)
However, disabling the preceding attributes prevents you from being able to take advantage of the significant performance benefits of parallel deployment. Instead of disabling parallel deployment altogether in the domain you are upgrading to WebLogic Server 12.2.1.4.0, Oracle recommends checking to see whether the deployment ordering of any applications or modules has been customized, and if so, whether it is necessary.
See:
-
Enabling Parallel Deployment for Applications and Modules in Deploying Applications to Oracle WebLogic Server, which contains important considerations regarding application and module dependencies when using parallel deployment.
-
Change the server deployment order in Oracle WebLogic Server Administration Console Online Help, which explains how to view or change the deployment order of deployments using the WebLogic Server Administration Console.
Server Logging Bridge
The Server Logging Bridge provides a lightweight mechanism for applications that currently use Java Logging or Log4J Logging to have their log messages redirected to WebLogic logging services. As of WebLogic Server 12.1.3, the Server Logging Bridge is added to the root logger of the java.util.logging
Logger tree when WebLogic Server starts. Therefore, you no longer need to explicitly configure the Server Logging Bridge.
If you have configured the weblogic.logging.ServerLoggingHandler
as described in Server Logging Bridge in Configuring Log Files and Filtering Log Messages for Oracle WebLogic Server:
-
If
weblogic.logging.ServerLoggingHandler
is attached to the root logger, Oracle strongly recommends that you remove it from yourlogging.properties
file. -
If
weblogic.logging.ServerLoggingHandler
is attached to a logger other than the root, Oracle strongly recommends that you either remove it from thelogging.properties
configuration, or set theuseParentHandlers
attribute tofalse
(for example,com.foo.barUseParentHandlers=false
).
These situations also apply to Log4J. However, the terminology is different:
-
weblogic.logging.log4j.ServerLoggingAppender
is the bridge for Log4J. -
useParentHandlers
is calledAdditivity
in Log4J. It is configured aslog4j.additivity.com.foo.bar=false
in the log4j.properties file.
Oracle Database Drivers
As of release 12.1.2, WebLogic Server installation includes the Oracle Database 12c drivers.
This requires the following changes to your applications:
-
Replace references to
wlserver/server/lib/ojdbc6.jar
with${MW_HOME}/oracle_common/modules/features/com.oracle.db.dbc7-no-dms.jar
. Note that this is automatically included in the class path when usingweblogic.jar
. -
Replace references to
wlserver/server/lib/aqapi.jar
with${MW_HOME}/oracle_common/modules/oracle.jdbc_12.1.0/aqapi.jar
, which also requires that you usecom.oracle.db.jdbc7-no-dms.jar
.
If you want to continue running with the Oracle Database 11g driver JARs, you must:
-
add them to the front of the classpath
-
move the Oracle Database 12c driver JARs out of the
MW_HOME/oracle_common/modules/oracle.jdbc_12.1.0
directory.
Oracle Enable JavaNet FastPath
Oracle Enable JavaNet Fastpath enables the Oracle JDBC JavaNet Fastpath to reduce data copies and fragmentation. As of WebLogic Server 12.1.3, this attribute is no longer supported in the WebLogic Server Administration Console.
In previous versions of WebLogic Server, you could configure the Oracle Enable JavaNet FastPath attribute on the Configuration:Oracle tab in the WebLogic Server Administration Console. To go to the Configuration:Oracle tab, click Domain Structure, click Services, and then click Data Sources in the WebLogic Server Administration Console.
Maximum POST Size
A new session descriptor, max-save-post-size
, has been added in WebLogic Server 12.1.2, which may impact existing applications. This descriptor sets the maximum size, in bytes, of the POST that is saved or buffered by the application container during FORM authentication.
The default value of the max-save-post-size
descriptor is 4096 bytes.
If your application posts a form for which the size exceeds 4096 bytes during FORM authentication, you must increase max-save-post-size
to an appropriate value. Otherwise, a MaxPostSizeExceededException
occurs in the browser.
WLDF Schema Upgrade
If you are using a JDBC-based store for WebLogic Diagnostics Framework (WLDF) event and harvester data, you must update or recreate the WLDF tables in your database.
In the wls_events
table, change the THREADNAME
column from varchar(128)
to varchar(250)
. In the wls_hvst
table, add the column WLDFMODULE varchar(250) default NULL
.
This upgrade applies only to WebLogic Server standalone installations. For installations that include Fusion Middleware products, the schema upgrade process is done through the Oracle Upgrade Assistant.
See Configuring a JDBC-Based Store in Configuring and Using the Diagnostics Framework for Oracle WebLogic Server.
jdbc-connection-timeout-secs Element Has Been Removed
jdbc-connection-timeout-secs
element in the weblogic.xml
deployment descriptor has been removed in WebLogic Server 12.1.2. If your application configures the jdbc-connection-timeout-secs
element, you must remove it from the weblogic.xml
deployment descriptor to prevent deployment of the application from failing.
Commitment of Local Transactions
-
-Dweblogic.datasource.endLocalTxOnNonXAConWithCommit=false
can be used to avoid one extra DBMS round-trip with non-XA connections, for applications that are trusted to always complete their transaction explicitly. If this parameter is set tofalse
, local transactions on non-XA connections are implicitly committed or rolled back when a connection pool is closed, according to what the particular JDBC driver being used does whensetAutoCommit(true)
is called. Per the JDBC specification, that action is to commit the transaction, but there is varied compliance among drivers. By default, or if the property is set totrue
, these transactions are now committed. -
-Dweblogic.datasource.endLocalTXOnXAConWithCommit=true
can be used to commit local transactions on XA connections when a connection pool is closed. By default, these transactions are rolled back.
JVM Settings
The Java virtual machine (JVM) is a virtual execution engine instance that executes the bytecodes in Java class files on a microprocessor. How you tune your JVM affects the performance of WebLogic Server and your applications.
After you upgrade to Oracle WebLogic Server 12.2.1.4.0, you may have to reconfigure some of the JVM settings. Review the following topics and change the settings as required:
Setting the Location of the Java Endorsed Directory
In the following situations, you do not need to manually set the location of the Java endorsed directory or directories:
-
you are using JDK8.
-
you are using one of the JDKs that is installed with WebLogic Server 12.1.1.
-
you are using WLS 12c domains and start scripts that were generated by domain creation via the WebLogic Server 12c Configuration Wizard, or your start scripts reference
commEnv.cmd/sh
as installed by the WebLogic Server installer, or both.
If none of these situations apply, and any one of the following situations apply, you must manually set the location of the Java endorsed directory in the command you use to start your Managed Servers:
-
you are using Node Manager to start your Managed Servers, but you are not using a start script, that is
startScriptEnabled=false
. Note that as of WebLogic Server 12.1.1, the default value forstartScriptEnabled
istrue
. -
you are using custom start scripts, that is, start scripts that are not provided by Oracle.
-
you are trying to create an empty domain using
java.weblogic.Server
.
In any of these cases, include the java.endorsed.dirs
parameter in the Managed Server startup command.
startWeblogic.sh -Djava.endorsed.dirs=
WL_HOME
/endorsed
To specify multiple Java endorsed directories, separate each directory path with a colon (:).
Note:
In all of the options described in this section, you must replace WL_HOME
with the full path to your WebLogic Server installation.
You can also specify this value when calling startServer
by passing the values as jvmArgs
, or when calling nmstart
by passing them as properties, such as:
wls:/nm/mydomain> prps = makePropertiesObject("Arguments=-Djava.endorsed.dirs=/
WL_HOME
/endorsed")
wls:/nm/mydomain> nmStart("AdminServer",props=prps)
If you are using Node Manager to start the Managed Server, you can include the -Djava.endorsed.dirs=/
WL_HOME
/endorsed")
parameter in the ServerStartMBean's arguments
attribute, either using WLST or the WebLogic Server Administration Console. If using the WebLogic Server Administration Console, enter this parameter in the Arguments field on the server's Configuration > Server Start tab. This attribute will be applied when you call start(server_name 'Server')
from a WLST client that is connected to the Administration Server or when you click on the Start button for the server in the WebLogic Server Administration Console.
Using MaxMetaSpaceSize
Java classes have an internal representation within Java Hotspot VM and are referred to as class metadata. In previous releases of Java Hotspot VM, the class metadata was allocated in the so called permanent generation. In JDK 8, the permanent generation was removed and the class metadata is allocated in native memory.
The amount of native memory that can be used for class metadata is by default unlimited. Use the option MaxMetaspaceSize
to put an upper limit on the amount of native memory used for class metadata. See Class Metadata in Java Platform, Standard Edition HotSpot Virtual Machine Garbage Collection Tuning Guide.
Node Manager startScriptEnabled Default Value
As of WebLogic Server 12.1.1, the default value for startScriptEnabled
has been changed to true
. In all previous releases, the default was false
. If you do not want to use a start script with Node Manager, change this value to false
after upgrading.
Enterprise Java Beans (EJBs)
As of WebLogic Server 12.1.1, support for JPA 2.0 is built in. JPA 2.0 includes improvements and enhancements to domain modeling, object/relational mapping, EntityManager
and Query
interfaces, and the Java Persistence Query Language (JPQL), and more. See Setting the Default Provider for the Domain in Developing Enterprise JavaBeans for Oracle WebLogic Server.
WebLogic Server 8.1 Web Services Stack Has Been Removed
In WebLogic Server 12.1.1 release, the WebLogic Server 8.1 Web services stack has been removed. Therefore, WebLogic Server 8.1 Web services applications will no longer work.
Oracle recommends that you upgrade such applications to the WebLogic JAX-RPC or JAX-WS stacks, as described in Upgrading an 8.1 WebLogic Web Service to the WebLogic JAX-WS Stack.
Universal Description and Discover (UDDI) Registry Has Been Removed
In WebLogic Server 12.1.1 release, UDDI has been removed.
If you are still using UDDI and want to upgrade to WebLogic Server 12.1.1, Oracle recommends that you migrate to the Oracle Service Registry (OSR). OSR UDDI 3.0 compliant.
Certicom SSL Implementation Has Been Removed
In WebLogic Server release 12.1.1, the Certicom SSL implementation has been removed.
This change may require you to update system properties and debug switches as described in Command Line Properties for Enabling SSL Debugging and System Property Differences Between the JSSE and Certicom SSL Implementations in Administering Security for Oracle WebLogic Server.
Oracle Coherence Version
The WebLogic Server 12.1.1 installer includes Coherence 3.7.1. All servers in a cluster must use the same version of Coherence. Therefore, all cache servers in the cluster must be upgraded to Coherence 3.7.1.
Deprecated and Obsolete Web Application Features
See the list of Web application features that have been deprecated from, or are no longer supported in, Oracle WebLogic Server 12.1.1.
-
Information about deprecated functionality in Oracle WebLogic Server 11g Release 1 can be found on My Oracle Support at
https://support.oracle.com/
.In the Search Knowledge Base field, enter document ID
888028.1
. -
Information about functionality that is deprecated in Oracle WebLogic Server 12.1.1 can be found on My Oracle Support at
https://support.oracle.com/
. Search for Deprecated Features.
Evaluation Database Changed From PointBase to Derby
As of WebLogic Server 10.3.3, the evaluation database available from the WebLogic Server installation program has been changed from PointBase to Apache Derby.
If you select the Evaluation Database option on the Choose Products and Components screen, the Derby database is installed in the WL_HOME\common\derby
directory. If you select a Typical installation, Derby is installed by default.
DataSource Profile Logging
ONS Debugging
Oracle Type 4 JDBC Drivers From DataDirect
Oracle recommends reviewing DataDirect documentation for detailed information about driver behavior. See Progress DataDirect for JDBC User's Guide Release 5.1 and Progress DataDirect for JDBC Reference Release 5.1 at http://www.datadirect.com/index.html
.
Default Message Mode Has Changed
Changes to org.apache.commons.fileupload.disk.DiskFileItem Java Class
In Oracle WebLogic Server Patch Set Update (PSU) version 10.3.6.0.1610180 and later, the Java class org.apache.commons.fileupload.disk.DiskFileItem
in the Weblogic Server bundled Apache Commons FileUpload jar file is changed, and no longer implements java.io.Serializable
in order to prevent the potential security vulnerability. When an application tries to serialize this type of object, it fails with java.io.NotSerializableException
.
For information about the security vulnerabilities of Apache Commons FileUpload, see Apache Commons FileUpload Security Vulnerabilities.
After you upgrade to Oracle WebLogic Server 12.2.1.4.0, you can either modify your application to stop serializing the org.apache.commons.fileupload.disk.DiskFileItem
object, or configure the Filtering Class Loader to specify the problematic package to be loaded from your application. For information about configuring the Filtering Class Loader, see My Oracle Support document ID 1163020.1 "How to Configure Filtering Class Loader in Weblogic.xml?".
Limitation on the Size of JSP Files
The Java Virtual Machine (JVM) limits the amount of code to 65536 bytes per Java method, post upgrade. Therefore, when redeploying applications after upgrading to Oracle WebLogic Server 12.2.1.4.0, if the JSP files are embedded with too many scriptlets, the compiler fails to optimize the code, causing the deployment to fail with CompilationException
.
When you run into such issues, reduce the size of the JSP files with minimal scriplets and redeploy the application.
Modifications to SSLMBean
SSLMBean
has been modified to support additional SSL configuration capabilities, including the ability to enable or disable the JSSE adapter. See the following topics:
-
For a list of the differences in the way the JSSE SSL implementation handles the WebLogic system properties, see System Property Differences Between the JSSE and Certicom SSL Implementations in Administering Security for Oracle WebLogic Server.
-
For information about SSL support in WebLogic Server, see SSL: An Introduction in Understanding Security for Oracle WebLogic Server.
-
For information about JSEE, see Java Secure Socket Extention (JSEE) Reference Guide.
New Web Services Features
Oracle WebLogic Server 10.3.3 added several new Web services features, such as support for Web services atomic transactions, enhanced support for clustered environments, the ability to attach Oracle WSM policies to WebLogic Web services using Fusion Middleware Control, and more.
The following new features have been added in WebLogic Server as of release 10.3.3:
-
Support for Web services atomic transactions: WebLogic Web services enable interoperability with other external transaction processing systems, such as WebSphere, JBoss, Microsoft .NET.
-
Enhanced support for Web services in a clustered environment
-
Enhanced monitoring of Web services and clients
-
Attachment of Oracle WSM policies to WebLogic Web services using Fusion Middleware Control
-
EclipseLink DBWS support for declarative Web service solution for accessing relational databases
-
Method-Level policy attachment behavior change: Before WebLogic Server 10.3.3, if a policy was attached, through the WebLogic Server Administration Console, to a method of one Web service, the policy was also attached to all methods of the same name for all Web services in that module. As of WebLogic Server 10.3.3, the policy is attached only to the method of the appropriate Web service.
-
policy:
prefix now removed from OWSM policy names -
Web services WSDL tab now removed: Before WebLogic Server 10.3.3, you could view the WSDL for the current Web service by selecting the Configuration > WSDL tab. The WSDL tab has been removed as of WebLogic Server 10.3.3.
-
New development tools: Oracle JDeveloper and Oracle Enterprise Pack for Eclipse (OEPE)
-
Integration with Oracle Enterprise Manager Fusion Middleware Control
-
Support for Oracle WebLogic Services Manager (WSM) security policies
-
Support for WS-SecureConversation 1.3 on JAX-WS and MTOM with WS-Security on JAX-WS
Introduction of JSSE
As of WebLogic Server 10.3.3, Java Secure Socket Extension (JSSE) was introduced as an SSL implementation. JSSE is the Java standard framework for SSL and TLS and includes both blocking-I/O and non-blocking-I/O APIs, and a reference implementation including several commonly-trusted CAs.
Performance Enhancements for Security Policy Deployment
However, if your custom deployable Authorization or Role Mapping providers do not support parallel calls, you must disable the parallel security policy and role modification and instead enforce a synchronization mechanism that results in each application and module being placed in a queue and deployed sequentially. You can turn on this synchronization enforcement mechanism from the WebLogic Server Administration Console or by using the DeployableProviderSynchronizationEnabled
and DeployableProviderSynchronizationTimeout
attributes of the RealmMBean.
See Enabling Synchronization in Security Policy and Role Modification at Deployment in Administering Security for Oracle WebLogic Server .
ActiveCache
Class Caching
-
Server startup time is reduced.
-
The package level index reduces search time for all classes and resources.
Class caching is supported in development mode when starting the server using a startWebLogic
script. Class caching is disabled by default and is not supported in production mode. The decrease in startup time varies among different JRE vendors. See Class Caching With the Policy Classloader in Developing Applications for Oracle WebLogic Server.
Deprecated JDBC Drivers
The WebLogic Type 4 JDBC driver for Oracle and Sybase JConnect 5.5 and 6.0 drivers are deprecated.
-
WebLogic Type 4 JDBC driver for Oracle
This driver was deprecated in WebLogic Server 10.3 and is now removed. Instead of using this deprecated driver, use the Oracle Thin Driver that is provided with WebLogic Server. For details about the Oracle Thin Driver, see JDBC Drivers Installed with WebLogic Server in Administering JDBC Data Sources for Oracle WebLogic Server.
-
Sybase JConnect 5.5 and 6.0 drivers
These drivers are removed from WebLogic Server as of release 10.3.3 due to an Oracle security policy regarding default installation of code samples. You can download the driver from Sybase or you can use the Oracle-branded JDBC driver for Sybase that is packaged with WebLogic Server.
Changes to weblogic.jms.extension API
weblogic.jms.extensions.WLMessage
interface are removed from Java API Reference for Oracle WebLogic Server. These methods include the following:
public void setSAFSequenceName(String safSequenceName); public String getSAFSequenceName(); public void setSAFSeqNumber(long seqNumber); public long getSAFSeqNumber();
Your applications should not use these internal methods. Internal methods may change or be removed in a future release without notice.
Persistent Store Updates
Oracle Internet Directory and Oracle Virtual Directory Authentication Providers
As of WebLogic Server 10.3.2, two new LDAP authentication providers, the Oracle Internet Directory Authentication Provider and the Oracle Virtual Directory Authentication Provider, are added to WebLogic Server. These authentication providers can store users and groups in and read users and groups from the Oracle Internet Directory and Oracle Virtual Directory LDAP servers, respectively.
For information about configuring and using these new security providers, see Configuring LDAP Authentication Providers in Administering Security for Oracle WebLogic Server.
CapacityIncrement Attribute
As of WebLogic Server 10.3.1, the CapacityIncrement
attribute of the JDBCConnectionPoolMBean
is no longer configurable and is set to a value of 1.
Middleware Home Directory
<drive:>Oracle/Middleware
. This change has the following impact on WebLogic Server:
-
A new environment variable is introduced in several WebLogic scripts in 10.3.1 to represent the Middleware Home directory:
MW_HOME
. The directory to which this variable is set generally is the same asBEA_HOME
, which is also still used in WebLogic Server scripts. -
By default, the WebLogic Server installation program selects
<drive:>Oracle/Middleware
as the root product installation directory. However, if a directory containing an existing WebLogic Server installation is detected, that directory is selected instead by default. -
The WebLogic Server 10.3.1 documentation now uses the term
Middleware Home
, instead of BEA Home. However, this revision is functionally only a change in terminology. This revision does not imply that any WebLogic software, custom domains, or applications must be moved, or that any existing environment variables that represent those locations must be changed.
This change does not affect any existing WebLogic Server installations, custom domains, applications, or scripts on your computer. You can continue to use the BEA_HOME
environment variable as before.
Resource Registration Name
See Registering an XAResource to Participate in Transactions in Developing JTA Applications for Oracle WebLogic Server.
Servlet Path Mapping
As of version 2.3 of the Java Servlet Specification, two additional characters, /
and *
, can be used to define mappings.
-
A servlet path string that contains only the
/
(slash) character indicates the default servlet of the application. The servlet path resolves to the request URI minus the context path. In this case, the path resolves tonull
. -
A string that begins with an
*
(asterisk) specifies an extension mapping.
These changes introduce a change in behavior with the following HttpServletRequest
methods:
-
getPathInfo
-
getServletPath
To illustrate the change in behavior, consider the request /abc/def.html
that resolves to ServletA:
-
If
/
maps to ServletA, thenservletPath="abc/def.html"
andpathInfo=null
. -
If
/*
maps to ServletA, thenservletPath=""
andpathInfo="abc/def.html"
.
To ensure that the path information returned is non-null, replace all occurrences of the /
(slash) servlet mapping string with /*
.
If you define a servlet using both the @WebServlet
annotation and the <servlet>
element of the web.xml
deployment descriptor file, you must make sure that the servlet name you specify is the same in both locations. If the names do not match, then an exception is generated that prevents the application from starting. This requirement was not enforced in versions of WebLogic Server 12c before 12.2.1.0.
You can download the Java Servlet Specification from the following location:
http://www.oracle.com/technetwork/java/javaee/servlet/index.html