- Don’t use any type not in the JVM
- Encode the version in the payload
- Don’t use Java serialisation but use JSON and use the available types on the 
receiving side to map the JSON back. If the type is not available turn it into 
a Map. Receivers can easily turn a map back into a DTO if they want to.

This is one of the most vexing problems in software. Most developers want the 
convenience of automatic serialisation but forget that it is really hard to 
ensure a consistent class space between different processes. Keeping the types 
on the wire simple makes life a lot easier imho.

Kind regards,

        Peter Kriens


> On 1 Jun 2017, at 10:26, João Assunção <joao.assun...@exploitsys.com> wrote:
> 
> Hello all,
> 
> I'm working in a service to support distributed events across OSGi 
> containers. By distributed events, I mean forwarding events from one Event 
> Admin to a Event Admin running in separate OSGi container. For this purpose 
> I'm using Hazelcast.
> Due to object serialization in Hazelcast and to avoid ClassNotFoundExceptions 
> my bundle uses DynamicImport-Package: *. The reasoning behind the * is that I 
> don't know what classes might be in the event payload.
> This works but I'm not satisfied with this DynamicImport solution. 
> Can anyone suggest me alternatives?
> Thanks in advance.
>  
> Regards,
> 
> João Assunção
> 
> Email: joao.assun...@exploitsys.com <mailto:joao.assun...@exploitsys.com>
> Mobile: +351 916968984
> Phone: +351 211933149
> Web: www.exploitsys.com <http://www.exploitsys.com/>
> 
> 
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev

_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Reply via email to