ObjectQ Java Implementation – Beta Release 1.0.0.0 – Release Notes



Introduction

The Java implementation of ObjectQ follows the C++ model as faithfully as possible, given the constraints of the language differences. For example, exceptions are used, rather than return codes. Users familiar with the C++ implementation will see obvious parallels, with classes and methods duplicated as far as is possible. The MIB files remain almost exactly the same, with a minor modification to the Service Name Resolution file, discussed later.

The implementation uses JMS as the underlying transport, so that any vendor that exposes a JMS interface can be used – although it has only been tested thus far on a WebSphere MQ transport.

This document provides information on the differences between the Java and C++ implementations, as well as installation and setup instructions.

Differences from the C++ implementation


Installation and setup

  1. There is a single jar file, named ObjectQ.jar, which should be placed in the application's classpath.

  2. Supporting jar files, which should also be placed in the classpath, are: log4j-api-X.X.X.jar and log4j-core-X.X.X.jar, and IBM WebSphere MQ's mqjms.jar.

  3. The MIB files should be placed in a directory whose path is passed to the ObjectQ constructor. This constructor should be invoked before any other. The MIB files are identical to those used by the C++ implementation, with one exception: the START LOCATION stanza in SNR file has one additional field, with tag server:. It should be set either to JMS, indicating that the server is another Java implementation, or MQS, indicating that the server is NON-JMS C++ implementation. Currently only WebSphere MQ is supported, since the mechanism for transporting queue information between applications is vendor-dependent.

  4. Queues should be set up in JNDI. Within ObjectQ, queue aliases are used to refer to queues – these are identical to JNDI entries.

  5. The name of the log4j logger used by ObjectQ is ObjectQ – it can be configured using log4j's configuration file. If a logger is passed to the ObjectQ constructor, it is used instead.

  6. Properties are read from a file named ObjectQ.properties, which should again be in the classpath. Here is an example of its contents:

    # The name of the Queue Connection Factory used
    # to obtain QueueConnections

jmsQCF=sampleQCF

# The URL for JNDI, defaulting to file:.

jmsURL=file:/D:/ObjectQ/workspaces/ObjectQ/bindings

# The location of the regdomain file,
# defaulting to ./
regdomain

REGDOMAIN=D:/ObjectQ/regdomain

# The Initial Context Factory

jmsICF=
com.sun.jndi.fscontext.RefFSContextFactory

# The maximum message size, defaulting to 32000
MAXMSGSIZE=32000

Resources