[infinispan-dev] @Marshallable as an option for end user externalizers?

[Sanne Grinovero]

2011/3/16 Manik Surtani <manik at jboss.org>:
>
> On 16 Mar 2011, at 18:14, Galder Zamarreño wrote:
>
>> Hi,
>>
>> Some feedback has come saying that it'd be nice to be able to configure externalizers using annotations. Now, in a previous discussion (http://lists.jboss.org/pipermail/infinispan-dev/2010-December/007047.html) it was agreed that for framework developers this is not nice since it makes it hard to abstract the Infinispan layer, but end users might be interested in using annotations rather than having to implement getId(), getTypeClasses() in Externalizer interface - see http://community.jboss.org/docs/DOC-16198
>>
>> To be able to support this, @Marshallable annotation that would be used wth externalizer implementations would have to be brought back with id and typeClasses attributes. That'd make it a 3rd way to define ids, after XML and getId() implementations.
>>
>> Clearly, getId() and getTypeClasses() would be moved to a different interface, so that people that chose to use @Marshallable could just provide read/writeObject method implementations.
>>
>> The gain from having end users use @Marshallable is not that great IMO cos we don't do annotation scanning, so there would still be a need to register externalizers.
>
> Why don't we do annotation scanning?  We maintain a table of externalizers keyed on class, right?  So why not scan each new type (the first time we encounter it) for @Marshallable to compile this externalizer table on the fly?
>
> Is it to do with classloader leaks?  If so, a weak map could be used for this table...

+1
In some form we'll have to do annotation scanning anyway, I assume you
want to finish integrating the Query module to support adding new
entities on the fly. That will need some more advanced trivial garbage
collection.

Cheers,
Sanne

>
> Cheers
> Manik
>
> --
> Manik Surtani
> manik at jboss.org
> twitter.com/maniksurtani
>
> Lead, Infinispan
> http://www.infinispan.org
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>