edoclin opened a new issue, #101:
URL: https://github.com/apache/dubbo-hessian-lite/issues/101
### Pre-check
I am sure that all the content I provide is in English.
### Search before asking
I had searched in the issues and found no similar issues.
### Apache Dubbo Component
Java SDK (apache/dubbo)
### Dubbo Version
Apache dubbo： 3.3.4, java 8, hessian-lite 4.0.3
### Steps to reproduce this issue
hessian-lite/src/main/java/com/alibaba/com/caucho/hessian/io/UnsafeDeserializer.java#instantiate
hessian-lite/src/main/java/com/alibaba/com/caucho/hessian/io/JavaDeserializer.java#instantiate
Migrating from dubbo2 to dubbo3, some entity classes still initialize
default values, for example:
```java
public class Example { private String all = "all"; }
```
UnsafeDeserializer constructs objects via allocateInstance; in certain
scenarios, the deserialized object ends up with` obj.all = null` rather than
the default `obj.all = "all"`.
Using the startup parameter `-Dcom.caucho.hessian.unsafe=false` switches the
deserializer to
`hessian-lite/src/main/java/com/alibaba/com/caucho/hessian/io/JavaDeserializer.java`,
which effectively solves the field default value issue.
However, when JavaDeserializer deserializes BigInteger with a null
constructor argument, it throws an NPE (compared to dubbo2.7:
`com.alibaba.com.caucho.hessian.io.BigIntegerDeserializer` provides a dedicated
compatibility class).
Is there a method to make UnsafeDeserializer honor field default
initializations, or a way to make JavaDeserializer compatible with BigInteger
deserialization?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
