I guess I am not sure then what you are trying to show with your example. Under what case would the SpacePublisher be sent to another VM, and how is that different from normal SmartProxy deserialization?
Gregg > On Jan 23, 2017, at 2:39 PM, Michał Kłeczek (XPro Sp. z o. o.) > <michal.klec...@xpro.biz> wrote: > > > > Gregg Wonderly wrote: >>> michal.klec...@xpro.biz <mailto:michal.klec...@xpro.biz> >>> <mailto:michal.klec...@xpro.biz> <mailto:michal.klec...@xpro.biz>> wrote: >>>> >>>>> The use case and the ultimate test to implement is simple - have a >>>> listener that publishes remote events to a JavaSpace acquired dynamically >>>> from a lookup service: >>>>> class SpacePublisher implements RemoteEventListener, Serializable { >>>>> private final JavaSpace space; >>>>> public void notify(RemoteEvent evt) { >>>>> space.write(createEntry(evt), ...); >>>>> } >>>>> } >>>>> >>>>> It is NOT possible to do currently. It requires non-hierarchical class >>>> loading. It is not easy to solve. It would open a whole lot of >>>> possibilities. >>>> >>>> I am probably too ignorant to see it; What exactly is "NOT possible" with >>>> the above use-case snippet? >>> With currently implemented PreferredClassProvider it is not possible to >>> deserialize such an object graph. >> >> This can happen, but what’s necessary is that the codebase of the >> SpacePublisher needs to include all the possible RemoteEvent classes, or the >> javaspace’s classpath has to include them. > I am not sure I understand. > The problem does not have anything to do with RemoteEvent (sub)classes. The > issue is that SpacePublisher cannot be deserialized at all ( except one case > when JavaSpace interface is available from context class loader and it is not > marked as preferred in SpacePublisher code base). > > Michal
