JVM compatible with Oracle JRE Java 1.7.x or higher.
(Note: The actual JAR files may have version numbers in them.)
| Library | Description |
|---|---|
The QFJ core JAR and message JARs.
|
QFJ runtime libraries |
| Library | Description |
|---|---|
| mina-core-2.0.16.jar | Socket handling (Java NIO) |
| slf4j-api.jar | SLF4J library for JDK logging. |
| Library | Description |
|---|---|
| log4j.jar | If Log4J logging is desired. The JDK logging is the default. |
| slf4j-log4j12.jar | Use this JAR file instead of slf4j-jdk14-*.jar if you want to use Log4J logging. |
| proxool.jar | This JAR provided database connection pooling capabilities. It is required if you are using the JDBC store or log. |
| jcl104-over-slf4j.jar | Adapts Jakarta Commons Logging to SLF4J. Required if you are using an optional library that depends on Jakarta Commons Logging. Currently, this includes Proxool (needed by JDBC store and log for connection pooling). |
| sleepycat-je.jar | Needed if the SleepyCat JE message store is used. |
By default, the XML processing in QuickFIX/J uses the XML parser included with the JDK. In general other parsers can be used but it's possible you will have problems. We've had users report that Xerces 2.6 does not work, but that version 2.8 does. If you try other parsers, please let us know if it works or not.
These instructions are for developers who don't want to use the prebuilt binaries or are intending to modify and rebuild the QuickFIX/J code. If you are building the code from the command line you'll need to download and install Maven (version 3.2.5 or newer). If you are building from an IDE, Maven is usually included. Building from source requires Java 7+.
mvn package to build the QuickFIX/J and examples jar files.
This will also generate all the FIX message-related code for the various
FIX versions.-Dgenerator.decimal option on the command line when
running the generate.code target.| Switch | Description | Default |
|---|---|---|
| -Dgenerator.decimal | Generate BigDecimal vs doubles fields | false |
| -DskipAT=true | Skip running of acceptance test suite. | false |
For example, in order to generate fields with BigDecimals and skip acceptance tests:
mvn test -Dgenerator.decimal=true -DskipAT=true
When the project is first created, it will not have the generated message classes
and compile errors will occur! Best is to compile once on the command line before importing
the project into the IDE.
If the IDE reports some errors after the compilation with mvn package, try to use mvn install .
If you are using the Maven build system, you can reference the pre-built QuickFIX/J libraries hosted at the Central Repository repository.
Add the following to your dependencies section, with appropriate modifications based on
the logging subsystem you choose:
<!-- QuickFIX/J dependencies -->
<dependency>
<groupId>org.quickfixj</groupId>
<artifactId>quickfixj-core</artifactId>
<version>2.0.0</version>
</dependency>
<dependency>
<groupId>org.quickfixj</groupId>
<artifactId>quickfixj-messages-fix40</artifactId>
<version>2.0.0</version>
</dependency>
<dependency>
<groupId>org.quickfixj</groupId>
<artifactId>quickfixj-messages-fix41</artifactId>
<version>2.0.0</version>
</dependency>
<dependency>
<groupId>org.quickfixj</groupId>
<artifactId>quickfixj-messages-fix42</artifactId>
<version>2.0.0</version>
</dependency>
<dependency>
<groupId>org.quickfixj</groupId>
<artifactId>quickfixj-messages-fix43</artifactId>
<version>2.0.0</version>
</dependency>
<dependency>
<groupId>org.quickfixj</groupId>
<artifactId>quickfixj-messages-fix44</artifactId>
<version>2.0.0</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.7.22</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.22</version>
</dependency>
Everything needed to generate your database is in the src/main/resources/config/sql subdirectories.
For MySQL, there are the script and batch files create_mysql.sh and create_mysql.bat.
These scripts will work on a newly installed mysql database with default permisions.
The scripts will try to generate the database using the root MySQL account
with no password. If you need to use a different account or need a password,
you will have to edit the script. To select a different user, simply change
'root' to another user. To add a password, use pass the -p option after the
username. Similar scripts are provided for MSSQL, PostgreSQL and Oracle.
Oracle treats empty strings as null values. Null values are not allowed for primary key fields. The fields used in the primary keys are:
Please also not, that for string fields always the VARCHAR2 data type should be used. If CHAR fields are used, they always have to be spaced-padded to the full length.
The development of QuickFIX has been driven by a suite of functional acceptance tests and unit tests. We have been working incrementally, functional test by functional test, writing the unit tests before the code. If these tests pass, we're reasonably confident that the engine works as intended.
The developer unit tests are written as JUnit tests and test the code directly. The functional acceptance tests are scripted FIX messages that are pumped into a running FIX server. Most of these tests are based off of the FIX Session-level Test Cases and Expected Behaviors document.
The unit tests can be run by running the test target
in the pom.xml file. If you are using Eclipse, you can right-click on
the quickfix package in the test subdirectory and select the "Run as... ->
JUnit Test" option. This should locate all the unit tests in the package hierarchy
and run them in the integrated JUnit test runner.
QuickFIX/J also has a scriptable test runner that comes with a series of automated acceptance test. The basic tests that come with QuickFIX are based off of the FIX Session-level Test Cases and Expected Behaviors document produced by the FIX protocol organization. These tests verify that QuickFIX adheres to the FIX specifications. The automated nature of these tests guarantees that future releases of QuickFIX will not break any current functionality.
Perhaps even more importantly is how these test are used to drive the development of QuickFIX. Before a line of code is written in support of a protocol feature, one of these tests is written. This test first approach sets up a goal for developers who will have objective verification that they correctly implemented the standard.
To run the acceptance tests:
If you are using Eclipse, right-click on the quickfix.test.acceptance.AcceptanceTestSuite class
and select the "Run as... -> JUnit Test" option. This will start an acceptance
test program with an embedded QuickFIX/J server, load the AT definition files
and convert them to JUnit tests, and run those tests in the embedded JUnit
test view.
Below is an example of a test script that tests the engines behavior when it receives a NewSeqNo value that is less than the expected MsgSeqNum.
iCONNECT I8=FIX.4.2␁35=A␁34=1␁49=TW␁52=<time>␁56=ISLD␁98=0␁108=30␁ E8=FIX.4.2␁9=57␁35=A␁34=1␁49=ISLD␁52=00000000-00:00:00␁56=TW␁98=0␁108=30␁10=0␁ # sequence reset without gap fill flag (default to N) I8=FIX.4.2␁35=4␁34=0␁49=TW␁52=<time>␁56=ISLD␁36=1␁ E8=FIX.4.2␁9=112␁35=3␁34=2␁49=ISLD␁52=00000000-00:00:00␁56=TW␁45=0␁58=Value is incorrect (out of range) for this tag␁372=4␁373=5␁10=0␁ I8=FIX.4.2␁35=1␁34=2␁49=TW␁52=<time>␁56=ISLD␁112=HELLO␁ E8=FIX.4.2␁9=55␁35=0␁34=3␁49=ISLD␁52=00000000-00:00:00␁56=TW␁112=HELLO␁10=0␁ # sequence reset without gap fill flag (default to N) I8=FIX.4.2␁35=4␁34=0␁49=TW␁52=<time>␁56=ISLD␁36=1␁123=N␁ E8=FIX.4.2␁9=112␁35=3␁34=4␁49=ISLD␁52=00000000-00:00:00␁56=TW␁45=0␁58=Value is incorrect (out of range) for this tag␁372=4␁373=5␁10=0␁ I8=FIX.4.2␁35=1␁34=3␁49=TW␁52=<time>␁56=ISLD␁112=HELLO␁ E8=FIX.4.2␁9=55␁35=0␁34=5␁49=ISLD␁52=00000000-00:00:00␁56=TW␁112=HELLO␁10=0␁ iDISCONNECTIn these script there are two types of commands, action commands and messages commands. Action commands begin with lowercase letters while message command begin with uppercase letters.
When using the I command, you do not need to add the Length(9) or the CheckSum(10) fields, they will be added for you with the correct values in the appropriate locations. The only time you would add these fields is if you intentionally wish to make them incorrect.
The I command also provides a TIME macros for fields. By setting a field equal to <TIME>, the current system time will be placed in the field. (i.e. 52=<time>). You can also use offsets such as 52=<TIME-120> or 52=<TIME+15> in order to set the time plus or minus some seconds from the current time.
The E command verifies that you have received the correct message. This command will compare the values of each field to make sure they are correct. Some fields cannot be verified deterministically before run-time such as the SendingTime and CheckSum fields. These fields can be added to the fields.fmt file where a regular expression can be defined to at least verify the field is in the correct format. For example:
10=\d{3}, checksum must be exactly three digits
52=\d{8}-\d{2}:\d{2}:\d{2}, sending time must be in the form of DDDDDDDD-DD:DD:DD
where D is a digit.