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

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

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