On Aug 26, 2012, at 5:12 PM, Dennis Reedy <[email protected]> wrote:
> 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). Hi Dennis! What I'd like to not have to do, is all kinds of packaging and versioning control work. I'd like to be able to just "run watcha brung". Versioning happens, and I can appreciate dealing with it. However, I think it's also a good point of abuse which can lead to stuff just not working well, because versioning leads to breakage when testing escalates by orders of magnitude and some tests stop getting run. That's what I don't like about the world of OSGi. It seems too ridged and too tool intensive for the small applications. I would like to have something that enables all the dynamic code flexibility, but which has a much better depends-on graph resolution strategy so that one could build all the various "code source" bits and fully believe that there wasn't missing classes. Gregg > 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 >> >
