The changes proposed at the beginning, taking in account the feedback provided, is now in
master and you can find the updated documentation in
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(a)noderunner.net>:
>> 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?
>>
>> 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(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
> _______________________________________________
> 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
_______________________________________________
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