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

[Galder Zamarreño]

On Dec 9, 2010, at 12:11 AM, Sanne Grinovero wrote:

> I'm liking Elias's suggestion to define the ids in xml, at least I
> would have a single place where I can clearly see
> and inspect usage of my used ids;

You can always have an interface with constants defining your IDs. That's what the Infinispan Core code does to allow a central view of the IDs that are allocated. I don't want Infinispan Core having to fiddle with GlobalConfiguration passed, or having to have some XML for internal works.

I understand your point though from a users perspective, and so I'll allow both IDs to be defined via XML or annotation. If there's clashes (i.e. same ID points to diff externalizers), a WARN/ERROR (?) message will be shown, but the end winner, just like in the EE world, will be XML.

> btw having the map logged in
> readable format at startup would be nice.

Both maps in operation will be logged on startup, but so far not doing anything fancy, just toString(). Any suggestion to what format you'd want to see?

> However getTypeParameters()[0] seems to me insufficient as for the
> requirement to reuse each externalizer for multiple cases.

+1

> 
> I'd rather use Galder's original proposal to have type(s) and ids
> provided by the class, but the ids would be a default only,
> especially useful for the autodiscovered externalizers, and then let
> the user override all ids in the XML if he wishes so.

Exactly. That's the conclusion to which I arrived in my comment above. At the end of the day, I'm trying to use the same mechanism to define Infinispan Core externalizers and foreign, or user-defined, ones, so your suggestion is what IMO can fit both use cases at the same.

> 
> Cheers,
> Sanne
> 
> 2010/12/8 Elias Ross <genman at noderunner.net>:
>> 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?
>> 
>> 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.
>> 
>> I feel having the IDs in one place also makes things easier to debug.
>> For network analysis, it's helpful as a reference.
>> 
>> 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?
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> 
> 
> _______________________________________________
> 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