I discovered a bug regarding our use of ComposedKey classes and the serialization of some of their fields in the context of the Caching mechanism. One of its fields (scopeId) is of type KapuaId. The problem is that sometimes we create ComposedKeys using a ScopeId instance and then we try to perform a lookup of the same cache entry but using a KapuaEid. If this doesn’t seem a problem from an object-oriented perspective, considering that they have the same internal Id and the equals method would return true, it is from a “serialization” for the cache perspective, because the serialization of the 2 fields is different and, as so, the lookup cannot behave as want.
I fixed the issue in the constructor of the ComposedKey class casting the various KapuaId passed in input to be a fixed KapuaEid
I discovered a bug regarding our use of ComposedKey classes and the serialization of some of their fields in the context of the Caching mechanism. One of its fields (scopeId) is of type KapuaId. The problem is that sometimes we create ComposedKeys using a ScopeId instance and then we try to perform a lookup of the same cache entry but using a KapuaEid. If this doesn’t seem a problem from an object-oriented perspective, considering that they have the same internal Id and the equals method would return true, it is from a “serialization” for the cache perspective, because the serialization of the 2 fields is different and, as so, the lookup cannot behave as want.
I fixed the issue in the constructor of the ComposedKey class casting the various KapuaId passed in input to be a fixed KapuaEid