river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Trasuk <tras...@stratuscom.com>
Subject Re: [Discuss - Remove JRMP and IIOP support]
Date Sat, 14 Nov 2015 01:31:32 GMT

> On Nov 13, 2015, at 6:23 PM, Peter <jini@zeus.net.au> wrote:
> i have done some investigation into implementing dynamic iiop stub generation.  glassfish
does this.
> I'd like to retain iiop.

I guess my question is why keep IIOP?  Is there a use case that IIOP/CORBA covers that is
not adequately addressed by JERI?  If I’m not mistaken, the Sun crew put it in there originally
in hopes of being able to interop with EJBs.  I don’t think that’s a reasonable use case.

> 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
> 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.
> ---- Original message ----
> From: Greg Trasuk <trasukg@stratuscom.com>
> Sent: 14/11/2015 05:02:42 am
> To: dev@river.apache.org
> Cc: user@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

View raw message