i have done some investigation into implementing dynamic iiop stub generation.  
glassfish does this.

I'd like to retain iiop.

We could certainly remove JRMP, but it's worth remembering that 
MarshalledObject still ties us to RMI, hence the need to set a property that 
allows downloaded code 

java.rmi.server.useCodebaseOnly

In my local copy of River, all instances of MarshalledObject are marshalled and 
unmarshalled using MarshalledInstance .  The next step would be to use 
interface default methods to replace MarshalledObject parameters with 
MarshelledInstance and deprecate. serial form would retain MarshalledObject 
where it existed for compatibility.

 Phoenix and the test suite still use JRMP.  In my local copy of River I've 
converted the test suite to JERI, I may have committed it for River 3.0, I 
don't recall and would need to check.  My local copy of Phoenix uses JRMP , but 
only to establish a connection with rmi activation.

i have also removed rmi stubs from Phoenix except for one required for 
activation compatibility, that Isn't downloaded.  Instead phoenix  now uses 
reflection's proxy (again my local copy).

rmi stubs have been removed from all other services in my local copy of River.  

so there's quitez a lot of work required, something for River 3.1?

Regards
Peter.


Sent  from my Samsung device.
  Include original message
---- Original message ----
From: Greg Trasuk <tras...@stratuscom.com>
Sent: 14/11/2015 05:02:42 am
To: dev@river.apache.org
Cc: u...@river.apache.org
Subject: [Discuss - Remove JRMP and IIOP support]

Hello all: 

I’d like to suggest removing JRMP support (i.e. pre-compiled proxy classes), 
and IIOP support (i.e. CORBA).  JRMP is nicely replaced by JERI, which offers 
security and doesn’t require you to create compiled proxy classes by running 
rmic.  JRMP support was originally included in the Jini 2.0 release waaay back 
in 2001 or so, in order to allow backwards compatibility with Jini 1.2 
installations.  The IIOP support could in theory provide compatibility with 
native CORBA services (does anyone still do that?) or EJBs, but to my 
knowledge, it wasn’t widely used. 

The main reason for pruning theses capabilities is that unused code still 
requires maintenance and increases the chance of bugs.  Also I think that as we 
go forward with refactoring, renaming, restructuring the build and so on, it 
seems wasteful to do that work on code that isn’t actually in use. 

Obviously, the code remains in Subversion and in the 2.2.2 release, so if 
someone wants to get it back, we (or they) could package it into a different 
deliverable.  But I wouldn’t plan on doing that unless there’s actual demand 
for it. 

My thought is to put this out there for discussion - If there is consensus 
after a few days I’ll call a lazy-consensus vote.   I’ll be happy to do the 
work in the 2.2 branch. 

So, I propose to drop support for the following: 

net.jini.jrmp.** 
net.jini.iiop.** 
     
QA Harness classes that test any of the above. 


Cheers, 

Greg Trasuk

Reply via email to