Gregg, If you want to use Netbeans RCP, then why not consider making everything OSGi-able? We are using a Netbeans RCP front end on a project I'm working on now (with a Rio-backend that uses a custom RMIClassLoaderSpi that does artifact resolution for an artifact URL, goodbye http codebases and good riddance:) ), and from what I see, you either need to wrap everything up and turn it into an OSGi module, or go whole-hog and make everything OSGi (its all or nothing).
Dennis On Aug 26, 2012, at 211PM, Gregg Wonderly wrote: > > On Aug 26, 2012, at 9:17 AM, Greg Trasuk <[email protected]> wrote: > >> See comments interspersed... >> >> >> On Sun, 2012-08-26 at 04:53, Peter Firmstone wrote: >>> There are some notable conditions that may exist in modular environments. >>> >>> 1. Lets get this out of the way first: Preferred proxy classes are >>> implementation classes, the modular environment has no place >>> managing proxy private implementation classes. >>> 2. In addition to the marshaled smart proxy implementation, >>> Serialized objects will be transferred between remote hosts and >>> these may not belong to the proxy preferred class list, instead >>> they will belong to the Java or Jini platforms, or the Service >>> API, a local modular environment requires these objects be >>> instantiated by the correct class instance, which may reside in >>> different ClassLoaders. >>> 3. Different versions of classes may be present locally in separate >>> ClassLoaders. >>> 4. Resolving classes for objects a smart proxy refers to may not be >>> visible via traditionally expected ClassLoader hierarchy trees. >>> These classes may need to be found by other means. These classes >>> needn't be visible to the smart proxy, fields may refer to a >>> common super class or interface. >>> 5. Service API must reside in a parent ClassLoader, so we need to >>> know super class names, to be able to nominate a suitable parent >>> ClassLoader for a smart proxy. >>> >> Small point - #5 isn't quite true, although that's the way most >> containers, Jini and otherwise, seem to operate. For instance, in most >> servlet containers, the servlet API is in a parent classloader to the >> servlet itself. Similarly, in the Jini Starter utility, the River API >> classes are in a parent classloader. This is usually done for the >> convenience of the container - it allows the container to access the >> same classes that the application does, without needing to use >> reflection. >> >> The correct, and slightly looser, constraint is that classes and >> interfaces used in the API must be visible to application classes. They >> could be in the same classloader as the applicaton classes. In the >> River container I'm working on in /skunk, the service API classes are >> actually in the same classloader as the application (much like the >> application would include the interface classes for a user-written >> service). The container communicates with the application using the >> Reflection API, and doesn't share any classloaders with the contained >> applications (except the system CL, of course). >> >> I guess what I'm saying is that it's hazardous to assume any particular >> classloader hierarchy. The classloader used to house the proxy should >> probably just have the application's context class loader as its parent. > > This is the flexibility that I think we need to focus on. We need to think > about class origins, and any time/place that River is interacting with class > loading, we should try and evaluate how that can be the least troublesome. > In some cases, no-flexibility can be less trouble. 100 interfaces and > abstract classes don't always make the best programming environment. One way > to do things, which works well, can be a good thing. > >> >>> This won't be so hard to implement if we have a ClassLoader registry and >>> we know super class names and version information, this information is >>> currently not annotated with the Object stream. >>> >> I don't think versions are required. Simply load any preferred classes >> from the codebase url that the remote object provides. > > I'd like to keep "Versioning" completely out of what River considers as part > of the "platform". The plugability of class loading should not hinder the > use of versioning. It may be a good idea to put down some sentences which > represent the features which we all agree versioning is represented by. Then > we can keep River from prohibiting those things as a choice. > > Gregg >
