Agreed, please keep IIOP. "Small" as it is, IIOP is one of the niches I'd say Jini plays in, and it would be sensible to keep it.
Of course, this doesn't mean it has to be baked into the core code base - equally desirable would be a way to simply activate or layer in the appropriate adaptor, with simple instructions on how to do so? regards, Dawid Loubser On 14/11/2015 05:13, Dennis Reedy wrote: > +1 for keeping IIOP > > You never know what you’re going to need to integrate with. Right now for me > it’s fortran (not that IIOP helps here, just an example), go figure > > Regards > > Dennis > > >> On Nov 13, 2015, at 918PM, Peter <j...@zeus.net.au> wrote: >> >> Rivers IIOP implementation is very small and yet provides cross language >> capability. i think the minor maintenance burden is outweighed by its >> benefits. Corba is also an actively maintained standard. >> >> I think it should stay part of the platfom. >> >> JRMP should be deprecated, it provides less functionality than JERI and has >> security issues. >> >> Just my thoughts, >> >> Peter. >> >> Sent from my Samsung device. >> Include original message >> ---- Original message ---- >> From: Greg Trasuk <tras...@stratuscom.com> >> Sent: 14/11/2015 11:31:32 am >> To: dev@river.apache.org >> Cc: u...@river.apache.org <u...@river.apache.org> >> Subject: Re: [Discuss - Remove JRMP and IIOP support] >> >> >>> 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: >>> >>> netjini.jrmp.** >>> net.jini.iiop.** >>> >>> QA Harness classes that test any of the above. >>> >>> >>> Cheers, >>> >>> Greg Trasuk >>
