I'm no expert on the build scripts, but in the trunk's build.xml, there appears to be a "preferredListGen" tool and ant task...
Cheers, Greg. On Mon, 2011-08-29 at 11:17, Gregg Wonderly wrote: > 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. > >> > >> > > > >
