[infinispan-dev] Preliminary implementation for ISPN-244 and improvement suggestions.

[Galder Zamarreño]

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()[0]
> 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
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache