I've recently reached a milestone regarding testing of the jgdms modular maven build (in OSGi bundle format based on River 3.0,) where 99.6% of the qa test suite is now passing.
I haven't run the jtreg test suite against it yet, but will do so in coming weeks. Note that at this stage it has not been tested in an OSGi environment. The following changes have been made to provide support for OSGi: 1. Modules are also OSGi bundles 2. Service implementation modules now depend on proxy / download modules (as per Rio module practices). Serializable objects used by a service have the same ClassLoader visibility through the same proxy / download module at the server and client endpoints. Service implementation classes will not be visible to serializable objects and don't need nor should be (a significant security advantage reducing both endpoints attack surface). 3. ServiceLoader providers will be automatically registered with the osgi service registry. The discovery implementations are in their own module and available from the osgi service registry for example. I'm planning on using the module structure / layout / relationships as a guide for River 3.1 I'm also considering renaming JGDMS to Overture after the Jini experimental pre release of the same name. Note this code has been security hardened in other ways including the latest tls v1.2 cyphers, removal of insecure cyphers, input validation for deserialization as well as delayed unmarshalling that allows authentication before provisioning service proxy modules during discovery and lookup. I'm not sure how popular phoenix activation is, but it too now has has the option of using secure sockets for the rmi registry to prevent unauthorised access. Regards, Peter. Sent from my Samsung device.
