- All Superinterfaces:
- All Known Subinterfaces:
- All Known Implementing Classes:
- AbstractExternalizer, AbstractWheelConsistentHash.Externalizer, ArrayListExternalizer, AtomicHashMap.Externalizer, AtomicHashMapDelta.Externalizer, Bucket.Externalizer, ByteArrayKey.Externalizer, CacheRpcCommandExternalizer, CacheView.Externalizer, ChunkCacheKey.Externalizer, ClearOperation.Externalizer, DefaultConsistentHash.Externalizer, DldGlobalTransaction.Externalizer, ExceptionResponse.Externalizer, ExperimentalDefaultConsistentHash.Externalizer, FileCacheKey.Externalizer, FileListCacheKey.Externalizer, FileMetadata.Externalizer, FileReadLockKey.Externalizer, Flag.Externalizer, Fqn.Externalizer, GlobalTransaction.AbstractGlobalTxExternalizer, GlobalTransaction.Externalizer, ImmortalCacheEntry.Externalizer, ImmortalCacheValue.Externalizer, Immutables.ImmutableMapWrapperExternalizer, InDoubtTxInfoImpl.Externalizer, JGroupsAddress.Externalizer, JGroupsTopologyAwareAddress.Externalizer, LinkedListExternalizer, LockInfo.Externalizer, MapExternalizer, MarshalledValue.Externalizer, MortalCacheEntry.Externalizer, MortalCacheValue.Externalizer, MurmurHash2.Externalizer, MurmurHash2Compat.Externalizer, MurmurHash3.Externalizer, NodeKey.Externalizer, NoStateExternalizer, PutOperation.Externalizer, RecoveryAwareDldGlobalTransaction.Externalizer, RecoveryAwareGlobalTransaction.Externalizer, RemoteTransactionLogDetails.Externalizer, RemoveOperation.Externalizer, ReplicableCommandExternalizer, SerializableXid.XidExternalizer, SetExternalizer, SingletonListExternalizer, SuccessfulResponse.Externalizer, TopologyAwareConsistentHash.Externalizer, TransientCacheEntry.Externalizer, TransientCacheValue.Externalizer, TransientMortalCacheEntry.Externalizer, TransientMortalCacheValue.Externalizer, UnionConsistentHash.Externalizer, UnsuccessfulResponse.Externalizer, UnsureResponse.Externalizer, VersionedImmortalCacheEntry.Externalizer, VersionedImmortalCacheValue.Externalizer, VersionedMortalCacheEntry.Externalizer, VersionedMortalCacheValue.Externalizer, VersionedTransientCacheEntry.Externalizer, VersionedTransientCacheValue.Externalizer, VersionedTransientMortalCacheEntry.Externalizer, VersionedTransientMortalCacheValue.Externalizer
public interface Externalizer<T>
- extends Serializable
One of the key aspects of Infinispan is that it often needs to marshall or
unmarshall objects in order to provide some of its functionality. For
example, if it needs to store objects in a write-through or write-behind
cache store, the objects stored need marshalling. If a cluster of
Infinispan nodes is formed, objects shipped around need marshalling. Even
if you enable storing as binary, objects need to marshalled so that they
can be lazily unmarshalled with the correct classloader.
Using standard JDK serialization is slow and produces payloads that are too
big and can affect bandwidth usage. On top of that, JDK serialization does
not work well with objects that are supposed to be immutable. In order to
avoid these issues, Infinispan uses JBoss Marshalling for
marshalling/unmarshalling objects. JBoss Marshalling is fast, provides
very space efficient payloads, and on top of that, allows users to
construct objects themselves during unmarshalling, hence allowing objects
to carry on being immutable.
Starting with 5.0, users of Infinispan can now benefit from this marshalling
framework as well. In the simplest possible form, users just need to
Externalizer implementation for the type that they want
to marshall/unmarshall, and then annotate the marshalled type class with
SerializeWith indicating the externalizer class to use and that's
all about it. At runtime JBoss Marshaller will inspect the object and
discover that's marshallable thanks to the annotation and so marshall it
using the externalizer class passed.
It's common practice to include externalizer implementations within the
classes that they marshall/unmarshall as
public static classes.
To make externalizer implementations easier to code and more typesafe, make
sure you define type as the type of object that's being
Even though this way of defining externalizers is very user friendly, it has
If you're affected by any of these disadvantages, an alternative mechanism
to provide externalizers is available via
- Due to several constraints of the model, such as support different
versions of the same class or the need to marshall the Externalizer
class, the payload sizes generated via this method are not the most
- This model requires for the marshalled class to be annoated with
SerializeWith but a user might need to provide an Externalizer
for a class for which source code is not available, or for any other
constraints, it cannot be modified.
- The use of annotations by this model might be limiting for framework
developers or service providers that try to abstract lower level
details, such as the marshalling layer, away from the user.
More details can be found in this interface's javadoc.
- Galder Zamarreño
void writeObject(ObjectOutput output,
- Write the object reference to the stream.
output - the object output to write to
object - the object reference to write
IOException - if an I/O error occurs
T readObject(ObjectInput input)
- Read an instance from the stream. The instance will have been written by the
writeObject(ObjectOutput, Object) method. Implementations are free
to create instances of the object read from the stream in any way that they
feel like. This could be via constructor, factory or reflection.
input - the object input to read from
- the object instance
IOException - if an I/O error occurs
ClassNotFoundException - if a class could not be found
Copyright © 2012 JBoss, a division of Red Hat. All Rights Reserved.