In case anyone's concerned, maven or osgi isn't mandatory, this is simply intended to make River play well with OSGi.
Making River play well with OSGi shouldn't be of concern to those who don't want the option, as the existing functionality and use cases will continue working, this functionality is assured by tests. For OSGi, we're ensuring class visibility is identical at each endpoint. The smart proxy code / bundle / version is a service implementation concern. The use of java serialization is also a service implementation concern that can be replaced in future. It's my intent to bring this functionality to River once it has stabilised. Some River developers / users have often strongly expressed their preference towards maintaining a stable trunk, that hasn't changed. My preference would be for a git based repo, as git workd very well with a stable trunk with fork and merge development. Svn is beter suited to an experimental trunk with a period of stabilisation prior to branching for release. A piece of trivia, the modular build uses maven for code that will be released, ant for the test suite and make for CA cert generation for jtreg tests. Maven modules certainly simplify River , it organises the code into understandable digestible bites. Cheers, Peter. Sent from my Samsung device. Include original message ---- Original message ---- From: Peter <j...@zeus.net.au> Sent: 21/04/2017 12:37:09 pm To: dev@river.apache.org <dev@river.apache.org> Subject: Recent Progress 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.
