On Dec 7, 2010, at 7:16 PM, Sanne Grinovero wrote:
Hi,
Is the Clazz going to be matched with some degree of polymorphism?
No, it'll be matched on equality, so no polymorphism there.
Or will I be able to use the same externaliser for multiple types,
so
effectively having something like
marshallable.setTypeClasses(Class... types)
and
@Marshalls(typeClasses={Person.class}, id=768)
That could certainly be handy. Good suggestion Sanne :). It's not uncommon to see the
same Externalizer type being used for different classes. For example, within Infinispan
you have:
JDK_EXTERNALIZERS.put(HashMap.class.getName(), MapExternalizer.class.getName());
JDK_EXTERNALIZERS.put(TreeMap.class.getName(), MapExternalizer.class.getName());
Where MapExternalizer externalizes both HashMap and TreeMap.
Cheers,
Sanne
2010/12/7 Manik Surtani <manik(a)jboss.org>:
> All looks great. +1 to annotating externalizers rather than the class being
externalized, but how would you match them up? When the marshalling framework sees Class
clazz, would it try and match the classes using clazz.equals()? We'd need to consider
class loader implications...
>
> +1 to making the config easier too.
>
>
> On 7 Dec 2010, at 09:49, Galder Zamarreño wrote:
>
>> 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(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Manik Surtani
> manik(a)jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
>
http://www.infinispan.org
>
http://www.jbosscache.org
>
>
>
>
>
> _______________________________________________
> 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