[infinispan-dev] Providing a context for object de-serialization

[Mircea Markus]

----- Original Message -----
> From: "Sanne Grinovero" <sanne at infinispan.org>
> To: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
> Sent: Tuesday, June 26, 2012 5:13:28 PM
> Subject: [infinispan-dev] Providing a context for object de-serialization
> 
> Imagine I have a value object which needs to be stored in Infinispan:
> 
> class Person {
>    final String nationality = ...
>    final String fullName = ...
>  [constructor]
> }
> 
> And now let's assume that - as you could expect - most Person
> instances have the same value for the nationality String, but a
> different name.
> 
> I want to define a custom Externalizer for my type, but the current
> Externalizer API doesn't allow to refer to some common application
> context, which might be extremely useful to deserialize this Person
> instance:
> 
> we could avoid filling the memory of my Grid by having multiple
> copies
> of the nationality String repeated all over, when a String [1] could
> be reused.
> 
> Would it be a good idea to have the Externalizer instances have an
> initialization phase receiving a ComponentRegistry, so I could look
> up
> some custom service to de-duplicate or otherwise optimize my
> in-memory
> data representation?
> Personally I'd prefer to receive it injected via the constructor so
> that I could use a final field when my custom Externalizer is
> constructed.
+1. That's pretty easy to achieve by registering the Externalizers into the ComponentRegistry (or simpler just run the component registry wiring code on each externalizer object in the ExternalizerTable). Unfortunately our internal dependency injection framework doesn't support c-tor injection yet.