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?
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.
