The problem with RMIClassLoaderSPI is that you can't replace it's implementation except through the use of command line property values. This is not a workable solution for many different reasons in many different environments. So, just putting in CodebaseAccessClassLoader as it sits, should be trivial to do, and it doesn't break anything with the defaults.
I wonder if Peter pulled it out when some of the other stuff he was pushing into the build created some problems late last year? Humm, it should be in there. Gregg Wonderly On Oct 26, 2012, at 12:18 PM, Simon IJskes - QCG <[email protected]> wrote: > On 26-10-12 17:41, Gregg Wonderly wrote: >> I believe the patches shown there have been put in place now have >> they not? Peter was working on this a while back, and I thought that > > I'm not sure. Could you check? I've in the mean time implemented the Spi, and > it works for me. I was bitten by the exact problem described in the comments > in the ticket. > >> What I did was all that was strictly necessary to make it possible to >> replace the use of RMIClassLoaderSPI with similar behavior, but that >> behavior could be plugged in at runtime, with appropriate >> permissions. Since I just patched over the present logic, it doesn't >> change how things work, just where the software that processes the >> "events" can come from. > > I cannot find 'CodebaseAccessClassLoader' in the code. > >> It can also allow the "annotation" to change use/behavior on JVMs >> which share a common behavior plugged in with this facility. This >> implies that things as "elegant" as Maven, could actually be used for >> codebase resolution. > > Hum. Yes. Eveything is possible! :) In the mean time i've coded a Spi, with a > default implementation to RMIClassLoader, but not with the SystemClassLoader, > but the classloader of the Spi found. > > Gr. Simon
