All MobileFabric Posts

How custom code JAR files are handled

Ajay Bhat - Aug 22, 2017 - Integration

In this post, Sandeep Prabhu discusses managing JAR files containing custom code through MobileFabric.

Kony MobileFabric provides a bunch of extensibility points where developers can inject custom JAVA code. e.g. a service can have a pre/post processor. In this post, I will cover how these JAR files are handled by MobileFabric.

A custom code JAR file is a shared resource in MobileFabric. It’s basically an independent entity that can be consumed (or referenced) by one or more entities. e.g.

  • Two services may have similar requirements and so may want to use the same pre processor class from a given JAR file
  • A JAR file may be implementing multiple post processors and a bunch of services may then consume this JAR file and specify the relevant post processor
  • A JAR file may implement some common utility functions. A bunch of pre processor JAR files may then be built using those functions, i.e. all those JAR files consume the utility JAR

A custom code JAR file can be managed from the Console by navigating to API Management --> Custom Code. Note that if you are on an on-premise installation, this capability was added in the 7.3 version. From this tab, you can see all the JAR files, see who are referencing those and do the full management – adding new ones, updating existing ones, deleting the unused ones, …


From an execution or runtime perspective as well, a JAR is a shared resource. When services are published to an environment, there’s exactly one copy of each referenced JAR file that’s stored in that environment. And there’s exactly one instance of that JAR file that gets loaded by the environment. All the calls from the referring entities are handled by that one instance. What this also means is that when a publish updates a JAR file in an environment, it will impact all the existing consumers of that JAR file and everyone will use the updated contents.

Now there may be scenarios where you want to change the contents but not have the existing services pick those up. To achieve this isolation, you will need to create a new JAR and make sure the package name/class name is used to disambiguate the classes in the two JAR files. 

e.g. say a service is using HelloWorld.jar and within that as the pre processor class. Another service can use HelloWorld-2.0.jar and within that as the pre processor class.