PolicyFileProvider tests & jdk9
The policy file provider tests that utilise the sub policy provider are testing UmbrellaGrants, in this case we might be better off disabling these tests for jdk9. The ConcurrentPolicyFile provider has some optimisations to avoid populating a ProtectionDomain with permissions unless it has been granted AllPermmission (to avoid blocking during implies permission checks). This makes it an unsuitable replacement for the sun policy provider in this instance, unless we want to revise the tests to ignore the results of Policy.getPermissions(CodeSource) calls? Regards, Peter. Sent from my Samsung device.
Re: Phoenix RMI Registry and jdk9
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 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. > >
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.
Phoenix RMI Registry and jdk9
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.
