Chapter 5 Java Enterprise System 2005Q1 Compatibility Information

A new release of the Sun Java™ Enterprise System software strives for compatibility with the previous release. However, there are always some differences in the compatibility level of the two releases. This section discusses the issues that might impact your deployment when you upgrade from Java Enterprise System 2003Q4 to Java Enterprise System 2005Q1.


Note	This information does not address operating system or runtime compatibility. Although the Sun Solaris operating system provides a compatibility guarantee, other vendors might not guarantee the same compatibility level across different third party components, such as other J2EE runtimes that are supported by component products. The compatibility issues addressed here concern only the Java Enterprise System and the interfaces that are exposed to customers.

Access Manager

Table 5-1 list the known incompatibilities between Access Manager 2005Q1 and earlier versions.

Table 5-1 Access Manager Compatibility
Incompatibility	Impact	Comments
Different user data presented in Access Manager when the user logs in via http://<server_name>:<port> /amconsole	the information displayed is changed compared to earlier releases. The following are not present any more: Employee Number: User Alias List Success URL Failure URL
The way of moving the attributes from “merge” to “default” have changed in the Access Manager GUI interface.	the information displayed is changed compared to earlier releases. the following are not present any more: This appears in configuration of SSO channels of Calendar Server and Mail Configuration settings of the channels are the same as before.	See the Sun Java System Access Manager Administration Guide (http://docs.sun.com/doc/817-7647) for updated information.
Incompatibilities in Access Manager when configuring the Instant Messaging channel.	There are missing two attributes “server” and “port” which are present in earlier versions of Identity Server: server - node3 port - 49999 You can add these attributes manually

Application Server

Table 5-2 list the known incompatibilities between Application Server 8.1 2005Q1 and earlier versions.

Table 5-2 Application Server 8.1 Compatibility Issues
Incompatibility	Impact	Comments
Application Server 8.1 is incompatible with the 2004Q2 versions of Portal Server and Access Manager.	Upgrade Portal Server and Access Manager when upgrading Application Server.
Sun Java System Application Server 7 does not work with J2SE 5.0	If necessary, install J2SE (1.4.2) and configure Sun Java System Application Server 7 to use that.
Installation directory has changed	Now /opt/SUNWappserver
Log/instance directory has changed	Now /var/opt/SUNWappserver	Automated log analysis may need updating
Domains directory has changed.	Now /var/opt/SUNWappserver/domains/domain1
Changes in asadmin commands (stop/start options, deploy, list-components, etc.)l	Stop/start options, deploy, list-components, etc.	Refer to the Application Server Administration Guide.
Change of “access” log files	The access log files are now in the following directory /var/opt/SUNWappserver/domains/domain1/logs/access with the names server_access_log __asadmin_access_log
The default port values have changed for application server.	These (new) values are used as defaults during installation. 4848 is now 4849 80 is now 8080 81 is now 8181

Instant Messaging

Table 5-3 list the known incompatibilities between Instant Messaging 7 2005Q1 and earlier versions.

Table 5-3 Instant Messaging 7 2005Q1 Compatibility Issues
Incompatibility	Impact	Comments
Instant Messaging 7 is incompatible with the 2004Q2 versions of Portal Server and Messaging Server.	Upgrade Portal Server and Messaging Server when upgrading Instant Messaging 7.
Due to a protocol change the Java ES 3 version of Instant Messaging server will not be able to communicate with a server of an older version.	Instant Messaging federated deployment sites will need to upgrade all the servers. The existing deployments who do not wish to upgrade the server will have to explicitly set the property of collaboration session factory object to use the legacy protocol implementation.
The IM SDK implementation of Legacy IM/Presence protocol is also now bundled	The default behavior of the IM SDK APIs will be to use the implementation based on the XMPP protocol. Applications will have to explicitly set the property of collaboration session factory object to use the Legacy protocol implementation.
The default multiplexor port has changed	Now 5222
The SDK component includes additional jar files: The IM SDK uses the JSO (JABBER Stream Objects) libraries.	This will require the modification of the classpath for older applications using the IM SDK and wish to take advantage of XMPP.
Federated deployments	Due to Protocol change the new version of the server will not be able to communicate with a server of the old version.	The sites will need to upgrade all the servers in a federated deployment. The upgrade must be coordinated in order to limit the length of time during which servers will be unable to communicate with each other.
Client - Server Communication	Due to the protocol change the older versions of the client will not be able to communicate with the newer versions of the server and vice versa.	The sites will need to upgrade both the client and server at the same time.
The default server port has changed.	It is now 45222
The default code base location for Instant Messaging has changed from http://<server_name:<port>/iim	It is now http://<server_name:<port>/im

Message Queue

This section covers issues you need to be aware of when migrating to Message Queue 3 2005Q1 from Message Queue 3.5 and 3.0.x versions. These issues fall into two general categories:

Platform Issues

Solaris


Note	Migration of Message Queue versions prior to 3.0.1 are not supported.

On the Solaris platform, you can install Message Queue 3 2005Q1 on top of Message Queue 3.0.x and 3.5 versions, and your previous instance data (configuration properties, flat-file persistent store, log files, flat-file user repository, and/or access control properties file) will be used by Message Queue 3 2005Q1 (see Compatibility Issues).

If you depended on jar files being in their 3.0.x locations, please note that these have been moved to the /usr/share/lib directory. This applies to the following .jar files: jms.jar, imq.jar, imqxm.jar, activation.jar, saaj-api.jar, saaj-impl.jar, mail.jar, commons-logging.jar, jaxm-api.jar, fscontext.jar.

Linux

On the Linux platform, you should migrate any prior Message Queue data before upgrading to Message Queue 3 2005Q1, and not try to install Message Queue 3 2005Q1 on top of existing versions. This is due to the fact that the installed directory structure has been changed for Message Queue 3 2005Q1, and this complicates the migration of instance data (configuration properties, flat-file persistent store, log files, flat-file user repository, and/or access control properties file) from Message Queue 3.0.x and 3.5 to Message Queue 3 2005Q1. The utility mqmigrate is provided to ease the migration of this data.

Script Compatibility

Scripts that use hard-coded paths to the previous Linux installation of Message Queue will need to be changed to the new location of Message Queue. If you need symbolic links that point the old locations to the new locations, you must install the sun-mq-compat RPM package. This package may not be supported in future releases.

Compatibility Issues

Protocol Compatibility

When using SUN ONE Web Server in cooperation with Message Queue via the imqhttp.war application you cannot upgrade only the Web Server component. Due to a protocol change, Message Queue has to be upgraded when upgrading earlier versions of Web Server in this circumstance.

Broker Compatibility

A Message Queue 3 2005Q1 broker will inter-operate with a Message Queue 3.0.x or 3.5 broker, however changes have been made in broker properties and the persistent store schema. Some Message Queue 3.0.x data is compatible with Message Queue 3 2005Q1, as shown in Table 5-4, and can be used after migrating to Message Queue 3 2005Q1.

Message Queue 3.5 data is generally compatible with Message Queue 3 2005Q1, and can be used after migrating to Message Queue 3 2005Q1.

When migrating from Message Queue 3.0.x or 3.5 to Message Queue 3 2005Q1, you should consider the following:

You can use Message Queue 3.0.x or 3.5 config.properties files, or you can copy them to another location and consult the property settings they contain when you configure Message Queue 3 2005Q1 brokers.

Any persistent Message Queue 3.0.x or 3.5 data—messages, destinations, durable subscriptions—is automatically converted to Message Queue 3 2005Q1 data when starting up a Message Queue 3 2005Q1 broker for the first time. For example, any existing Message Queue 3.0.x or 3.5 destinations will be converted to Message Queue 3 2005Q1 destinations, preserving existing attributes and using default values of new attributes.



Note	The following information applies to Message Queue 3.0.x migration only. For Message Queue 3.5, the conversion is minor, transparent and compatible.

The automatic migration of persistent data leaves the Message Queue 3.0.x data intact. You can delete this data by using the following option when starting up the Message Queue 3 2005Q1 broker for the first time:

imqbrokerd -upgrade-store-nobackup

If you do not use this option, you should delete the old persistent store manually:

For a built-in (flat file) data store, delete the old persistent store, located at

…/instances/instanceName/filestore/

For a plugged-in (JDBC-compliant) data store, delete the old tables using the following command:

imqdbmgr delete oldtbl



Note	When you migrate persistent data from Message Queue 3.0.x to Message Queue 3 2005Q1, the migrated data can no longer be used by a Message Queue 3.0.x broker. If this is a concern, save the old persistent data to a secure location instead of deleting it as directed above.

Note: Applies to Message Queue 3.0.x only. You can continue to use the Message Queue 3.0.x user repository and access control properties files after installing Message Queue 3 2005Q1, however these files have been made instance-specific and are now placed in the …/instances/instanceName/etc directories. The Message Queue 3 2005Q1 installer does not overwrite the Message Queue 3.0.x files. When you first start up a Message Queue 3 2005Q1 broker, copies of the Message Queue 3.0.x files are placed in the appropriate Message Queue 3 2005Q1 location (see the Message Queue Administration Guide, Appendix A). If Message Queue 3.0.x user repository and access control properties files are not found at the old location, new files will be created in the …/instances/instanceName/etc directory.

If you mix Message Queue 3.0.x or 3.5 brokers and Message Queue 3 2005Q1 brokers in a cluster, the master broker must be a Message Queue 3.0.x or 3.5 broker (whichever is older), and the cluster will run as a Message Queue 3.0.x or 3.5 cluster.

Table 5-4 Compatibility of Message Queue 3 2005Q1 with Message Queue 3.0.x Data
Message Queue 3.0.x Data Category	Location of Message Queue 3.0.x Data	Compatibility with Message Queue 3 2005Q1
Broker properties	IMQ_VARHOME/instances/instanceName/ props/config.properties	New properties have been added, and some property names have changed. Old property names are still recognized.
Persistent store: messages, destinations, durable subscriptions	IMQ_VARHOME/instances/instanceName/ filestore/ or JDBC-accessible data store	Converted to Message Queue 3 2005Q1 format when Message Queue 3 2005Q1 broker is started for the first time. The persistent store is at IMQ_VARHOME/instanceName/fs350
Security: flat-file user repositories	/etc/imq/passwd (Solaris) IMQ_HOME/etc/passwd (other platforms)	Compatible. File automatically copied to following location at first broker startup: …/instances/instanceName/etc/ passwd
Security: access control file	/etc/imq/accesscontrol.properties (Solaris) IMQ_HOME/etc/accesscontrol.properties (other platforms)	Compatible. File automatically copied to following location at first broker startup: …/instances/instanceName/etc/ accesscontrol.properties

Administered Object Compatibility

Message Queue 3 2005Q1 administered objects have been enhanced with new attributes and some Message Queue 3.0.x and 3.5 attributes have been renamed. Therefore, when migrating from Message Queue 3.0.x or 3.5 to Message Queue 3 2005Q1, you should consider the following:

You can use the same object store and administered objects that you created in Message Queue 3.0.x or 3.5; however, it is best to upgrade your administered objects after installing Message Queue 3 2005Q1. The Administration Console (imqadmin) and the ObjectManager command line utility (imqobjmgr), when performing an update operation, will convert Message Queue 3.0.x and 3.5 administered objects into Message Queue 3 2005Q1 administered objects.

The Message Queue 3 2005Q1 client runtime will look up and instantiate Message Queue 3.0.x and 3.5 administered objects and convert them for use by Message Queue 3 2005Q1 clients. However, this will not convert Message Queue 3.0.x and 3.5 administered objects residing in the object store from which the lookup was made.

Existing Message Queue 3.0 and 3.5 clients (applications and/or components)—that is, clients that directly instantiate administered objects—are compatible with Message Queue 3 2005Q1. However, if they are to use the new administered object attributes (see Chapter 2 of the Message Queue Developer’s Guide for Java Clients, http://docs.sun.com/doc/819-0068 and Chapter 16 of the Message Queue Administration Guide, http://docs.sun.com/doc/819-0066 for information on administered object attributes), they will need to be rewritten. (Re-compiling Message Queue 3.0.x and 3.5 clients with Message Queue 3 2005Q1 will show which Message Queue 3.0.x and 3.5 attributes have been renamed in Message Queue 3 2005Q1. The old names will still work.)

Scripts that start Java clients and which set administered object attribute values using command line options are compatible with Message Queue 3 2005Q1. However, if they are to use the new administered object attributes (see Chapter 2 of the Message Queue Developer’s Guide for Java Clients, http://docs.sun.com/doc/819-0068 and Chapter 16 of the Message Queue Administration Guide, http://docs.sun.com/doc/819-0066 for information on administered object attributes), they will need to be rewritten.

Administration Tool Compatibility

Because of the addition of new commands and new administrative capabilities, the Message Queue 3 2005Q1 administration tools (the Administration Console and command line utilities) only work with Message Queue 3 2005Q1 brokers. However, all Message Queue 3.0.x and 3.5 commands and command options remain supported.

Client Compatibility

When upgrading from Message Queue 3.0.x or 3.5 to Message Queue 3 2005Q1, you should consider the following, regarding Java clients:

A Message Queue 3 2005Q1 broker will support a Message Queue 3.0.x or 3.5 client (but without additional Message Queue 3 2005Q1 capabilities).

A Message Queue 3 2005Q1 Java client can connect to a Message Queue 3.0.x or 3.5 broker (but without additional Message Queue 3 2005Q1 capabilities).

Java clients built on JDK 1.3 or 1.4 can inter-operate with a broker running JRE 1.4. However, clients that use a secure (SSL-based) connection to a broker will require additional JSSE and JNDI libraries if they are not built on JDK 1.4 (which includes these libraries). These libraries are provided on each platform as follows:

on Solaris, in the SUNWiqsup package, which is not installed by default

on Linux, in the sun-mq-sup RPM package, which is not installed by default.

on Windows, as part of a custom installation

C client programs cannot connect to a Message Queue 3.0.x broker; they are supported only by Message Queue 3.5, 3.5 SPx, or 3 2005Q1 brokers running with a trial or enterprise license.

Messaging Server

Table 5-5 list the known incompatibilities between Messaging Server 6 2005Q1 and earlier versions.

Table 5-5 Messaging Server 6 Compatibility
Incompatibility	Impact	Comments
The comm_dssetup.pl under /opt/SUNWmsgsr/lib doesn’t work and is referring to /opt/SUNWcomds	The comm_dssetup.pl tool has been moved to its own package.	install the comm_dssetup package and run the tool from there. On Solaris, the default location is /opt/SUNWcomds. On Linux, the default location is /opt/sun/comms/dssetup
The configuration program for commcli (now Delegated Administrator) has changed.	Find the current program location at: /opt/SUNWcomm/sbin/config-commda

Communications Express

Table 5-6 list the known incompatibilities between Communications Express 2005Q1 and earlier versions.

Table 5-6 Unified Web Client Compatibility
Incompatibility	Impact	Comments
This release of Communications Express is incompatible with the 2004Q2 versions of Calendar Server and Messaging Server.	Upgrade Calendar Server and Messaging Server when upgrading Communications Express.

Web Server

Table 5-7 list the known incompatibilities between Web Server 6 2005Q1 and earlier versions.

Previous Contents Index Next
Sun Java Enterprise System 2005Q1 Upgrade and Migration Guide