This document contains information on the following topics:
This document is intended to track incompatibility between adjacent product releases and configuration options that may result in incompatibility with the product specifications. For example, this compatibility page details Sun Java System Application Server Platform Edition 8 incompatibility with Sun Java System Application Server Platform Edition 7, J2EE 1.4 incompatibility with the J2EE 1.3 release, and Sun Java System Application Server Platform Edition 8 compatibility with the J2EE 1.4 specification. Our intention is to update this document as information becomes available. Check back frequently for updates or changes to this document.
For abbreviation of text in this document, the Sun Java System Application Server Platform Edition 8 will occasionally be referred to as Application Server PE 8, and the Sun Java System Application Server Platform Edition 7 will occasionally be referred to as Application Server PE 7.
See also: Java 2 Platform, Standard Edition, Version 1.4.2: Compatibility with Previous Releases
The Sun Java System Application Server Platform Edition 8 is upward binary-compatible with Sun Java System Application Server Platform Edition 7 except for the incompatibilities noted below. J2EE applications that run on version 7 will continue to work on version 8 except for the incompatibilities noted below.
The topics discussed in this section include incompatibilities in the following areas:
The Sun Java System Application Server Platform Edition 8 replaces the Web server shipped with Sun Java System Application Server Platform Edition 7 with a Java-based Web container. As a result, the following Web server-specific features are no longer supported in version 8:
The package names of the security realm implementations have been
renamed from com.iplanet.ias.security.auth.realm
to
com.sun.enterprise.security.auth.realm
. Custom realms written using
the com.iplanet.*
classes must be modified.
In Application Server PE 7, the default value for the
optional attribute delegate
was false
.
In this release, this attribute defaults to true
.
This change means that by default the Web application classloader will first
delegate to the parent classloader before attempting to load a class
by itself.
In Application Server PE 7, users were able to specify the following system property to optionally turn on some ORB performance optimization:
-Djavax.rmi.CORBA.UtilClass=com.iplanet.ias.util.orbutil.IasUtilDelegate
The ORB performance optimization is turned on by default in Application Server PE 8. If you are using the system property reference above, you must remove it to avoid interfering with the default optimization.
Commands for the command line interface, asadmin
, are backward
compatible except as noted below:
Sub-commands not supported in Application Server PE 8 (may be supported in Sun Java System Application Server Standard Edition 8 and/or Enterprise Edition 8):
show-instance-status
create-instance
delete-instance
start-instance
stop-instance
restart-instance
list-instances
Sub-commands that are no longer supported in Application Server PE 8:
install-license
display-license
create-http-qos
delete-http-qos
create-mime
delete-mime
list-mime
create-authdb
delete-authdb
list-authdbs
create-acl
delete-acl
list-acls
Some dotted names used in get
/set
subcommands are not compatible.
See Mapping of Incompatible Dotted Names
for more details on this topic.
In Application Server PE 8, domain.xml
is the main server
configuration file. In Application Server PE 7, the main server
configuration file was server.xml
. The DTD of domain.xml
is found in lib/dtds/sun-domain_1_0.dtd
. The upgrade tool included in
Application Server PE 8 can be used to migrate the server.xml
from Application
Server 7 to domain.xml
for Application Server PE 8.
In general, the configuration file formats are NOT backward-compatible. The following configuration files are NOT supported:
*.conf
*.acl
mime.types
server.xml
(replaced with domain.xml
)
Application Server PE 8 uses Java Keystore (jks) as the keystore format. The NSS format used in Application Server PE 7 is not supported. The upgrade tool included in the product can be used to migrate existing NSS keystores to jks keystores.
As a general rule, tools are not interoperable between Application Server PE 7 and 8. Users must upgrade their Application Server PE 7 tools to work with Application Server PE 8.
The following use of dotted names in asadmin
get
and set
subcommands are NOT backward compatible:
server
instead of server1
server.<resource>
becomes domain.resources.<resource>
server.<app-module>
becauses domain.applications.<app-module>
poolResizeQuantity
is now pool_resize_quantity
The table below displays a one-to-one mapping of the incompatibilities in
dotted names between Application Server PE 7 and 8. The compatible dotted names are not listed in this
table. The text inside of <...>
should be replaced by the actual name of
the object. For example <server instance>
should be replaced with the actual
name of the server instance. Likewise <listener id>
should be replaced with the actual
listener id.
Application Server PE 7 dotted names |
Application Server PE 8 dotted names |
|
1. |
<server
instance>.http-listener.<listener
id> <server instance>.http-service.http-listener.<listener id> |
server.http-service.http-listener.<listener
id> server-config.http-service.http-listener.<listener id> |
2. |
<server instance>.orb <server instance>.iiop-service |
server.iiop-service server-config.iiop-service |
3. |
<server instance>.orblistener <server-instance>.iiop-listener |
server.iiop-service.iiop-listener.<listener
id> server-config.iiop-service.iiop-listener.<listener id> |
4. |
<server instance>.jdbc-resource.<jndi
name> |
server.resources.jdbc-resource.<jndi name> domain.resources.jdbc-resource.<jndi name> |
5. |
<server
instance>.jdbc-connection-pool.<pool
id> |
server.resources.jdbc-connection-pool.<pool
id> domain.resources.jdbc-connection-pool.<pool id> |
6. |
<server
instance>.external-jndi-resource.<jndi
name> <server instance>.jndi-resource.<jndi name> |
server.resources.external-jndi-resource.<jndi
name> domain.resources.external.jndi-resource.<jndi name> |
7. |
<server instance>.custom-resource.<jndi
name> |
server.resources.cutsom-resource.<jndi
name> domain.resources.custom-resource.<jndi name> |
8 *. |
<server instance>.web-container.logLevel |
server.log-service.module-log-levels.web-container server-config.log-service.module-log-levels.web-container |
9. * |
<server
instance>.web-container.monitoringEnabled |
server.monitoring-service.module-monitoring-levels.web-container server-config.monitoring-service.module-monitoring-levels.web-container |
10. |
<server
instance>.j2ee-application.<application
name> <server instance>.application.<application name> |
server.applications.j2ee-application.<application
name> domain.applications.j2ee-application.<application name> |
11. |
<server
instance>.ejb-module.<ejb-module
name> |
server.applications.ejb-module.<ejb-module
name> domain.applications.ejb-module.<ejb-module name> |
12. |
<server
instance>.web-module.<web-module
name> |
server.applications.web-module.<web-module
name> domain.applications.web-module.<web-module name> |
13. |
<server
instance>.connector-module.<connector
module name> |
server.applications.connector-module.<connector
module name> domain.applications.connector-module.<connector module name> |
14. |
<server
instance>.lifecycle-module.<lifecycle
module name> |
server.applications.lifecycle-module.<lifecycle
module name> domain.application.lifecycle-module.<lifecycle module name> |
15. |
<server instance>.virtual-server-class |
N/A |
16. |
<server
insatnce>.virtual-server.<virtual-server
id> |
server.http-service.virtual-server.<virtual
server
id> server-config.http-service.virtual-server.<virtual server id> |
17. |
<server instance>.mime.<mime id> |
N/A |
18. |
<server instance>.acl.<acl id> |
N/A |
19. |
<server
instance>.virtual-server.<virtual
server id>.auth-db.<auth-db id> |
N/A |
20. |
<server instance>.authrealm.<realm
id> <server instance>.security-service.authrealm.<realm id> |
server.security-service.auth-realm.<realm
id> server-config.security-service-auth-realm.<realm id> |
21. |
<server
instance>.persistence-manager-factory-resource.<jndi
name> <server instance>.resources.persistence-manager-factory-resource.<jndi name> |
server.resources.persistence-manager-factory-resource.<jndi
name> domain.resources.persistence-manager-factory-resource.<jndi name> |
22. |
<server instance>.http-service.acl.<acl
id> |
N/A |
23. |
<server instance>.mail-resource.<jndi
name> |
server.resources.mail-resource.<jndi name> domain.resources.mail-resource.<jndi name> |
24. |
<server instance>.profiler |
server.java-config.profiler server-config.java-config.profiler |
* - Rows #8 and #9 are the attribute names. In these instances, there is not a one-to-one relationship with the dotted names between Application Server PE 7 and 8.
The J2EE 1.4 Application Server release is upwards binary-compatible with J2EE SDK, v1.3 except for the incompatibilities listed below. This means that, except for the noted incompatibilities, applications built for version 1.3 will run correctly in the Sun Java System Application Server Platform Edition 8 release.
Downward source compatibility is not supported. If source files use new J2EE APIs, they will not be usable with an earlier version of the J2EE platform.
In general, the policy is that:
Maintenance releases do not introduce any new APIs, so they maintain source-compatibility with one another.
Functionality releases and major releases maintain upwards but not downwards source-compatibility.
Deprecated APIs are methods and classes that are supported only for backwards compatibility, and the compiler will generate a warning message whenever one of these is used, unless the -nowarn command-line option is used. It is recommended that programs be modified to eliminate the use of deprecated methods and classes, though there are no current plans to remove such methods and classes entirely from the system.
The JSun Java System Application Server Platform Edition 8 release is strongly compatible with previous versions of the J2EE platform. Almost all existing programs should run on the Sun Java System Application Server Platform Edition 8 release without modification. However, there are some minor potential incompatibilities that involve rare circumstances and "corner cases" that we are documenting here for completeness.
Java Servlet Specification Version 2.4 (http://java.sun.com/products/servlet/) ships with the Sun Java System Application Server Platform Edition 8 release. Version 2.3 of the specification shipped with the J2EE 1.3 SDK. The following items discuss compatibility issues between these releases.
HttpSessionListener.sessionDestroyed
In the previous versions of the specification, this method was defined
as: Notification that a session was invalidated
. As of this release, this method is changed to: Notification that a session is about to
be invalidated
so that it notifies before the session invalidation. If the code assumed the previous behavior, it must be modified to match the new behavior.
ServletRequest methods getRemotePort, getLocalName, getLocalAddr,
getLocalPort
The following methods are added in the ServletRequest
interface in this version of the specification. Be aware that this
addition causes source incompatibility in some cases, such as when a developer
implements the ServletRequest
interface. In this case, ensure that all the new methods are implemented:
public int getRemotePort()
returns the Internet Protocol (IP) source port of the client or last proxy that sent the request.
public java.lang.String getLocalName()
returns the host name of the Internet Protocol (IP) interface on which the request was received.
public java.lang.String getLocalAddr()
returns
the Internet Protocol (IP) address of the interface on which the request was
received.
public int getLocalPort()
returns the Internet Protocol (IP) port number of the interface on which the request was received.
Java Server Pages Specification 2.0 (http://java.sun.com/products/jsp/) ships with the Sun Java System Application Server Platform Edition 8 release. JSP Specification 1.2 shipped with the J2EE 1.3 SDK. Where possible, the JSP 2.0 Specification attempts to be fully backwards compatible with the JSP 1.2 Specification. In some cases, there are ambiguities in the JSP 1.2 specification that have been clarified in the JSP 2.0 Specification. Because some JSP 1.2 containers behave differently, some applications that rely on container-specific behavior may need to be adjusted to work correctly in a JSP 2.0 environment.
The following is a list of known backwards compatibility issues of which developers who use JSP technology should be aware:
Tag Library Validators that are not namespace aware and that rely solely on the prefix parameter may not correctly validate some JSP 2.0 pages. This is because the XML view may contain tag library declarations in elements other
than jsp:root
, and may contain the same tag library declaration more than once, using different prefixes. The uri
parameter should always be used by tag library validators instead. Existing JSP pages with existing tag libraries will not have any problems.
Users may observe differences in I18N behavior on some containers due primarily to ambiguity in the JSP 1.2 specification. Where possible, steps were taken to minimize the impact on backwards compatibility and overall, the I18N abilities of technology have been greatly improved.
In JSP specification versions previous to JSP 2.0, JSP pages in XML syntax ("JSP documents") and those in standard syntax determined their page encoding in the same fashion, by examining the pageEncoding
or contentType
attributes of their page directive, defaulting to ISO-8859-1 if neither was present.
As of the JSP Specification v2.0, the page encoding for JSP documents is determined as described in section 4.3.3 and appendix F.1 of the XML specification, and
the pageEncoding
attribute of those pages is only checked to make sure it is consistent with the page encoding determined as per the XML specification.
As a result of this change, JSP documents that rely on their
page encoding to be determined from their pageEncoding
attribute will no longer be decoded correctly. These JSP documents must be changed to include an appropriate XML encoding declaration.
Additionally, in the JSP 1.2 Specification, page encodings are determined on a per translation unit basis whereas in the JSP 2.0 Specification, page encodings are determined
on a per-file basis. Therefore, if a.jsp
statically includes
b.jsp
, and a page encoding is specified in a.jsp
but not in
b.jsp
, in the JSP 1.2 Specification a.jsp
's encoding is
used for b.jsp
, but in the JSP 2.0 Specification, the default encoding is used
for b.jsp
.
The type coercion rules (shown in Table JSP.1-11 in the JSP 2.0 Specification) have been reconciled with the EL coercion rules. There are some exceptional conditions that will no longer result in an exception in the JSP 2.0 Specification . In particular, when passing an empty String("")
to an attribute of a numeric type, a translation error or a NumberFormatException
used to occur, whereas in the JSP 2.0 Specification, a 0
will be passed in
instead. See the Table JSP.1-11 in the JSP 2.0 Specification for details. In general, this is not expected to cause any problems because these would have been exceptional conditions in the JSP 1.2 Specification and the specification allowed for these exceptions to occur at either translation time or request time.
The JSP container uses the version of web.xml
to determine
the default behavior of various container features. The following
is a list of items of which JSP developers should be aware when
upgrading their web.xml
from version Servlet 2.3 Specification to version Servlet
2.4 Specification.
EL expressions will be ignored by default in applications created with JSP 1.2 technology. When upgrading a Web application to the JSP 2.0 Specification, EL expressions will be interpreted by default. The escape sequence
\$
can be used to escape EL expressions that should not be interpreted by the container. Alternatively,
the isELIgnored
page directive attribute, or
the <el-ignored>
configuration element can be used to
deactivate EL for entire translation units. Users of JSTL 1.0 will need to either upgrade their taglib/
imports to the JSTL 1.1 URIs, or they will need to use the _rt
versions of the tags (e.g. c_rt
instead
of c
, or fmt_rt
instead of
fmt
).
Web applications that contain files with an extension
of .jspx
will have those files interpreted as JSP documents, by default. You can use the JSP configuration element <is-xml>
to
treat .jspx
files as regular JSP pages,
but there is no way to disassociate .jspx
from the JSP
container.
The escape sequence \$
was not reserved in the JSP 1.2 Specification. Any template text or attribute value that appeared as \$
in the JSP 1.2 Specification used to output \$
but will now output just $
.
The Sun Java System Application Server Platform Edition 8 is completely compatible with the Java 2 Platform, Enterprise Edition specification by default. All portable J2EE programs will run on the Application Server without modification. However, as allowed by the J2EE compatibility requirements, it is possible to configure applications to use features of the Sun Java System Application Server Platform Edition 8 that are not compatible with the J2EE specification. The following list documents these configuration options and the compatibility issues caused by using them.
When enterprise beans are assembled and deployed,
the pass-by-reference
element in the sun-ejb-jar.xml
file only applies to remote calls. As defined in the EJB 2.0 specification, section 5.4, calls to local interfaces use pass-by-reference semantics.
If the pass-by-reference flag is set to its default value
of false
, the passing semantics for calls to remote interfaces comply with the EJB 2.0 specification, section 5.4. If set to true
, remote calls involve pass-by-reference semantics instead of pass-by-value semantics, contrary to this specification.
Portable programs should not assume that a copy of the object is made during
such a call, and thus that it�s safe to modify the original. Nor should they assume that a copy is not made, and thus that changes to the object are visible to both caller and callee. When this flag is set to true
, parameters and return values should be considered read-only. The behavior of a program that modifies such parameters or return values is undefined.
More information on this item may be found at http://docs.sun.com/source/816-7151-10/deassemb.html#73093.
If the delegate
attribute in the class-loader
element of the sun-web.xml
file is set to its default value of false
, the classloader delegation behavior complies with the Servlet 2.3
specification, section 9.7.2. If set to true
, classes and resources residing in container-wide library JAR files are loaded in
preference to classes and resources packaged within the WAR file, contrary to what this specification recommends.
Portable programs that use this flag should not be packaged with any classes or interfaces that are a part of the J2EE specification. The behavior of a program that includes such classes or interfaces in its WAR file is undefined.
More information on this item may be found at http://docs.sun.com/source/816-7150-10/dwdeploy.html#48102.