On 24 June 2012 06:50, Peter Firmstone <j...@zeus.net.au> wrote: > One of my first tasks as a River developer was to rewrite ClassDep, > previously it was based on a jvm tools library, now it uses ASM. > > What became painfully obvious at the time: IT IS NOT POSSIBLE to determine > all runtime dependencies at compile time. > > However this could be sufficient for most developers, even if it's not > preferred, a class found during runtime may be not be available at the > client and could still be loaded from the proxy jar, it just means the > parent class loader will be tried first. > > So the preferred list automatically generated would not necessarily be > comprehensive, but in most cases adequate, this seems less confusing than > writing a new class loader with different behaviour. > > Can anyone see any issues with this? > > No. The only problems we've ever had with this are that we do the most flexible option as a default which puts load on the developer. So we're picking a different default which, so long as we document it, and explain what to do if that default is no good for you (and I reckon it will be for most), we're done.
Peter. > > > > Peter Firmstone wrote: > >> Well spotted, I spoke to Peter Kriens over the phone about this in 2010 >> (very smart guy btw), ClassDep doesn't detect Class.forName dependencies. >> >> A string might not be defined until runtime, so it's not something that >> can be easily determined. This could become even more difficult if dynamic >> languages like Groovy are used in the proxy. >> >> Another alternative might be to prefer everything resolvable by the proxy >> codebase string annotation at runtime. It would be up to the developer to >> ensure that proxy classses are packaged correctly, annotations could go >> some way to automating this for the developer. The developer could include >> any library jars required in their codebase string. >> >> Perhaps a classloader called ProxyPreferredClassLoader might be created >> for such a purpose. >> >> @ServiceAPI - dependency tree excluded from proxy codebase. >> @SmartProxy - root class for dependency search, to determine classes to >> be included in proxy jar file. >> >> Consideration has to be given to felixibility for developers using Maven, >> OSGi and dynamic languages. >> >> Peter. >> >> >> Could work for anything other than cases where someone makes liberal use >>> of >>> dynamic class loading via Class.forName and similar. So let's say I have >>> a >>> smart proxy that has some dynamically assembled bits, the references will >>> be in String form making bytecode analysis difficult. >>> >>> I wouldn't say this is likely a common case, more something that would >>> have >>> to be noted as a limitation of the tool so developers are not caught out. >>> >> >> >> >> >
