river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: Usability - "The Platform"
Date Wed, 31 Aug 2011 18:51:16 GMT
My comment below reflects my thoughts that many of the problems could be solved by serializing
objects and reflective proxy's between the classloaders and between the subprocess jvm and
the client jvm.

The only common classes between the classloaders would be jeri and some management framework
packages.
 
This could potentially fix many underlying issues experienced by developers.

Cheers,

Peter
----- Original message -----
> > Peter, I am not sure I really understand the exact issue(s) that you want to
> > resolve.  Jini has the behavior that clients dynamically discover the "code"
> > that they will use.  OSGi has the attribute that clients load packages for the
> > "code" that they use.  In both cases, the deployment mechanism has established
> > the content that is "the code".  OSGi includes more literal dependency
> > specifications from each packages perspective.  Jini doesn't do it that way.
> > Instead, the "codebase" and "classpath" mechanisms are used to "tell" the
> > system that is built what to do.
> >
> > When you get into a more arbitrary environment like "the internet", then more
> > expressive and more detailed relationship descriptions between packages can
> > help make it possible for multiple packages to use multiple versions of the
> > same package.  The code in com.sun.jini.start provides the mechanism for
> > services to be separated from each other, but not from the system classpath.
> >
> > I think it would be a good idea to just detail the concerns first, and then
> > discuss where those concerns are visible or problematic so that we can work
> > through any other issues that might be stimulated forth, out of the discussion.
> >
> > Gregg
>
> My main concern here is usability, River presents a problem for new
> developers, by behaving in ways (because of the underlying java
> platform) that are non intuitive, brittle and unexpected.
>
> Eg: codebase annotation losses when remote objects are transferred
> around the network, or where multiple remote objects interact in the
> same jvm.
>
> If possible I'd like to make the default behaviour intuitive, without
> the need for a detailed understanding of class loaders, codebase
> annotation losses etc for the application developer, but without
> limiting advanced developers who have a detailed understanding.
>
> Jini concepts are simple and elegant, the implementation isn't, perhaps
> because we push the boundaries of the java platform itself.
>
> I'm starting to think that each remote service with a smart proxy
> deserves it's own separate namespace, due to class versioning issues.  I
> can't think of any way to fix the current issues using ClassLoaders
> alone and smarter minds have spent many hours contemplating the problem.
>
> We could use two jvm's, one for local code, one for remote downloaded code.
>
> Each remote proxy should have jsk-platform.jar and any libraries it
> needs in it's own classloader, in the remote process jvm.  So the remote
> process jvm has a flat hierarchy of ClassLoaders, each containing a
> smart proxy namespace.  A small management kernerl would manage it in
> the application classloader.
>
> The client interacts through these via reflective proxy's.  Smart
> proxy's in the remote process jvm can be passed reflective proxy's that
> refer to other smart proxy's in different ClassLoaders, if obtained from
> the client.  Then the codebase annotations can even contain and utilise
> different versions of River, excluding the policy provider of course,
> which will be controlled by the client.  Proxy verification would have
> to be performed in the remote process jvm.
>
> This relies on maintaining Serialized form compatibility between
> versions, since serialization alone would be used to transfer classes
> between the client and remote process jvm.
>
> Thoughts?
>
> Peter.
>
> > On 8/29/2011 5:32 AM, Peter Firmstone wrote:
> > >  On 29/08/2011 6:23 PM, Peter Firmstone wrote:
> > > > >  On 28 August 2011 09:18, Peter Firmstone<peter.firmstone@zeus.net.au>
> > > > > wrote:  >
> > > > >  >  Then we stop using the preferred classes mechanism by default.
> > > > >  >
> > > > >
> > > > >  Why?
> > > > >
> > > > >  >  This will allow us to prevent codebase annotation loss.
> > > > >  >
> > > > >
> > > > >  Because of annotation loss? That's quite a serious compromise and
> > > > >  prevents service implementers from doing version management of
code in
> > > > >  their proxies amongst other things. That's a killer as it requires
all
> > > > >  services to move with the platform all the time which implies forced
> > > > >  mass upgrades etc.
> > > >
> > > >  Hmm, ok, so these are implementation private copies / concerns, unless
> > > > they  share a common interface or superclass with the platform.
> > > >
> > > >  The other alternative exteme is to prefer all classes other than those
in
> > > > the  service api, meaning the proxy get's to have all it's own
> > > > implementation  classes, this would definitely prevent codebase annotation
> > > > loss.
> > > >
> > > >  So if that's the case, is it possible to automate the preferred list?
> > > >
> > > >  Now what happens if we extend an existing Service API and the extension
> > > >  classes are not installed on the client, the proxy must download them.
> > > >
> > > >  So how about for all codebase annotations ending in *api.jar, we consult
> > > > the  parent classloader first, followed by the proxy ClassLoader
> > > >  (PreferredClassLoader) and for all other codebases, we try the proxy
> > > >  Classloader first, then the parent classloader if not found, or perhaps
> > > > only  the proxy classloader then throw a ClassNotFoundException?
> > >
> > >  This would require some very carefull thought, feel free to mention any
> > > gotcha's  you can think of. Any java classes would also have to delegate up.
> > >
> > >  Perhaps this isn't quite the right approach, perhaps the right approach is
> > > to  create a tool that generates preferred class lists for developers, all
> > > comments  and thoughts are welcome.
> > >
> > >  Another problem is, if a client retains references to objects from a proxy,
> > > this  can prevent the proxy classloader from being garbage collected, even
> > > if the  client has finished with the proxy itself.
> > >
> > >  To me it appears that the client and proxy should only interract using the
> > >  service api or common interfaces and jvm classes. This would also be useful
> > > to  enable clients and proxy's to run is separate jvm's, where each has it's
> > > own  runtime zone? In this case the proxy could use one version of a class,
> > > while the  client uses another, provided that the serialized form is still
> > > compatible, you  don't have to suffer the ClassLoader visibility problems
> > > then.
> > >
> > >  Cheers,
> > >
> > >  Peter.
> > >
> > > >
> > > >  Then developers don't need to try figure out what classes are preferred,
> > > >  simplifying development.
> > > >
> > > >  This allows each proxy to have it's own private implementation namespace.
> > > >
> > > >  Thoughts?
> > > >
> > > >  Cheers,
> > > >
> > > >  Peter.
> > > >
> > > >
> > >
> > >
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message