river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: river.jar
Date Mon, 03 Jan 2011 05:55:40 GMT

----- 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?
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message