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

[Galder Zamarreño]

On Dec 7, 2010, at 11:40 AM, Sanne Grinovero wrote:

> Hi Galder,
> this seems great, I plan to try out soon implementing the ones for
> Lucene for a little extra performance boost.
> Just to double-check, no annotations are required on the externalized
> classes right? That would be a showstopper for example in the JIRA
> case as I don't have control over all marshalled source code.

See docu, no reference to annotations. As mentioned below, annotations on externalized classes was only needed for internal, core/ project classes, and again, as suggested below, I wanna swap this around.

> 
> The lucene-infinispan module will definitely use it, do you think
> there's a way to make it as simple as possible to have the ones I'll
> write registered for the end user?
> Maybe in a future release, could we add an SPI style discovery to
> self-register externalizers found on classpath?

This is precisely what the module lifecycle is there for: http://jira.jboss.com/jira/browse/ISPN-245

This is what the tree module will use to avoid users having to define externalizers for tree module.

If you need this (sounds like it), wait until I've done https://jira.jboss.org/browse/ISPN-246

> 
> And in case we have something like that in place, how will we
> guarantee ID unique assignments and also consistency across the
> cluster; as a starter should I reserve a range of identifiers
> in core, even without introducing dependencies; maybe later we should
> have a consistency check at node join to verify the same types are
> registered.

Uniqueness can be guaranteed by checking for duplicates which is already done. Consistency accross the cluster will be easier to achieve with me suggestions below, making ids part of code (annotation) rather than configuration. 

Hmmm, not sure about adding a consistency check to verify that your type is in the ID range that you're granted.... maybe the module lifecycle impl can do this. I'll add a note to try this out in the tree module lifecycle impl.

> 
> Sanne
> 
> 
> 2010/12/7 Galder Zamarreño <galder at redhat.com>:
>> Hi all,
>> 
>> Re: https://jira.jboss.org/browse/ISPN-244
>> 
>> This is trunk now and I've written preliminary documentation for it in http://community.jboss.org/docs/DOC-16198. Have a read through it and let me know what you think.
>> 
>> Now, there's a couple of improvements I'm considering doing even for alpha1:
>> 
>> 1. Internally, Infinispan has been mapping Externalizer classes and the types they marshall via @Marshallable interface. I don't think this annotation is really usable as it is for users cos there can be situations where users might not be able to modify the class that they wanna serialize. However, they for sure should be able to modify the Externalizer implementation classes, so I was wondering of converting this annotation into an annotation that an Externalizer class takes and that specifies the type of class that it externalizes and its id. Example:
>> 
>> class Person {
>> ...
>> }
>> 
>> @Marshalls(typeClass=Person.class, id=768)
>> class PersonExternalizer Implements Externalizer<Person> {
>> ...
>> }
>> 
>> This could be a mechanism that could be used in equal manner by both internal and user defined externalizers. We don't wanna be doing annotation scanning, so in the same fashion that for internal externalizers we list the type classes that can be extermalized, this could lead to a user configuration simplification, i.e:
>> 
>> <global>
>>  <serialization>
>>    <externalizers>
>>      <externalizer class="PersonExternalizer" />
>>    </externalizers>
>>  </serialization>
>> </global>
>> 
>> On startup we'd load the externalizers defined in configuration and search for the @Marshalls annotation which would give us the rest of info which is: typeClass and id. Thoughts?? I think this would make internal and user defined externalizers more homogeneous when it comes to their definition and would simplify configuration.
>> 
>> Chaging @Marshallable to @Marshalls should be easy to do particularly cos this annotation was only used for internal purpouses.
>> 
>> 2. The second improvement I had in mind is around programmatic configuration. As you can see in the docu, configuring programmatically user defined externalizers requires quite a bit of code. I was thinking of adding a helper method in global configuration that would hide all of that away. If you take in account my recommendations for the previous point, that would be limited to something along the lines of:
>> 
>> globalCfg.addExternalizer(PersonExternalizer.class);
>> 
>> Where the method would have a signature like: public void addExternalizer(Class<? externds Externalizer> externalizerClass);
>> 
>> We could also have an alternative that uses reflection to load the class and add it: public void addExternalizer(String externalizerClassName);
>> 
>> Cheers,
>> --
>> 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
>> 
> 
> _______________________________________________
> 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