river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <ge...@cox.net>
Subject Re: OSGi
Date Mon, 23 Jan 2017 20:45:31 GMT
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?


> On Jan 23, 2017, at 2:39 PM, Michał Kłeczek (XPro Sp. z o. o.) <michal.kleczek@xpro.biz>
> Gregg Wonderly wrote:
>>> michal.kleczek@xpro.biz <mailto:michal.kleczek@xpro.biz> <mailto:michal.kleczek@xpro.biz>
<mailto:michal.kleczek@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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message