river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: Phoenix RMI Registry and jdk9
Date Tue, 16 Aug 2016 11:13:41 GMT
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 <pats@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. 
> 
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message