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
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<[email protected]> 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.
