Package org.infinispan.commons.marshall
Interface Externalizer<T>
-
- All Superinterfaces:
Serializable
- All Known Subinterfaces:
AdvancedExternalizer<T>
,LambdaExternalizer<T>
- All Known Implementing Classes:
AbstractExternalizer
,AcceptAllKeyValueFilter.Externalizer
,AdminFlagExternalizer
,AvailabilityMode.Externalizer
,ByteBufferImpl.Externalizer
,CacheEventConverterAsConverter.Externalizer
,CacheEventFilterAsKeyValueFilter.Externalizer
,CacheEventFilterConverterAsKeyValueFilterConverter.Externalizer
,CacheFilters.CacheFiltersExternalizer
,CompositeKeyValueFilter.Externalizer
,EmbeddedMetadata.Externalizer
,Flag.Externalizer
,ImmutableListCopy.Externalizer
,Immutables.ImmutableMapWrapperExternalizer
,Immutables.ImmutableSetWrapperExternalizer
,InstanceReusingAdvancedExternalizer
,KeyValueFilterAsCacheEventFilter.Externalizer
,KeyValueFilterConverterAsCacheEventFilterConverter.Externalizer
,MurmurHash3.Externalizer
,NoStateExternalizer
,ScopedState.Externalizer
,ScopeFilter.Externalizer
,SingletonExternalizer
,StreamMarshalling.StreamMarshallingExternalizer
,SuppliedExternalizer
,WrappedByteArray.Externalizer
@Deprecated public interface Externalizer<T> extends Serializable
Deprecated.since 10.0, will be removed in a future release. Please configure aSerializationContextInitializer
and utilise ProtoStream annotations on Java objects instead, or specify a customMarshaller
implementation via the SerializationConfiguration.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 provide anExternalizer
implementation for the type that they want to marshall/unmarshall, and then annotate the marshalled type class withSerializeWith
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 aspublic static classes
. To make externalizer implementations easier to code and more typesafe, make sure you define typeas the type of object that's being marshalled/unmarshalled. Even though this way of defining externalizers is very user friendly, it has some disadvantages: - 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 efficient.
- 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.
AdvancedExternalizer
. More details can be found in this interface's javadoc. Please note that even though Externalizer is marked asSerializable
, the need to marshall the externalizer is only really needed when developing user friendly externalizers (usingSerializeWith
).AdvancedExternalizer
instances do not require the externalizer to be serializable since the externalizer itself is not marshalled. Even though it's not strictly necessary, to avoid breaking compatibility with old clients,Externalizer
implementsSerializable
but this requirement is only needed for those user friendly externalizers. There's a chance that in future major releasesExternalizer
won't extendSerializable
any more, hence we strongly recommend that any user-friendly externalizer users mark their externalizer implementations as eitherSerializable
orExternalizable
.- Since:
- 5.0
- Author:
- Galder ZamarreƱo
-
-
Method Summary
All Methods Instance Methods Abstract Methods Deprecated Methods Modifier and Type Method Description T
readObject(ObjectInput input)
Deprecated.Read an instance from the stream.void
writeObject(ObjectOutput output, T object)
Deprecated.Write the object reference to the stream.
-
-
-
Method Detail
-
writeObject
void writeObject(ObjectOutput output, T object) throws IOException
Deprecated.Write the object reference to the stream.- Parameters:
output
- the object output to write toobject
- the object reference to write- Throws:
IOException
- if an I/O error occurs
-
readObject
T readObject(ObjectInput input) throws IOException, ClassNotFoundException
Deprecated.Read an instance from the stream. The instance will have been written by thewriteObject(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.- Parameters:
input
- the object input to read from- Returns:
- the object instance
- Throws:
IOException
- if an I/O error occursClassNotFoundException
- if a class could not be found
-
-