Agree with Niclas. I don’t understand the resolution comment. Not only is OSGi <> Jini integration feasible but it is a historical fact. Paremus did this - and a pretty good job we did - in … something like 2006 :-/
If the River community decided that there is interest in OSGi - then I’d suggest reading the Remote Service and Remote Service Admin specifications and thinking about how Jini concepts might enhance that world view. There are well over 10 million OSGi enabled IoT gateways out there! Sorry - I see no compelling technical or commercial arguments for the JBoss Module route. > On 16 Nov 2016, at 08:11, Niclas Hedhman <nic...@hedhman.org> wrote: > > I am curious, what do you mean by "non-deterministic dependency resolution" > ? You can make it as predictable as you wish with attributes and > directives. > > Cheers > Niclas > > On Wed, Nov 16, 2016 at 4:07 PM, Michał Kłeczek <michal.klec...@xpro.biz> > wrote: > >> While non-hierarchical class loading is crucial, OSGI with its >> non-deterministic dependency resolution is very difficult ( if not >> impossible ) to target. >> I'm working on JBoss Module based class loading for River which I'm going >> to propose as contribution soon. >> >> Thanks, >> Michal >> >> On Wednesday, 16 November 2016, Dawid Loubser <da...@travellinck.com> >> wrote: >> >>> +1 for OSGi providing the best solution to the class resolution problem, >>> though I think some work will have to be done around trust, as you say. >>> >>> >>> On 16/11/2016 02:23, Peter wrote: >>>> >>>> The conventional alternatives will remain; the existing ClassLoader >>> isolation and the complexities surrounding multiple copies of the same or >>> different versions of the same classes interacting within the same jvm. >>> Maven will present a new alternative of maximum sharing, where different >>> service principals will share the same identity. >>>> >>>> Clearly, the simplest solution is to avoid code download and only use >>> reflection proxy's >>>> >>>> An inter process call isn't remote, but there is a question of how a >>> reflection proxy should behave when a subprocess is terminated. >>>> >>>> UndeclaredThrowableException seems appropriate. >>>> >>>> It would plug in via the existing ClassLoading RMIClassLoader provider >>> mechanism, it would be a client concern, transparent to the service or >>> server. >>>> >>>> The existing behaviour would remain default. >>>> >>>> So there can be multiple class resolution options: >>>> >>>> 1. Existing PrefferedClassProvider. >>>> 2. Maven class resolution, where maximum class sharing exists. This >> may >>> be preferable in situations where there is one domain of trust, eg within >>> one corporation or company. Max performance. >>>> 3. Process Isolation. Interoperation between trusted entities, where >>> code version incompatibilities may exist, because of separate development >>> teams and administrators. Each domain of trust has it's own process >>> domain. Max compatibility, but slower. >>>> 4. OSGi. >>>> >>>> There may be occassions where simpler (because developers don't need to >>> understand ClassLoaders), slow, compatible and reliable wins over fast >> and >>> complex or broken. >>>> >>>> A subprocess may host numerous proxy's and codebases from one principal >>> trust domain (even a later version of River could be provisioned using >>> Maven). A subprocess would exist for each trust domain. So if there are >>> two companies, code from each remains isolated and communicates only >> using >>> common api. No unintended code versioning conflicts. >>>> >>>> This choice would not prevent or exclude other methods of >> communication, >>> the service, even if isolated within it's own process will still >>> communicate remotely over the network using JERI, JSON etc. This is >>> orthogonal to and independant of remote communication protocols. >>>> >>>> OSGi would of course be an alternative option, if one wished to execute >>> incompatible versions of libraries etc within one process, but different >>> trust domains will have a shared identity, again this may not matter >>> depending on the use case. >>>> >>>> Cheers, >>>> >>>> Peter. >>>> >>>> ESent from my Samsung device. >>>> >>>> Include original message >>>> ---- Original message ---- >>>> From: "Michał Kłeczek (XPro Sp. z o. o.)" <michal.klec...@xpro.biz >>> <javascript:;>> >>>> Sent: 15/11/2016 10:30:29 pm >>>> To: dev@river.apache.org <javascript:;> >>>> Subject: Re: Maven Build >>>> >>>> While I also thought about out-of-process based mechanism for execution >>> of dynamically downloaded code, I came to the conclusion that in the >>> context of River/Java in-process mechanism is something that MUST be done >>> right. All other things can (and should) be built on that. >>>> >>>> I think that the proposal to implement "remote calls on smart proxy >>> interfaces that aren't remote" is somewhat a misnomer. The call is either >>> remote or local - you cannot have both at the same time. AFAIK Jini >>> community always believed there is no possibility to have local/remote >>> transparency. That is why there exists java.rmi.Remote marker interface >> in >>> the first place. >>>> >>>> There is also the question about the level of isolation you want to >>> achieve. Simple "out-of-process" is not enough, chroot is not enough, >>> CGROUPS/containers/jails/zones might be not enough, virtual machines >> might >>> be not enough :) - going the route you propose opens up the whole world >> of >>> new questions to answer. At the same time you loose the most important >>> advantages of in-process execution: >>>> - simplicity of communication between components (basic function call, >>> no need to do anything complicated to implement callbacks etc.) >>>> - performance >>>> >>>> In the end you either standardize on the well known set of >> communication >>> protocols (such as JERI) OR you say "end of protocols" by allowing >>> execution of dynamically downloaded code in-process. >>>> If River is going to choose the first route - IMHO it is going to fail >>> since it does not propose anything competitive comparing to current >>> mainstream HTTP(S)/REST/JSON stack. >>>> >>>> Thanks, >>>> Michal >>>> Peter November 15, 2016 at 8:28 AM >>>> I've been thinking about process isolation (instead of using >>> ClassLoader's for isolation). Typically, smart proxy's are isolated in >>> their own ClassLoader, with their own copies of classes, however with >>> Maven, a lot more class sharing occurs. Since River uses codebase >>> annotations for identity, using maven codebase annotations will result in >>> proxy's from different services sharing identity. >>>> >>>> A better way to provide for different identities coexisting on the same >>> node, would be to use subprocess jvm's for each Service's server >> principal >>> identity, to keep classes from different services in different processes. >>>> >>>> This way, each principal would have their own process & Maven namespace >>> for their proxy's. >>>> >>>> Presently JERI only exports interfaces in reflection proxy's that >>> implement Remote, so I'd need an endpoint that can export all >> interfaces, >>> accross a local interprocess connection to allow remote calls on smart >>> proxy interfaces that aren't remote. >>>> >>>> This also means that memory resource consumption of smart proxy's can >> be >>> controlled by the client and a smart proxy's process killed without >> killing >>> the client jvm. >>>> >>>> Cheers, >>>> >>>> Peter. >>>> >>>> >>>> >>>> Dawid Loubser November 15, 2016 at 8:50 AM >>>> As a very heavy Maven user, I wanted to say that this is great news. >>>> This is encouraging indeed! >>>> >>>> Dawid >>>> >>>> >>>> Peter November 15, 2016 at 4:08 AM >>>> Some other news that might encourage participation, I've been working >>> on Dennis Reedy's script to modularise the codebase, I haven't run the >> test >>> suites against it and it isn't generating stubs yet, and I'll need to >>> modify the platform modules for the IoT effort after the conversion is >>> complete. >>>> >>>> Here's the output of the River maven build: >>>> >>>> Reactor Summary: >>>> >>>> River-Internet Project ............................ SUCCESS [0.689s] >>>> Module :: River Policy ............................ SUCCESS [8.395s] >>>> Module :: River Resources ......................... SUCCESS [0.607s] >>>> Module :: River Platform .......................... SUCCESS [23.521s] >>>> Module :: River Service DL Library ................ SUCCESS [8.999s] >>>> Module :: River Service Library ................... SUCCESS [8.014s] >>>> Module :: River Service Starter ................... SUCCESS [3.930s] >>>> Module :: River SharedGroup Destroy ............... SUCCESS [3.018s] >>>> Module :: Outrigger .............................. SUCCESS [0.056s] >>>> Module :: Outrigger Service Download classes ...... SUCCESS [2.416s] >>>> Module :: Outrigger Service Implementation ........ SUCCESS [4.118s] >>>> Module :: Outrigger Snaplogstore ................. SUCCESS [3.273s] >>>> Module :: Lookup Service ......................... SUCCESS [0.048s] >>>> Module :: Reggie Service Download classes ........ SUCCESS [3.966s] >>>> Module :: Reggie Service Implementation .......... SUCCESS [3.621s] >>>> Module :: Mahalo ................................. SUCCESS [0.436s] >>>> Module :: Mahalo Service Download classes ......... SUCCESS [2.059s] >>>> Module :: Mahalo Service Implementation ........... SUCCESS [4.175s] >>>> Module :: Mercury the Event Mailbox ............... SUCCESS [0.497s] >>>> Module :: Mercury Service Download classes ........ SUCCESS [3622s] >>>> Module :: Mercury Service Implementation .......... SUCCESS [3.562s] >>>> Module :: Norm .................................... SUCCESS [0.013s] >>>> Module :: Norm Service Download classes ........... SUCCESS [2.867s] >>>> Module :: Norm Service Implementation ............. SUCCESS [6.390s] >>>> Module :: Group ................................... SUCCESS [0.025s] >>>> Module :: Mahalo Service Download classes ......... SUCCESS [2.877s] >>>> Module :: Group Service Implementation ............ SUCCESS [2.037s] >>>> Module :: Tools ................................... SUCCESS [0.485s] >>>> Module :: Check ConfigurationFile ................. SUCCESS [2.720s] >>>> Module :: Check serialversionUid .................. SUCCESS [2.129s] >>>> Module :: ClassDep ................................ SUCCESS [4.157s] >>>> Module :: Class Server ............................. SUCCESS [3.353s] >>>> Module :: Compute message digest .................. SUCCESS [1.734s] >>>> Module :: Compute httpmd codebase ................. SUCCESS [2.102s] >>>> Module :: Environment Check ...................... SUCCESS [2.837s] >>>> Module :: Jar wrapper ............................ SUCCESS [2.179s] >>>> Module :: Preferred classes list generator ........ SUCCESS [2.495s] >>>> Module :: Phoenix Activation ..................... SUCCESS [0.029s] >>>> Module :: Phoenix Download ....................... SUCCESS [2.685s] >>>> Module :: Phoenix ................................ SUCCESS [4.095s] >>>> Module :: Phoenix Group ........................... SUCCESS [2.445s] >>>> Module :: Phoenix Init ............................ SUCCESS [1.740s] >>>> River Distribution ................................ SUCCESS [10.523s] >>>> ------------------------------------------------------------ >> ------------ >>>> BUILD SUCCESS >>>> ------------------------------------------------------------ >> ------------ >>>> Total time: 2:29.804s >>>> Finished at: Mon Nov 14 22:22:31 EST 2016 >>>> Final Memory: 145M/247M >>>> ------------------------------------------------------------ >> ------------ >>>> >>>> >>>> >>>> >>> >>> >> > > > > -- > Niclas Hedhman, Software Developer > http://zest.apache.org - New Energy for Java
