On Sun, 2010-12-12 at 02:39, Peter Firmstone wrote: > Yes, I had noticed the container, interesting. > > Do you think it's possible to organise runtime ClassLoader's so Jini's > API, Java and the Service API are loaded with Java's application class > loader, while all implementations are loaded into separate child class > loaders? If we do this, we can keep, service implementations, client > code and proxy's in separate namespaces, forcing them to cooperate using > only Java, Jini's API and Service API. Sort of like having separate > Classpath's for each, many are compiled separately so it makes sense if > they each bring their own lunch and don't step on each others > implementations and libraries etc.
Goes without saying...Also that we don't put every single jar file in the codebase annotation. Usually it's only the "-api" and "-dl" jar files, although there might be plain libraries as well. > Eg a proxy should bring with it any > additional libraries it needs and not rely on them being present at the > client. That's automatically handled by the rmi classloader (PreferredClassLoader I believe) and the appropriate codebase annotations. > Application libraries shouldn't be visible to the proxy. Sort > of like Preferred Classes, but automatic without configuration. > That's actually up to the application author; in many cases, there is a need to have a dependent library available locally (e.g. for business-domain object classes). The PreferredClassLoader mechanism used by Jeri allows the proxy to require a remotely downloaded class where it's absolutely necessary. > Cheers, > > Peter. > >
