在將Hessian從3.0.13升級(jí)到3.2.0時(shí)碰到兩個(gè)bug和一個(gè)ClassLoader處理策略的改變的問題，在此記錄下，希望能為使用Hessian 3.2.0的同學(xué)們提供點(diǎn)幫助，避免再走同樣的彎路。
Bug 1：HessianInput的readObject(Class)無效
對(duì)于使用Hessian 1的同學(xué)而言，有可能會(huì)使用到HessianInput的readObject(Class)這個(gè)方法，以實(shí)現(xiàn)將輸入流反序列化為指定的類實(shí)例，這在有一個(gè)場景中是很需要的，例如序列化時(shí)序列化的是一個(gè)子類對(duì)象，但反序列化時(shí)需要反序列化為父類，這個(gè)時(shí)候就非常需要這方法了，在Hessian 3.2.0之前的版本中這個(gè)沒有問題，但升級(jí)到3.2.0后就出現(xiàn)問題了，指定了Class會(huì)無效。
跟蹤Hessian 3.2.0代碼，發(fā)現(xiàn)它把之前版本的HessianInput的readObject(Class)方法做了改動(dòng)，改為了：
String type = readType();
// hessian/3386
if ("".equals(type)) {
Deserializer reader;
reader = _serializerFactory.getDeserializer(cl);
return reader.readMap(this);
}
else {
Deserializer reader;
reader = _serializerFactory.getObjectDeserializer(type);
return reader.readMap(this);
}
從上面代碼可以看出，只要序列化流中有類型信息，那么就完全忽視傳入的指定的Class類型，而在hessian中貌似只有Map類型的才不會(huì)寫type信息，其他都會(huì)寫，所以就導(dǎo)致了這個(gè)地方大多數(shù)情況下都會(huì)無視傳入的指定的Class類型，更讓人郁悶的是，去看Hessian2Input.readObject(Class)方法，它的處理方式就是正確的，在type不為""的情況下，它的處理方式為：
Deserializer reader;
reader = findSerializerFactory().getObjectDeserializer(type, cl);
return reader.readMap(this);
而默認(rèn)的SerializerFactory的getObjectDeserializer的實(shí)現(xiàn)如下：
Deserializer reader = getObjectDeserializer(type);
if (cl == null
|| cl.equals(reader.getType())
|| cl.isAssignableFrom(reader.getType())
|| HessianHandle.class.isAssignableFrom(reader.getType())) {
return reader;
}
if (log.isLoggable(Level.FINE)) {
log.fine("hessian: expected '" + cl.getName() + "' at '" + type + "' ("
+ reader.getType().getName() + ")");
}
return getDeserializer(cl);
從上面這段代碼的實(shí)現(xiàn)來看，是可以滿足傳入指定的Class類型的方式的需求的。
因此修正這個(gè)BUG的方法為，繼承HessianInput，并覆蓋它的readObject(Class)方法，將其中type不為""的處理方式改成和Hessian2Input一樣，重新測(cè)試，OK。
這個(gè)Bug即使到最新的Hessian 3.2.1里也沒有修復(fù)，因此暫時(shí)仍然需要自行處理。
Bug 2：當(dāng)Map中或?qū)ο笾杏袃蓚€(gè)long[]時(shí)反序列化出錯(cuò)
這個(gè)問題還真要湊巧才能碰上，大家可以自己寫段簡單的程序測(cè)試一下，用Hessian2Input和Hessian2Output去完成下面datas對(duì)象的序列化和反序列化：
Map<String,Object> datas=new HashMap<String,Object>();
datas.put("1",new long[]{1L,-1L});
datas.put("2",new long[]{2L,-2L});
反序列化的時(shí)候會(huì)拋出UnsupportedOperationException或java.util.Map cannot assigned from null這樣的異常信息，而且如果Map中只有一個(gè)long[]數(shù)組是不會(huì)拋異常的，詭異呀，跟蹤Hessian 3.2.0代碼，發(fā)現(xiàn)有個(gè)很詭異的地方，在有兩個(gè)數(shù)組后，Hessian會(huì)調(diào)用BasicDeserializer中的readLengthList方法，這個(gè)方法中竟然沒有對(duì)long[]數(shù)組的處理，而只有對(duì)其他布爾型數(shù)組、短整型數(shù)組、整型數(shù)組等的處理，而當(dāng)long[]數(shù)組的情況調(diào)用這個(gè)方法時(shí)，即拋出了UnsupportedOperationException異常，而更搞的是BasicDeserializer中的readList方法中是有對(duì)long[]數(shù)組的處理的，于是基本可以判斷是Hessian的開發(fā)者漏寫了對(duì)long[]的處理。
修正這個(gè)bug可以采用這兩種方法：
1、修改BasicDeserializer，在readLengthList方法中加上對(duì)LONG_ARRAY的處理；
2、升級(jí)為Hessian 3.2.1，修復(fù)了這個(gè)bug，修復(fù)方法和1相同。
在升級(jí)到Hessian 3.2.0或3.2.1時(shí)還有個(gè)需要注意的問題，對(duì)于有些需要操作序列化時(shí)ClassLoader的同學(xué)有可能會(huì)碰到，Hessian 3.2.0以前的版本是在反序列化之前獲取線程上下文ClassLoader來獲取Class的，但在3.2.0+后，改變了這個(gè)策略，改為了在SerializerFactory實(shí)例化的時(shí)候就去獲取線程上下文ClassLoader，以后在反序列化時(shí)就不再去獲取了，這個(gè)方式對(duì)于需要控制ClassLoader的同學(xué)來說會(huì)有點(diǎn)麻煩，但還好Hessian還提供了一個(gè)方式，就是允許在創(chuàng)建SerializerFactory對(duì)象時(shí)傳入ClassLoader，這就爽了，不用像以前一樣需要通過控制線程上下文ClassLoader了，這種方式更為優(yōu)雅，值得推薦。