[infinispan-dev] Preliminary implementation for ISPN-244 and improvement suggestions.
galder at redhat.com
Thu Dec 9 07:41:59 EST 2010
On Dec 8, 2010, at 10:58 PM, Elias Ross wrote:
> On Wed, Dec 8, 2010 at 1:05 PM, Mircea Markus <mircea.markus at jboss.com> wrote:
>> Isn't this possible even now through XML?
>> <marshallable id="456" typeClass="com.acme.Person" externalizerClass="com.acme.SameExternalizer"/>
>> <marshallable id="457" typeClass="com.acme.HotPerson" externalizerClass="com.acme.SameExternalizer"/>
> There are a few things that came to mind here:
> 1. In terms of assigning IDs, it needs to be fairly clear there's no
> "global" conflict and having IDs at the annotation level makes it a
> bit unclear what actual number goes with what class. Additionally,
> Infinispan (and users themselves) might want to provide externalizers,
> and unless there's assigned ranges to those teams, putting the ID
> within the annotation it somewhat difficult to reuse these classes.
> How would a team provide a combined cache from two separate instances
> that happen to use different externalizers with the same ID?
I don't understand what you're trying to imply here.
There's definitely a use case for having ids as part of the annotations, and that comes from Infinispan Core classes. I need to id them and clearly, I'm not gonna start fiddling with XML or try to change the GlobalConfiguration you pass me. So, I put these ids in an interface as constants and reference it from annotations. I'll explain myself further in the reply to Sanne's email.
> Still, having ranges reserved by Infinispan itself would make sense.
> If at all possible, I would restrict them to less than, say 64 or 32,
> thus allowing custom types to be passed as byte values.
Elias, see the JIRA(https://jira.jboss.org/browse/ISPN-244) for information on how this is coded.
Infinispan Core classes use a byte to define the marshaller. For user defined externalizers, there's a particular id that signals that a user id comes next. This ID is always positive for a reason, and that is to do variable length integers. So, if you pass 100, one byte, if u pass 40.000 2 bytes. So, not limiting users at all. As suggested in the JIRA, we're recommending frameworks to allocate 2 bytes for their ids, to allow end users to simply have 1 byte.
> I feel having the IDs in one place also makes things easier to debug.
> For network analysis, it's helpful as a reference.
Nothing stops you from putting your IDs as constants in an interface.
> 2. Can't the configuration be simply:
> <marshallable id="456" externalizerClass="com.acme.SameExternalizer"/>
> and then you simply call SameExternalizer.class.getTypeParameters()
> to determine the type class?
I don't wanna pollute Externalizer interface with a getTypeParameters() method. I think this type of metadata is better served by annotations IMO.
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
Sr. Software Engineer
Infinispan, JBoss Cache
More information about the infinispan-dev