Relatively straightforward, most of the hard work was done by enabling River to run on other jvm's, J9 in particular...
The sun policy provider's only used in some tests, the nameservice providers (not incl in jdk9) were separated out, but were only used in tests. Some parts of jeri (encryption) also used to access the sun namespace, but no longer does. In Phoenix's case it's a matter of not using an exporter and using the jvm's built in Registry. River's registry exporter doesn't really provide abstraction and flexibility as the implementation can only be jrmp and must access classes in the sun namespace, otherwise the Activation system won't be found. So it seems a lot simpler not to do this. Regards, Peter. Sent from my Samsung device. Include original message ---- Original message ---- From: Patricia Shanahan <p...@acm.org> Sent: 16/08/2016 07:58:43 pm To: dev@river.apache.org Subject: Re: Phoenix RMI Registry and jdk9 To what extent is it feasible to move away from depending on com.sun.* classes in general? On 8/16/2016 1:46 AM, Peter wrote: > Phoenix specific JRMP Exporters for Activation and Registry don't play well >with jdk9 as they access sun.* classes. > > Only the Registry exporter is required, to allow ActivationGroup to find the >ActivationSystem using the RMI Registry. There are JERI alternatives for all >other Phoenix's exported remote objects. > > Phoenix has its own read-only Registry implementation. > > I think it would be wise to deprecate all JRMP Exporters, given their recent >removal from the 2.2.x branch. > > Phoenix can use the standard RMI registry instead by default, I propose three >configuration entries to allow Phoenix to create a standard RMI Registry using >only public hava api's, with specified port and RMI SocketFactory instances, >which allow users to use TLS should they wish to prevent unauthorised access >to the Registry. > > Regards, > > Peter. > > Sent from my Samsung device. > >
