On May 26, 2010, at 856AM, Greg Trasuk wrote: > > On Tue, 2010-05-25 at 13:20, Dennis Reedy wrote: >> On May 25, 2010, at 1156AM, Patrick Wright wrote: >>> I myself would just >>> like to see River move away from the idea that dynamic download via >>> codebase services is a requirement, more or less, of using Jini, and >>> to provide a reasonable/workable alternative for those that don't need >>> it. >> >> Sums up the entire impetus to this thread, well said! > > Just curious, here... > > Dynamic loading of proxy classes has always seemed (to me) to be at the > core of the Jini philosophy. Much of the dynamic discovery, dynamic > redeployment, the concepts in Jim Waldo's "The End of Protocols" > (http://java.sun.com/developer/technicalArticles/jini/protocols.html), > Frank Somers' "Survival of the Fittest Jini Services" > (http://www.javaworld.com/javaworld/jw-04-2001/jw-0413-jiniology.html), > etc, goes away if you take out dynamic proxy loading. > > So what's the downside of dynamic download, specifically?
Lost codebase issue for one. Figuring out how to best deploy the artifacts for services is another. And having each developer/deployer figure that out for themselves exacerbates the issue. Also, we have found that in a large distributed system composed of (lots of) services, relying on http(md:) based class loading has definite issues as it relates to the infamous "too many open files" exception [1]. Using a maven repository to access artifacts that have been built & tested, both in development (snapshots) and deployed (immutable artifacts) allows River to take advantage of managed repositories of available artifacts. Using the dependency management capabilities we can easily derive the classpath of a service's artifacts, in the exact same way as the service has been developed and tested. You can still load the classes dynamically, you just load them locally as opposed to remotely each time. And, if local, trust becomes implicit since the classes do not come from a remote location (each time). So all of the jewels of Jini still are still intact, this approach just allows the requisite jars to be first downloaded to the client from a maven repository, then loaded locally. Dennis [1] Bug ID 4166799, manifests itself on RHEL. If you scroll down you'll see it is not fixed.
