Compatibility Statement for WebLogic
Server 6.1
BEA attempts to
support binary and source-level compatibility between WebLogic Server 6.1SP1 and
WebLogic Server 6.0SP2 in the areas of persistent data, generated classes,
and API compatibility. In some cases, it is impossible to avoid
incompatibilities. Where incompatibilities arise, they are fully documented
within this compatibility statement.
Note: When migrating applications from earlier
versions of WebLogic Server, please refer to the Migration Guide.
Persistent Data Compatibility
WebLogic Server 6.1
does not require you to make any changes to WLS 6.0 persistent data storage,
including configuration files, deployment descriptors, and JMS messages, with
the following exceptions:
- In WebLogic Server 6.0, the JMS
documentation correctly specifies "default", "true",
and "false" for the StoreEnabled attribute of the
JMSDestinationMBean, but the software allowed for mixed case characters.
WLS 6.1, however, requires all lower case characters for the
StoreEnabled settings.
- The EJB 2.0 implementation in WLS 6.0 was based
on the EJB 2.0 specification PFD 1. The EJB 2.0 implementation in WLS
6.1 is based on the EJB 2.0 specification PFD 2. Some changes made to
the specification may require code changes to applications based on the
WLS 6.0 EJB 2.0 implementation.
Generated Classes Compatibility
WebLogic Server 6.1
does not require you to recompile applications in order to create new
generated classes with the following exceptions:
- EJBs deployed on earlier versions of WLS
need to be recompiled using the EJBC compiler. If you attempt to deploy
EJBs compiled with earlier versions, the server will automatically
recompile the EJBs and keep a cached copy of the new generated classes
on disk. To avoid having the server recompile your EJBs every time the
application is deployed on a new machine, you should manually recompile
you EJBs using the EJBC compiler.
- JSPs that have been compiled using a
previous version of WLS will be recompiled in WLS 6.1.
API Compatibility
API method behavior
may change because that behavior was corrected to conform to a specification
or to fix incorrect behavior. In certain circumstances, this correction may
cause your application to behave differently. WLS 6.0 applications deployed
on WebLogic Server 6.1 will function without modification with the following
exceptions:
- The EJB 2.0 implementation in WLS 6.0 was
based on the EJB 2.0 specification PFD 1. The EJB 2.0 implementation in
WLS 6.1 is based on the EJB 2.0 specification PFD 2. Some changes made
to the specification may require code changes to applications based on
the WLS 6.0 EJB 2.0 implementation.
- In WLS 6.0, the Servlet container
automatically attempts to authenticate users when forwarded to a
different location using RequestDispatcher.forward(). The Servlet 2.3
specification has added a clause that prevents authentication on
forward. WLS 6.1 has been updated to comply with the Servlet 2.3
specification. The check-auth-on-forward property can be set in the
weblogic.xml Web Application deployment descriptor to revert this
behavior back to that of WLS 6.0. See weblogic.xml
Deployment Descriptor for details.
- Access to WLS Management Beans (MBeans) is
now controlled by an ACL. This ACL does not affect MBeans access for the
server or "system" user. See the Defining ACLs section of the Administration
Guide for details on setting this ACL.
- In WLS 6.1, the default XML parser has been
updated and is now based on the Apache Xerces 1.3.1 parser. The parser
implements version 2 of the SAX and DOM interfaces. Users who have used
older parsers that were shipped in previous versions may receive
deprecation messages. Users who prefer to use external parsers should do
so through JAXP. Migration of non-JAXP code to JAXP code may involve
some code adjustments.
- In WLS. changes to Apache's Xalan code
were made to enable Xerces and Xalan to work together. You may encounter
problems if you use Xalan from Apache, because it will not include these
changes.
- Validation in the WLS default parser is
more strict than in previous versions. This may require XML coding
changes.
- The ServletRuntime MBean
(weblogic.management.descriptors.webapp.ServletMBean) contains the
method
getName(). In WSL 6.0, this method returned the
name of the Servlet. For all other MBeans, the getName() method returns the name of the MBean. For
consistency, in WLS 6.1 the getName() method on the ServletRuntime MBean has
been modified to return the name of the MBean. A new method, getServletName(), has been added to the ServletRuntime
MBean to return the name of the Servlet
Protocol Compatibility
WebLogic Server 6.1
does not interoperate with prior versions of WebLogic Server at the wire
protocol level. The includes the following restrictions:
- WebLogic Server 6.1 cannot be a member of
a cluster that contains servers of a previous version.
- WebLogic Server 6.1 cannot act as an
Administration Server or Managed Server to a server of a previous
version.
- A pre-6.1 web server plug-in cannot be
configured as a proxy to WebLogic Server 6.1.
- Bi-directional communication between
WebLogic Server 6.1 and previous versions is not supported.
Server Compatibility with Service
Packs
The Administration Server must be at the same Service Pack Level or higher than its Managed Servers.
For instance, if the Managed Server is at WebLogic 6.1
Service Pack 1, then the Administration Server can be running Service Pack 1 or Service Pack 2. However, if the Managed
Server is at Service Pack 2, then the Administration Server must be at Service Pack 2 or higher.
Service Pack 2
includes a fix required for WebLogic Server to conform fully to the IIOP
specification. As a result of this fix, a 6.1 Service Pack 2 server will not
be able to interoperate either with a 6.1 GA server or a 6.1 Service Pack 1
server. Therefore, BEA strongly recommends you upgrade all of your WebLogic
6.1 servers to 6.1 Service Pack 2, if you are using the IIOP transport
protocol for communication between servers.
|
