|
||||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
SUMMARY: REQUIRED | OPTIONAL | DETAIL: ELEMENT |
Externalizer
method implementations.
@Retention(value=RUNTIME) @Target(value=TYPE) @Deprecated public @interface Marshalls
Once the Externalizer
implementations have been build, it's time to link them up together
with the type classes that they externalize and you do so annotating the Externalizer
implementations with Marshalls
.
When this annotation is used, it's mandatory that either typeClasses()
or typeClassNames()
is filled up. Basically, both of these properties indicate
which classes this Externalizer implementation marshalls. As indicated by the properties, a
Externalizer implementation is not limited to marshalling a unique type, on the contrary, it can
marshall different types. The difference between typeClasses()
and
typeClassNames()
is how these type classes are defined. The first option takes
Class
instances, but there might sometimes where the classes your externalizing are private
and hence you cannot reference the class instance. In this case, you should use
typeClassNames()
and indicate the fully qualified name of the class. You can find
an example of this in SingletonListExternalizer
that tries to
provide a better way to serialize lists with a single element.
Marshalls
annotation also takes an positive identifier as optional parameter which is used
to identify the type of externalizer. This is used at read time to figure out which Externalizer
should read the contents of the incoming buffer. Using a positive integer allows for very efficient
variable length encoding of numbers, and it's much more efficient than shipping Externalizer
implementation class information around. You can use any positive integer as long as it does not clash
with any other identifier in the system. You can find information on the pre-assigned identifier ranges
in here.
It's highly recommended that maintaining of these identifiers is done in a centralized way and you
can do so by making annotations reference a set of statically defined identifiers in a separate class
or interface. Such class/interface gives a global view of the identifiers in use and so can make it
easier to assign new ids.
Infinispan does no annotation scanning and so, as indicated in ExternalizerConfig
,
it is necessary that any Externalizer implementations to be used are listed in the global configuration
either via XML or programmatically. When listing these externalizer implementations, users can optionally
provide the identifier of the externalizer via XML or programmatically instead of via this annotation.
Again, this offers a centralized way to maintain the identifiers but it's important that the rules are clear:
An Externalizer implementation, either via XML/programmatic configuration or via annotation, needs to be
associated with an identifiers. If it isn't, Infinispan will throw an error and abort startup. If a
particular Externalizer implementation defines an id both via XML/programmatic configuration and annotation,
the value defined via XML/programmatically is the one that will be used.
Optional Element Summary | |
---|---|
int |
id
Deprecated. |
Class[] |
typeClasses
Deprecated. |
String[] |
typeClassNames
Deprecated. |
public abstract Class[] typeClasses
public abstract String[] typeClassNames
public abstract int id
|
--> | |||||||||
SUMMARY: REQUIRED | OPTIONAL | DETAIL: ELEMENT |