---
schema_version: "1"
id: 5eed0f36374d4044aa42e16c14535c6ec8867f1ec94b01b37a081e23bebf6570
title: Configure Custom Serializers
collection: mulesoft
version: current
locale: en-us
portal_url: https://docs.salesforce.com/mulesoft/current/en-us/mule-runtime/4.3/configure-custom-serializers.md
canonical_url: https://docs.mulesoft.com/mule-runtime/4.3/configure-custom-serializers
source_site: docs.mulesoft.com
content_type: documentation
content_hash: 5d0a83b1e1f763a7c77897fd26394816439990d4611c10687170bc6ee1b8d2ef
description: MuleSoft Documentation Site
release: "4.3"
latest: false
---
---
product: Mule Runtime
version: 4.3
---

# Configure Custom Serializers

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

By default, Mule runtime engine (Mule) uses ordinary Java serialization. However, you can configure
`defaultObjectSerializer` in your Mule application to specify a different serialization mechanism,
such as the Kryo serializer or any other custom serializer.

Using a custom serializer can improve functionality and performance when Mule executes any of the
following processes:

- Read from or write to a persistent object store

- Read from or write to a persistent VM or JMS queue

- Distribute an object through a Mule cluster

- Read from or write to an object from a file

Customization does not affect the behavior of the Batch module, which always uses the Kryo
serializer.

## Compatibility Between Serializers and Mule

If you are running Mule runtime engine (Enterprise Edition), you can configure the Kryo serializer
to improve performance.

If you are using Mule Kernel (Community Edition), you can create a custom serializer using the
Serialization API.

## Configure the Kryo Serializer

Mule provides an implementation of `ObjectSerializer` that relies on the Kryo framework. Using Kryo
provides the following benefits:

- Better performance  
  Kryo is much faster than Java serialization.

- Support for a wider range of Java types  
  Kryo is not bound by most of the limitations that Java serialization imposes, such as requiring
  the implementation of the `Serializable` interface, having a default constructor, and so on.

- Support for compression  
  You can use either Deflate or GZip compression algorithms.

The Kryo namespace enables you to configure this serializer inside your Mule application, without
defining a custom Spring bean. The following configuration example sets the default serializer to a
Kryo-based one:

```xml
<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns="http://www.mulesoft.org/schema/mule/core"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:kryo="http://www.mulesoft.org/schema/mule/kryo"
       xsi:schemaLocation="
        http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
        http://www.mulesoft.org/schema/mule/kryo http://www.mulesoft.org/schema/mule/kryo/current/mule-kryo.xsd">

    <kryo:serializer name="kryo" />
    <configuration defaultObjectSerializer-ref="kryo" />

</mule>
```

You can also include the `compressionMode` XML attribute to configure compression:

```xml
<kryo:serializer name="noCompression" compressionMode="NONE" /> <!-- NONE is the default value -->
<kryo:serializer name="deflate" compressionMode="DEFLATE" />
<kryo:serializer name="gzip" compressionMode="GZIP" />
```

## Create a Custom Serializer Using the Serialization API

The open-source Serialization API provides the `ObjectSerializer.java` interface, which enables you
to serialize or deserialize objects into a byte array. See
[ObjectSerializer.java in GitHub](https://github.com/mulesoft/mule-api/blob/master/src/main/java/org/mule/runtime/api/serialization/ObjectSerializer.java).

The Serialization API has the following features:

- Is thread-safe

- Passes an OutputStream when serializing and streaming

- Allows an InputStream as an input source

If you are going to serialize and deserialize in Mule, then you must define the
`getInternalProtocol()` method. If you are going to use the serialized object in an external system,
define that in the `getExternalProtocol()` method.  
A [Serialization Protocol](https://github.com/mulesoft/mule-api/blob/master/src/main/java/org/mule/runtime/api/serialization/SerializationProtocol.java)
is the object used to serialize and deserialize.

## Configure a Custom Serializer

Configure the default `ObjectSerializer` for your Mule application using the Mule `<configuration>`
tag:

```xml
<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns="http://www.mulesoft.org/schema/mule/core"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:spring="http://www.springframework.org/schema/beans"
       xsi:schemaLocation="
        http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
        http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-current.xsd">

  <spring:config name="Spring_Config" files="serializer.xml" />
  <configuration defaultObjectSerializer-ref="customSerializer" />

</mule>
```

Then, configure the bean in the `serializer.xml` file:

```xml
<?xml version="1.0" encoding="utf-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-4.3.xsd">
	<bean id="customSerializer" name="customSerializer"
		class="com.my.CustomSerializer">
		<!-- ... -->
	</bean>
</beans>
```

## Obtain a Configured ObjectSerializer

There are different ways to obtain an `ObjectSerializer` inside Java code. Generally, the
recommended approach is through dependency injection. The following code example shows you how to
get the currently configured `ObjectSerializer`:

```java
public class MyClass {
   @Inject
   private  ObjectSerializer objectSerializer;
}
```

If you want a specifically named serializer (whether it’s the default or not), you can access the
serializer by name:

```java
public class MyClass {
  @Inject
  @Named ("mySerializer")
  private ObjectSerializer objectSerializer;
}
```

## Performance Improvements with Kryo

Using Kryo provides particular performance improvements over ordinary Java serialization when you
are using these components:

- Persistent or clustered object stores

- Persistent or distributed VM queues

- JMS connector

The Kryo serializer without compression is significantly faster than the ordinary Java serializer in
all cases. However, compression mode provides an improvement only in high availability (HA) cases.

For compression to be worthwhile, the amount of time the CPU spends compressing and decompressing
has to be significantly lower than the amount of I/O time saved by reducing the payload size.
Because network operations are typically slower than disk operations, and because HA clustering
requires node replication (which translates to more traffic), compression is useful only in HA
environments.

This is not a universal constant. You might be running Mule on machines with slower disks or higher
I/O demands in which compression might be worthwhile in any case. Also, tests were performed using 1
MB payloads. If your data stream is larger, compression becomes more worthwhile.

## Considerations When Using Serialization

Ensure that you are aware of the following limitations and considerations when using serialization.

### Changing Serializers Requires a Clean Slate

Serializers are not interoperable nor interchangeable. That means that if you decide to change the
serializer your application uses, ensure that all messages in VM and JMS queues have been consumed
and that those queues are empty by the time the new serializer takes over.

The Kryo serializer won’t be able to read datagrams written by the Java serializer, and vice-versa.
The same thing applies to persistent object stores; you cannot read with one serializer an entry
generated with a different serializer.

### Shared VM Connectors Use the Domain’s Default Serializer

Domains provide a way to share resources between applications. For example, you can define a VM
connector on a domain to allow inter-app communication through VM message queues.

However, serializers can be configured only at an application level; they cannot be configured at a
domain level.

If applications A and B communicate with each other through a VM connector defined on a domain to
which both belong, but A serializes using Java and B using Kryo, the serialization works because
that particular message is not serialized with the application’s serializer but the one the VM
connector uses (the default serializer at domain level). This is good for a "plug-and-play
experience," but you won’t be able to realize a performance improvement by having that shared VM
connector use Kryo.

### Low Improvement For Local Persistent Object Stores

The local persistent object store has no performance advantage because of high contention on the
object store implementation.

### Low Improvement For JMS Queues

The JSM API specifies that queues need to provide an instance of the `javax.jms.Message` class, the
queues don’t work with raw payload objects. The broker client is responsible for serializing the
message, not Mule. So, configuring Kryo has minimun impact in this scenario.

The only performance gain of using Kryo with JMS is that Mule serializes the MuleSession and uses it
as a header in Base64 format. Serializing the MuleSession with Kryo can give you up to a 10%
performance increase, but this is primarily attributable to the JMS broker instead of Mule.

### Problematic Types

Although Kryo is capable of serializing objects that don’t implement the `Serializable` interface,
setting Kryo as the default serializer doesn’t mean that components such as the VM connector,
ObjectSerializer, or cluster can handle objects that don’t implement such an interface. Although
Kryo can work with those objects, the Java APIs for those components still expect instances of
`Serializable` in their method signatures.

Ordinary Java serialization fails with an object that doesn’t implement the `Serializable`
interface. However, if serialization contains another object which doesn’t implement the
Serializable interface, Kryo is likely (but not guaranteed) to succeed. A typical case is a POJO
containing an `org.apache.xerces.jaxp.datatype.XMLGregorianCalendarImpl,` which is in use in the
[NetSuite](https://anypoint.mulesoft.com/exchange/?search=netsuite) or
[Microsoft Dynamics CRM](https://anypoint.mulesoft.com/exchange/?search=Microsoft+Dynamics+CRM&type=connector)
connectors.

## See Also

- [Kryo information](https://github.com/EsotericSoftware/kryo)