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
