Dynamic Externalizers sorted for ISPN-986 - looking for some feedback
by Galder Zamarreño
Hi,
Re: https://issues.jboss.org/browse/ISPN-986
As indicated in my comments, there's two room for two types of serialization mechanisms: one for end users and the other for SPIs.
I've got a solution for this in https://github.com/galderz/infinispan/commit/09096f7998c0d0a5aae76d55bf59... and wanted to give a heads up to everyone on what it involves:
- Two separate externalizer interfaces: Externalizer (which currently, to disrupt as little code as possible, is named EndUserExternalier) and ExternalizerSpi or ServiceProviderExternalizer (currently named Externalizer). The first API is basic read/write methods and the second one with a couple of more methods for more specialised behaivour. Do people like these names? Or can someone come up with better names? More detailed info on the use cases in the JIRA.
- A related factor here would be to find a better name for the XML/programmatic configuration, i.e. getServiceProviderExternalizers()? <serviceProviderExternalzer> or getExternalizeSpis() <externalizerSpi>? This is one thing and the other is that I'd want this XML and programmatic configuration to be a bit hidden away cos it's specialised or for edge cases. The obvious route the average Infinispan user should be annotation and implement Infinispan's Externalizer interface. However, I'm don't think there's anything special that can be done in the current architechture of Infinispan without rethinking end user and spi configuration.
- To hide JBoss Marshaller details away and to simplify some of the API it provides, I've created a new @MarshallableBy annotation that maps directly to what JBMAR's @Externalizer does. To get an idea of the differences for the end users, see https://github.com/galderz/infinispan/commit/09096f7998c0d0a5aae76d55bf59... as opposed to https://github.com/galderz/infinispan/commit/09096f7998c0d0a5aae76d55bf59.... Are people happy with the annotation name? The cool thing is that if someone wants to really use JBoss Marshaller Externalizers, they can, but I think the majority will be happy with just a read/write object method.
And that's about it! Afterwards it just needs proper documentation in wiki and javadocs, but right now I'm mostly focused at getting naming right. Thoughts?
Ideally I'd like to get this into BETA1 (release date next Tuesday, 5th April), but I'll prob hold till BETA2 to get the naming right.
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
13 years
@Marshallable as an option for end user externalizers?
by Galder Zamarreño
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.
Thoughts?
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
13 years
Got a hole in JIRA issue numbers
by Sanne Grinovero
Hello,
I'm sorry, I had an issue with JIRA, ISPN-1021, ISPN-1022, ISPN-1023
won't ever exist.
I created a new issue, but it failed as "disk is full". I then tried
again at later times, three in total, and it seems the problem was
just solved but somehow the previous issues where "half-inserted":
they where created, but there was no way to mark them as duplicates or
solve them, the only option I had was "delete", so that's what I did.
I hoped the counter would start back from ISPN-1021, but the issue I
finally inserted correctly is now ISPN-1024.
Not a huge problem, but I guess the gap is now permanent.
sorry,
Sanne
13 years, 1 month
