[
https://jira.jboss.org/jira/browse/ISPN-244?page=com.atlassian.jira.plugi...
]
Galder Zamarreno commented on ISPN-244:
---------------------------------------
Obviously, an exception would returned if users defined negative numbers.
Main benefits of Externalizer vs Externalizable:
- Externalizer implementations create the actual objects, so this promotes encapsulation
and immutability. For example, if Externalizer is implemented as inner static class, the
class still needs to be public but ctror can be package default and you can keep your
instance variables as final!!!
Do not mandate @Marshallable in user/framework defined classed cos often users might not
be able to modify source code of these classes.
Enable external user/framework defined Externalizers
----------------------------------------------------
Key: ISPN-244
URL:
https://jira.jboss.org/jira/browse/ISPN-244
Project: Infinispan
Issue Type: Feature Request
Components: Marshalling
Reporter: Galder Zamarreno
Fix For: 4.1.0.BETA1
Create an internal magic number (i.e. -1 or 255) for user defined externalizers. This is
done to avoid users using our number space.
So, internally: <magic_number> <stream>
Users: <magic_number><user defined magic number (int)> <stream>
Mandate unsigned ints so that we can optimise by sending them as variable lenght
Internal frameworks could use high enough numbers for example up to 2 bytes: 5000, 7000,
20000
1 byte: 128
2 bytes: 32767
3 bytes: ...
GlobalConfiguration.registerMarshallable(Class type, Externalizer ext, int id);
Maybe CacheManager better?
CacheManager.registerMarshallable(Class type, Externalizer ext, int id);
Future improvement, maybe generate ids automatically for user defined classes?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira