> On Nov 13, 2015, at 6:23 PM, Peter <j...@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 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. > ---- 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
