Inline.... On 15 November 2011 23:10, Peter Firmstone <j...@zeus.net.au> wrote: > With River, we execute separately compiled bytecodes at runtime by taking > advantage of discovery and lookup services - distributed dependency > injection. Service API, Java and Jini Platforms provide compatibility, for > separately compiled components, these are the parent classes and interfaces > that clients and services use for communicating across compile time > boundaries, demarcated by Service API. > > Determining classes to be shared between proxy and client namespaces and > identifying what shouldn't be creates challenges for developers, who > currently need to define preferred class lists. >
Unless we find some means to make that a lot easier.... > My personal preference is to share as little as possible, how selfish! > Uh huh, useful default, see above. > The Java platform itself presents issues with Memory isolation, namespace > visibility, class resolution and codebase annotation loss for proxy's or > distributed objects. > > proxy - remote reference, implements Remote > distributed object - local copy of an object, serialized, implements > Serializable. > > If we share only the Service API, Java and Jini Platform classes and > objects, then we minimise Java platform issues. > > Proxy classes that extend services API, java or Jini platform classes don't > need to be visible to the client (the reverse holds true also), since client > code uses the super classes and interfaces in the Service API, Java or Jini > Platform. > > In reality client classes and any other libraries are loaded into the > application ClassLoader with the Service API and Jini Platform, so all these > additional classes are also visible to proxy's. > > If the proxy uses libraries or has classes in the same namespace as the > client, unless the proxy's classes are preferred, they will be resolved by > the application ClassLoader (the classes may or may not be compatible), if > the proxy is later transferred to another node in the network, the codebase > annotations have been lost because the classes were loaded by the > application class loader and resolved from the class path. If the 2nd > remote node doesn't have the required classes on its classpath, it's game > over. > True but, as I'm hinting, the problem is preferred classes aren't being set up right and that's where we should be focusing IMHO. > This problem could be solved if the Classpath isn't visible to the proxy, > only the ServiceAPI, Java and Jini Platform classes, so developers don't > have to understand ClassLoader visibility and preferred classes and may > instead just focus on developing services and getting their OS and network > to support multicast discovery. > Yep, you could try to solve these problems this way but I have a pretty strong feel in my gut that it'll be hard work, increase complexity substantially and be full of holes. Many of the problems you list ought to be solved in the JDK itself rather than fudged around with complex classloader structures (we all know where this goes, see any J2EE container for reference). That seems like an unlikely possibility so I'd be taking path of least resistance which appears to be improving the way we deal in preferred classes and establishing some meaningful defaults for setting up the necessary manifest entries etc. You could for example have the proxy share nothing of the platform bringing with it it's own versions on the basis that makes future versioning problems minimal. Of course it'll make for big .jars as downloads but hey ho. > Some options: > > 1. Use the extension classloader (command line option, not > /jre/lib/ext/) for ServiceAPI and Jini Platform classses, the > classpath will then not be visible to the proxy's that reside in > child classloaders of the extension classloader. Note classes in > the extension classloader can have reduced permission and don't > have to be AllPermission. > 2. OR Create a new child classloader, for the application and all > libraries. > 3. OR Use a Subprocess JVM for all smart proxy's (identified as > classes implementing Remote and having codebase annotations), the > JVM has been optimised to share platform class files with > subprocess jvm's for fast startup and less memory consumption. > However this requires reflective proxy's to represent smart > proxy's in the main jvm, the part I haven't figured out yet is how > to have a reflective proxy replaced by a smart proxy when it gets > transferred to another machine. Perhaps it might be possible > using a marker interface on the reflective proxy, however I'll > save that discussion for another thread. > > > To have any of these work properly would require a container, Tim > Blackman's Jini in a jar https://issues.apache.org/jira/browse/RIVER-342 > solves a number of the configuration, command line options and classpath > visibility issues using a new URL scheme, which enables a Jini application > to be run from a jar file. > > Do you think it's time we work towards a standard container? So that at > some point in the future all the downstream projects will be able to support > it as well as their existing container? > > What are the requirements for such a container? > > Regards, > > Peter. >
