Binary-incompatible changes in space objects and LocalView
I have a question regarding how binary-incompatible changes in space classes affects a LocalView.
We have an application A with embedded space, the space contains instances of classes C1, C2, C3. We have an application B which connects to A and creates a LocalView limited to classes C1 and C2. The class C3 is not used in the application B at all (it never attempts to read instances of this class from A).
Now we modify a space object class C3 in a binary-incompatible way, for example add a new property. We rebuild an application A with the new version of the class C3 and restart it. We restart the application B without rebuilding it. B's classpath still contains the old version of the class C3, but the class C3 is not used in B's application code.
We have observed that the LocalView in the application B reports an error "com.gigaspaces.internal.client.cache.SpaceCacheInitializationException: Failed to synchronize local view".
As far as I know, LocalView are implemented using replication. Does it mean that even though the LocalView in the application B does not contain class C3, the application B still requires a correct version of the class C3 in the classpath in order for the replication from A to B's LocalView to work properly?