Resolution:
Description:
= = = = = ==
The following MessageFormatException was thrown when receiving an ObjectMessage from the EMS server from an application running in IBM’s WebSphere 6.1:

javax.jms.MessageFormatException: Deserialization failed: com.citigroup.gsu.edelivery.engine.commons.EngineServiceObject
at com.tibco.tibjms.TibjmsObjectMessage.getObject(TibjmsObjectMessage.java:240)

Environment
= = = = = ==
All Platforms
The EMS Java client application uses EMS 5.1.0 and higher Java client library: tibjms.jar.


Resolution
= = = = = =
Pre EMS 5.1 used the thread context class loader to instantiate from an object message.  However, this did not work under all circumstances, particularly when instantiating simple primitive types.  Also the thread context class loader mechanism did not work with some newer application servers such as Weblogic application server 10.3. The remedy was to use the default class loader. The change was made in the following change request: CR:1-95Y3CH.

1-95Y3CH
EMS 5.1
Fixed an error that could cause Java clients to receive a ClassNotFoundException when using Object messages. Deserializing an Object message when the object is a class instance that represents primitive types sometimes resulted in an exception.

For some application servers like WebSphere application server 6.1 and Weblogic application server prior to 10.3, the object message could not be correctly initialized using the default class loader. You can switch to the thread context class loader by specifying “com.tibco.tibjms.use_extended_objinpstrm” as a Java argument to the application server startup.

Example usage:

–Dcom.tibco.tibjms.use_extended_objinpstrm