Red Hat JBoss® BPM Suite and Red Hat Decision Manager (formerly Red Hat JBoss BRMS) both use an artifact packaging known as a "KJAR", or knowledge artifact, since version 6. What is this file type? What separates it from a standard JAR file?

The basic summary

In very few words, a KJAR is a standard JAR file that has some extra files included. A KJAR keeps the same .jar extension as a JAR file, because its basic file structure is identical to that of a JAR.

Why the difference?

A JAR ("Java archive") file is meant to run Java code of any kind, with nearly limitless resources and assets potentially being included as part of the package. To quote the JAR standard, "A JAR file is essentially a zip file that contains an optional META-INF directory." ¹ By contrast, a KJAR ("Knowledge artifact") is specifically targeted for rules and processes which tend to be notated in XML or plain text. There may or may not be any further resources or assets contained within a knowledge artifact. The contents of a KJAR are still intended to compile into Java bytecode, but the specific focus on rules and processes allows them to configure and optimize their contents while still conforming to the standard JAR file structure.

What differences are there?

A KJAR must, at least, contain the file META-INF/kmodule.xml. This file is used to describe the KJAR structure and define some KIE-specific artifacts. The v6 specification for this file can be found here, and an example for v6 can be found here.

The following items are also different between JARs and KJARs:

• Maven-based
  • JAR: Does not need not be built according to any specific folder structure, as long as a META-INF directory is present at the top level
  • KJAR: Conforms to the Maven Standard Directory Layout
• Extra files
  • JAR: No specific files are required to be present
  • KJAR: Must contain a META-INF/kmodule.xml file, which in turn must contain at least a correctly formatted <kmodule> XML tag
• Pre-compiled asset cache
  • JAR: Any code which is to be pre-compiled into bytecode is the responsibility of the build service which generates the JAR.
  • KJAR: Uses the KIE Maven plugin during build time, which automatically pre-compiles some rule and process assets into a cache (META-INF/<kie-base-name>/kbase.cache). (This cache is not complete, but can improve performance when loading rules/processes.) If the cache is not created, all assets will be built at runtime.
• Deployment Descriptor (since v6.1)
  • JAR: No specific configurations or deployment types are specified, though various other frameworks or standards (such as Java EE) may create their own standards.
  • KJAR: If the file META-INF/kie-deployment-descriptor.xml exists, it is used automatically to determine various properties for executing rules and/or processes such as runtime strategy, event listeners, work item handlers, and more. ²

What remains the same?

Nearly everything about a KJAR is really a targeted addition to a JAR file, so you can count on KJARs being almost entirely the same as JAR files. You can still use a MANIFEST.MF file to define package info, you can still use a beans.xml file to have CDI pick up classes, and you can still use popular files like logback.xml or log4j.xml for use with popular Java logging frameworks.

How is a KJAR made?

The primary difference between building a KJAR and building a standard JAR is that the KJAR has a <packaging>kjar</packaging> entry in its pom.xml and also contains the necessary <plugin> for kie-maven-plugin in that same file. ³

What happens if I generate a JAR instead of a KJAR?

Officially, use of the KIE Maven plugin ensures that artifact resources are validated and pre-compiled, so use of that plugin is recommended at all times. However, if the rules/processes inside a KJAR are valid there are unlikely to be any execution problems whether they are running from a JAR or a KJAR. No kbase.cache would be created without the KIE Maven plugin ⁴, so it's possible that users would encounter worse performance when attempting to run rules/processes from a JAR instead of a KJAR.

Footnotes:

1) JAR File Specification - https://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html

2) Deployment Descriptors - https://access.redhat.com/documentation/en-us/red_hat_jboss_bpm_suite/6.4/html/administration_and_configuration_guide/chap_business_central_configuration#idm139940729511264

3) How to build a kjar from Maven command for BRMS/BPM Suite 6? - https://access.redhat.com/solutions/892893

4) Is it possible to load kbase.cache file directly to save time for loading KieBase in Drools 6 ? - https://access.redhat.com/solutions/1297523

Last updated: March 13, 2018