----- Original message ----- > > On Jan 2, 2011, at 9:09 PM, Greg Trasuk wrote: > > > > On Sun, 2011-01-02 at 20:56, Peter Firmstone wrote: > > > > > > This is why I think the client needs to be provided with a standard way > > > of being run from a child classloader of the jini platform class loader, > > > in this way, a service, proxy and client running within the same jvm, > > > only share the jini platform (& policy) classes, everything else becomes > > > a private implementation concern, including which version of a library > > > to use. > > > > > Agreed, and the "surrogate" container I'm working on allows for separate > > classloaders and protection domains for each application. So as you say > > above, if one "application" provides a service and another > > "application" consumes that service, they are entirely independent of > > each other. > > Have you guys looked at the com.sun.jini.start.ServiceStarter class in depth? > The code there, which assembles the separate environments for each service, > works very well as a model (using the classes used there) to separate clients > as > well. It's not trivial to consume, but I just keep seeing discussion about > the > features of those classes and activities of that class which make me wonder if > there is something you need it doesn't provide, or if it is just a familiarity > issue. > > Gregg Wonderly >
Should we move service starter into the public api?