org.infinispan.marshall
Annotation Type Marshalls


@Retention(value=RUNTIME)
@Target(value=TYPE)
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.

Since:
5.0
Author:
Galder ZamarreƱo

Optional Element Summary
 int id
           
 Class[] typeClasses
           
 String[] typeClassNames
           
 

typeClasses

public abstract Class[] typeClasses
Default:
{}

typeClassNames

public abstract String[] typeClassNames
Default:
{}

id

public abstract int id
Default:
2147483647

Google Analytics

Copyright © 2010 JBoss, a division of Red Hat. All Rights Reserved.