That’s what I was suggesting. The code works, but only if you put the required classes into codebases or class paths. It’s not a problem with mobile code, it’s a problem with resolution of objects in mobile code references. That’s why I mentioned ObjectSpace Voyager. It automatically sent/sends class definitions with object graphs to the remote VM.
Gregg > On Jan 23, 2017, at 3:03 PM, Michał Kłeczek (XPro Sp. z o. o.) > <michal.klec...@xpro.biz> wrote: > > The problem is that we only support (smart) proxies that reference only > objects of classes from their own code base. > We do not support cases when a (smart) proxy wraps a (smart) proxy of another > service (annotated with different codebase). > > This precludes several scenarios such as for example "dynamic exporters" - > exporters that are actually smart proxies. > > Thanks, > Michal > > Gregg Wonderly wrote: >> 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> <mailto: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> >>>>> <mailto: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 >> >> >
