On Aug 23, 2012, at 5:57 AM, Simon IJskes - QCG <si...@qcg.nl> wrote:
> On 19-08-12 14:09, Peter Firmstone wrote: > >> Thoughts? > > What is the main driver for the RMIClassLoader replacement? The technical details, are/were that the default behavior of PreferredClassProvider and RMIClassLoaderSPI, together said that the parent class loader of the unmarshalled objects' URLClassLoader, which was created using the annotation returned by RMIClassLoaderSPI, was null, or otherwise known as the system class loader. In netbeans, the correct parent class loader, is the class loader of the invoking class, because the system class loader is empty of anything except the basic netbeans platform classes which are enough to start module loading from the other class loaders which are created/associated with the "modules" that make up the netbeans application (whether or not it's the actual IDE application itself). So, I needed to augment the behavior of PreferredClassProvider and replace the RMIClassLoaderSPI implementation with a new one. The problem is, that you can't change the netbeans "classpath", at startup, with a "module". You have to rewrite all kinds of "configuration" and such and thus you can't plug in a different RMIClassLoaderSPI, at all. Thus, I decided to do what developers do best to solve software problems. I added another layer of indirection between Jini/River and the RMIClassLoaderSPI so that we could replace the behavior of RMIClassLoaderSPI programmatically, at runtime. I augmented PreferredClassProvider to call out to this new layer as well, to access the details about which parent class loader should be used. Additionally... When I was doing this, I was also imagining changes to how unmarshalling would be done, and so I wanted to be able to replace the entire behavior of RMIClassLoaderSPI in the river source, to potentially provide the start of a layer which would allow this to be done. In the old days, we had ObjectSpace's Voyager in the RPC community, and they provided a seamless behavior of sending objects between VMs. It just worked. The codebase annotation available through the RMIClassLoaderSPI getAnnotation() mechanisms, was passed on to the recipient VM so that it could load the same vintage class definition as was used by the sender. This, of course doesn't always "just work", but for many more applications, then not, it provides a more dependable mechanism because versioning all but disappears. Gregg Wonderly
