[jboss-dev-forums] [Design of JBossCache] - Re: Common marshalling infrastructure

[david.lloyd@jboss.com]

"galder.zamarreno at jboss.com" wrote : Hey David, I've started to look into how to integrate JBoss Marshalling into JBoss Cache. Here's a list of things I wanted to ask you about:
  | 
  | 1.- Would it be possible to upload source jars to the maven repo for next release?
  | 

Will do.  If I don't, feel free to yell at me. :-)

"galder.zamarreno at jboss.com" wrote : 2.- Looking at JBoss Marshalling, I saw that you're considering primitive arrays as known classes but primitive object arrays are not. Is this an oversight or on purpose? i.e.
  | 
  | map.put(Byte[].class, Protocol.ID_BYTE_ARRAY_CLASS);
  |   | map.put(Boolean[].class, Protocol.ID_BOOLEAN_ARRAY_CLASS);
  |   | map.put(Character[].class, Protocol.ID_CHAR_ARRAY_CLASS); 
  |   | ...
  | 

The reason for this is that primitive array classes do not extend the object array class.  Since all object arrays are represented by a single byte plus the component type information, there should be one byte to signify the array plus one byte for the primitive wrapper, which is two bytes (not too bad).  Likewise, e.g. Byte[][].class would be three bytes, etc.  If the length is still unacceptably long, a ClassTable can be used to reduce it down to a single byte.

"galder.zamarreno at jboss.com" wrote : 3.- Looks like collections like ArrayList, LinkedList, Hashmap, TreeMap...etc are treated as Serializable objects whereas JBoss Cache treats them differently. Instead, we look through the collection and see if it's an object we might want to marshall it in a diferent way to standard Serialization, i.e. a list of ReplicableCommand (ReplicableCommand does not implement Serializable). How would we deal with this?

That can depend.  You can always use an Externalizer for those types to override how the serialization occurs.  Another option is to use an ObjectTable, which lets you customize the serialization process to a slightly higher degree (at the cost that both the reader and the writer need to have matching ObjectTable specifications; Externalizers do not have this restriction as the writer's Externalizer is itself serialized).

"galder.zamarreno at jboss.com" wrote : 4.- Also, JBC treats SingletonList instances separately by just copying the single object within them. Any plans to add this to JBoss Marshalling as well?

This could also be easily handled with an Externalizer.

"galder.zamarreno at jboss.com" wrote : Other than this, JBoss Marshalling seems to contain the rest of optimisation JBC did for known type arrays, repeated objects, null values...etc. So, in spite of agreeing with Jason's statement in https://jira.jboss.org/jira/browse/JBCACHE-1336 earlier today:
  | 
  | anonymous wrote : It might be more useful to define type marshallers outside of the type since most of our magic numbers apply to types not under our control (JDK types). 
  | 
  | I don't think this might apply any longer if the above points can be resolved. IOW, all types that are not under our control would already be handled by JBoss Marshalling which means that we can concentrate on our types and we could then use @Marshallable annotations.

Yeah, I think that between ClassTable, ObjectTable and ClassExternalizerFactory you can implement all the customizations you need.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220413#4220413

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220413