Re: [infinispan-dev] Preliminary implementation for ISPN-244 and improvement suggestions.
On Dec 8, 2010, at 10:58 PM, Elias Ross wrote:
On Wed, Dec 8, 2010 at 1:05 PM, Mircea Markus
<mircea.markus(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache