The simplest tool, I believe, would be a jar traversal that looked for "classes
implementing interfaces" or "classes subclassing classes", and then pieced
together the tree of dependencies. If you provided multiple jar files, it would
then be able to look through the list of jars for overridden classes and output
those class names.
Something like the following that specifies the classpath you expect to be
active and the codebase you expect to download.
./preferredCheck \
-codebase myservice-dl.jar:somelibv2.jar:someotherlib.jar:jsk-dl.jar \
-classpath jsk-platform.jar:jsk-lib.jar:myservice.jar:somelibv1.jar
Note that I said I would be downloading somelibv2.jar as an example of a "bug
fix" for somelibv1.jar.
The output would then be all class names in somelibv2.jar that were already in
the specified classpath, plus anything else duplicated in the other -codebase jars.
Just thinking out loud...
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.
