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 as least one person had put the changes into place for his private code base so that he could now trivially integrate with a JavaEE container.
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. 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. Gregg Wonderly On Oct 26, 2012, at 7:58 AM, Simon IJskes - QCG <[email protected]> wrote: > On 26-10-12 01:07, Simon IJskes - QCG wrote: >> On 26-10-12 00:56, Greg Trasuk wrote: >>> >>> Isn't there already java.rmi.server.RMIClassLoaderSpi that >>> net.jini.loader.pref.PreferredClassProvider implements? What would a >>> River-specific provider interface add? >> >> RMIClassLoaderSpi is used for instance in java webstart (javafx) to >> initialize if with the default implementation. I see no way to > .............it >> circumvent this. I havent looked in detail to RIVER-336 [1] but it looks >> like it asked for a similar seperation possibility. Maybe other >> solutions can be made pluggable? >> >> [1] https://issues.apache.org/jira/browse/RIVER-336 >> > > Anybody? >
