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.
