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

[Galder Zamarreño]

The changes proposed at the beginning, taking in account the feedback provided, is now in master and you can find the updated documentation in http://community.jboss.org/docs/DOC-16198

Next up I'll focus on https://issues.jboss.org/browse/ISPN-246 to get the corresponding module lifecycle for tree and server modules. Sanne, once these are done, you'll have a good a pretty good idea of what needs doing for the lucene directory impl.

On Dec 9, 2010, at 1:49 PM, Galder Zamarreño wrote:

> 
> 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
> 
> 
> _______________________________________________
> 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