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?

Thanks (again) go to Gregg for helping dig me out of this hole.

Tom


-----Original Message-----
From: Gregg Wonderly [mailto:[email protected]] 
Sent: 09 October 2009 15:05
To: [email protected]
Subject: Re: Finding Service Registrars on Linux

Tom Hobbs wrote:
> The plot thickens.
> 
...

> Exception in thread "main" java.lang.IllegalAccessError: class
> com.sun.jini.reggie.RegistrarImpl_Stub cannot access its
superinterface
> com.sun.jini.reggie.Registrar

Stubs are being used, so that implies to me, that the JDK version is an
issue.

>       at java.lang.ClassLoader.defineClass1(Native Method)
>       at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
>       at
>
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
>       at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
>       at java.net.URLClassLoader.access$000(URLClassLoader.java:56)
>       at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
>       at java.security.AccessController.doPrivileged(Native Method)
>       at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
>       at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
>       at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
>       at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
>       at java.lang.Class.forName0(Native Method)
>       at java.lang.Class.forName(Class.java:247)
>       at
> sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:434)
>       at
> sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165)

I don't think you have jsk-resources.jar in your system classloader
classpath, 
and/or you don't have

-Djava.rmi.server.RMIClassLoaderSpi=net.jini.loader.pref.PreferredClassP
rovider

in the environment so that right here, RMIClassLoader would be invoking 
net.jini.loader.ClassLoading.loadClass() as it should be.

>       at
> java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:620)
>       at
> java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:247)
>       at
>
sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:1
> 97)

This is what I can see in this stack trace.  Peter Jones might be able
to 
provide more inside into why the _Stub is referenced.

Gregg Wonderly

www.sucdenfinancial.com

Sucden Financial Limited, Plantation Place South, 60 Great Tower Street, London 
EC3R 5AZ
Telephone +44 203 207 5000

Registered in England no. 1095841
VAT registration no. GB 446 9061 33

Authorised and Regulated by the Financial Services Authority (FSA) and entered 
in the FSA register under no. 114239

This email, including any files transmitted with it, is confidential and may be 
privileged. It may be read, copied and used only by the intended recipient. If 
you are not the intended recipient of this message, please notify 
[email protected] immediately and delete it from your computer system.

We believe, but do not warrant, that this email and its attachments are 
virus-free, but you should check.

Sucden Financial Limited may monitor traffic data of both business and personal 
emails. By replying to this email, you consent to Sucden Financial 's 
monitoring the content of any emails you send to or receive from Sucden 
Financial . Sucden Financial is not liable for any opinions expressed by the 
sender where this is a non-business email.

The contents of this e-mail do not constitute advice and should not be regarded 
as a recommendation to buy, sell or otherwise deal with any particular 
investment.

This message has been scanned for viruses by Mimecast.

Reply via email to