At this point, most people should have moved from jini-core and jini-ext to
jsk-platform.jar and jsk-resources.jar. Clients need to have jsk-lib.jar in
their classpath, and codebases need to have jsk-dl.jar to make sure everything
that shouldn't be preferred is in the codebase as well. I'm working on putting
together some modules for netbeans, and my RCP version of the modules still have
some issues with how netbeans manages class loading.
Tom Hobbs wrote:
Oh course, yes, you're right.
I removed reggie.jar from the CP in Eclipse and added the following as
an environment variable.
-Djava.rmi.server.RMIClassLoaderSpi=net.jini.loader.pref.PreferredClassP
rovider
Eclipse is now happy and runs fine. Hurrah! So, thinking I (actually,
Gregg) have discovered some problem with my NetBeans projects which has
been masked by having a really heavy classpath; I create a new one.
Want more confusion?
Removing all the Jini JARs apart from jini-core.jar, jini-ext.jar and
sun-util.jar from the classpath I execute the same code again. This
time expecting it to fail since this new NetBeans project doesn't have
the PreferredClassProvider env variable set.
But it still works in NetBeans. Is there some fundamental RMI
doo-hickey thing that's different between the two IDEs? Or am I missing
something so obvious that everyone thinks I've checked it already?
What happens is that nearly everything is getting loaded from those jars,
instead of from the codebase, because the SPI is not in place and RMIClassLoader
goes ahead and just loads stuff fine to define the reggie proxy. Try using a
service that lookup returns and I think you'll get a failure, or is that what
you say is working?
So far, I am having problems with the context class loader being managed
correctly.
Thanks (again) go to Gregg for helping dig me out of this hole.
I'm getting lucky!
Gregg Wonderly
