«

My RMI code has worked perfectly prior to Update 10.

The _Stub class, which is in my jar, could not be loaded by the
classloader, and it was not a security problem.

What has changed in RMI for update 10 ? I doubt I am the only one
with this problem.

OUT: 08.11.02 01:18:23.874: RemoteIndicatorServiceImpl object created.
ERR: 08.11.02 01:18:23.907: java.rmi.ServerException: RemoteException
occurred in server thread; nested exception is:
java.rmi.UnmarshalException: error unmarshalling arguments; nested
exception is:
java.lang.ClassNotFoundException:
com.twc.remote.RemoteIndicatorServiceImpl_Stub
java.rmi.ServerException: RemoteException occurred in server thread;
nested exception is:
java.rmi.UnmarshalException: error unmarshalling arguments; nested
exception is:
java.lang.ClassNotFoundException:
com.twc.remote.RemoteIndicatorServiceImpl_Stub
at sun.rmi.server.UnicastServerRef.oldDispatch(Unknow n Source)
at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
at sun.rmi.transport.Transport$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport.handleMessages( Unknown Source)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandl er.run0(Unknown
Source)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandl er.run(Unknown
Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run Task(Unknown
Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run (Unknown Source)
at java.lang.Thread.run(Unknown Source)
at
sun.rmi.transport.StreamRemoteCall.exceptionReceiv edFromServer(Unknown
Source)
at sun.rmi.transport.StreamRemoteCall.executeCall(Unk nown Source)
at sun.rmi.server.UnicastRef.invoke(Unknown Source)
at sun.rmi.registry.RegistryImpl_Stub.rebind(Unknown Source)
at java.rmi.Naming.rebind(Unknown Source)
at com.twc.trader.ZoneTrader.<init>(Unknown Source)
at com.twc.trader.ZoneTrader.createAndShowGUI(Unknown Source)
at com.twc.trader.ZoneTrader.access$3(Unknown Source)
at com.twc.trader.ZoneTrader$95.run(Unknown Source)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilter s(Unknown
Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(U nknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarch y(Unknown
Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
Caused by: java.rmi.UnmarshalException: error unmarshalling arguments;
nested exception is:
java.lang.ClassNotFoundException:
com.twc.remote.RemoteIndicatorServiceImpl_Stub
at sun.rmi.registry.RegistryImpl_Skel.dispatch(Unknow n Source)
at sun.rmi.server.UnicastServerRef.oldDispatch(Unknow n Source)
at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
at sun.rmi.transport.Transport$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport.handleMessages( Unknown Source)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandl er.run0(Unknown
Source)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandl er.run(Unknown
Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run Task(Unknown
Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run (Unknown Source)
at java.lang.Thread.run(Unknown Source)

*** The class not found is clearly in the jar ***
Caused by: java.lang.ClassNotFoundException:
com.twc.remote.RemoteIndicatorServiceImpl_Stub
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at sun.rmi.server.LoaderHandler.loadClass(Unknown Source)
at sun.rmi.server.LoaderHandler.loadClass(Unknown Source)
at java.rmi.server.RMIClassLoader$2.loadClass(Unknown Source)
at java.rmi.server.RMIClassLoader.loadClass(Unknown Source)
at sun.rmi.server.MarshalInputStream.resolveClass(Unk nown Source)
at java.io.ObjectInputStream.readNonProxyDesc(Unknown Source)
at java.io.ObjectInputStream.readClassDesc(Unknown Source)
at java.io.ObjectInputStream.readOrdinaryObject(Unkno wn Source)
at java.io.ObjectInputStream.readObject0(Unknown Source)
at java.io.ObjectInputStream.readObject(Unknown Source)
... 12 more

OUT: 08.11.02 01:18:23.907: RemoteIndicatorServiceImpl Naming.rebind
FAILURE.

FutureScalper wrote:
> My RMI code has worked perfectly prior to Update 10.
>
> The _Stub class, which is in my jar, could not be loaded by the
> classloader, and it was not a security problem.
>
> What has changed in RMI for update 10 ? I doubt I am the only one
> with this problem.

Could you post code and directory structure to recreate the problem ?

Arne

No, code is way too complex. In a nutshell, this is a standalone
Java application which permits a portion of the code to be accessed
externally as an RMI server. Thus, two instances of my executable
can "talk" to each other via RMI. Pretty straight forward, really;
and has been working for years.

I would have expected perhaps some Security problem preventing
the classloading, but that is not the case. The classes are, and
have always been in the jar on the classpath.

Previously, I instantiated the Impl and, in the constructor
simply called Naming.rebind("servicename", this). I've separated
this out to make it much cleaner, and made SURE that all RMI handles
are STATIC variables so they do not disappear prior/during the binding
process, etc.

I spent hours trying to get it to work on Update 10, trying everything
in the book, so to speak, and I just have to get my users to roll back
uninstall Java 6 Update 10 until / unless I can figure it out.

On Nov 2, 1:49*pm, Arne Vajhøj <a...@vajhoej.dk> wrote:
> FutureScalper wrote:
> > My RMI code has worked perfectly prior to Update 10.
>
> > The _Stub class, which is in my jar, could not be loaded by the
> > classloader, and it was not a security problem.
>
> > What has changed in RMI for update 10 ? *I doubt I am the only one
> > with this problem.
>
> Could you post code and directory structure to recreate the problem ?
>
> Arne

FutureScalper wrote:
> No, code is way too complex. In a nutshell, this is a standalone

Please do not top-post. Without some clue of your code it is awfully hard to
diagnose what you're seeing.

> Java application which permits a portion of the code to be accessed
> externally as an RMI server. Thus, two instances of my executable
> can "talk" to each other via RMI. Pretty straight forward, really;
> and has been working for years.

Are you absolutely sure you cannot construct a short, self-contained
compilable example (SSCCE) of an RMI call that demonstrates your problem?
<http://sscce.org/>

> Previously, I instantiated the Impl and, in the constructor
> simply called Naming.rebind("servicename", this). I've separated
> this out to make it much cleaner, and made SURE that all RMI handles
> are STATIC variables so they do not disappear prior/during the binding
> process, etc.

Static variables are an antipattern.

FutureScalper wrote:
>>> My RMI code has worked perfectly prior to Update 10.
>>> The _Stub class, which is in my jar, could not be loaded by the
>>> classloader, and it was not a security problem.
>>> What has changed in RMI for update 10 ? I doubt I am the only one
>>> with this problem.

Is this relevant?
<http://java.sun.com/javase/6/docs/technotes/guides/rmi/relnotes.html>
> Dynamic Generation of Stub Classes (since 5.0)
> This release adds support for the dynamic generation of stub classes at
> runtime, obviating the need to use the Java Remote Method Invocation (Java
> RMI) stub compiler, rmic, to pregenerate stub classes for remote objects. Note
> that rmic must still be used to pregenerate stub classes for remote objects
> that need to support clients running on earlier versions.

I reviewed
<http://java.sun.com/javase/6/docs/technotes/guides/rmi/index.html>
but didn't find anything that seems to help.

It would help to have an SSCCE.

--
Lew

I spawn rmiregistry.exe on Windows as a separate process, and each
of my instances registers a unique name for its services. All
access is localhost, for purposes of this discussion.

Again, the primary exception is class not found exception, so
if this is a bug, it affects class loading of the _Stub class
I'd say.

I guess I can construct some sort of test case. But doesn't
the exception give enough information? Why would the _Stub
class loading be the issue? It's in the jar.

OK, it's a signed jar, and OK, it's run by Java Web Start; there
are quite a few variables here, but it's a straightforward usage
of RMI which has worked forever without any issues until Update
10 came along.

On Nov 2, 2:42*pm, Lew <no...@lewscanon.com> wrote:
> FutureScalper wrote:
> > No, code is way too complex. *In a nutshell, this is a standalone
>
> Please do not top-post. *Without some clue of your code it is awfully hard to
> diagnose what you're seeing.
>
> > Java application which permits a portion of the code to be accessed
> > externally as an RMI server. *Thus, two instances of my executable
> > can "talk" to each other via RMI. *Pretty straight forward, really;
> > and has been working for years.
>
> Are you absolutely sure you cannot construct a short, self-contained
> compilable example (SSCCE) of an RMI call that demonstrates your problem?
> <http://sscce.org/>
>
> > Previously, I instantiated the Impl and, in the constructor
> > simply called Naming.rebind("servicename", this). *I've separated
> > this out to make it much cleaner, and made SURE that all RMI handles
> > are STATIC variables so they do not disappear prior/during the binding
> > process, etc.
>
> Static variables are an antipattern.
>
> FutureScalper wrote:
> >>> My RMI code has worked perfectly prior to Update 10.
> >>> The _Stub class, which is in my jar, could not be loaded by the
> >>> classloader, and it was not a security problem.
> >>> What has changed in RMI for update 10 ? *I doubt I am the only one
> >>> with this problem.
>
> Is this relevant?
> <http://java.sun.com/javase/6/docs/technotes/guides/rmi/relnotes.html>
>
> > Dynamic Generation of Stub Classes (since 5.0)
> > This release adds support for the dynamic generation of stub classes at
> > runtime, obviating the need to use the Java Remote Method Invocation (Java
> > RMI) stub compiler, rmic, to pregenerate stub classes for remote objects. Note
> > that rmic must still be used to pregenerate stub classes for remote objects
> > that need to support clients running on earlier versions.
>
> I reviewed
> <http://java.sun.com/javase/6/docs/technotes/guides/rmi/index.html>
> but didn't find anything that seems to help.
>
> It would help to have an SSCCE.
>
> --
> Lew

No, I am not trying to use an inprocess rmi registry. The
rmiregistry.exe process is running in a separate process so
that isn't the issue.

On Nov 2, 2:42*pm, Lew <no...@lewscanon.com> wrote:
> FutureScalper wrote:
> > No, code is way too complex. *In a nutshell, this is a standalone
>
> Please do not top-post. *Without some clue of your code it is awfully hard to
> diagnose what you're seeing.
>
> > Java application which permits a portion of the code to be accessed
> > externally as an RMI server. *Thus, two instances of my executable
> > can "talk" to each other via RMI. *Pretty straight forward, really;
> > and has been working for years.
>
> Are you absolutely sure you cannot construct a short, self-contained
> compilable example (SSCCE) of an RMI call that demonstrates your problem?
> <http://sscce.org/>
>
> > Previously, I instantiated the Impl and, in the constructor
> > simply called Naming.rebind("servicename", this). *I've separated
> > this out to make it much cleaner, and made SURE that all RMI handles
> > are STATIC variables so they do not disappear prior/during the binding
> > process, etc.
>
> Static variables are an antipattern.
>
> FutureScalper wrote:
> >>> My RMI code has worked perfectly prior to Update 10.
> >>> The _Stub class, which is in my jar, could not be loaded by the
> >>> classloader, and it was not a security problem.
> >>> What has changed in RMI for update 10 ? *I doubt I am the only one
> >>> with this problem.
>
> Is this relevant?
> <http://java.sun.com/javase/6/docs/technotes/guides/rmi/relnotes.html>
>
> > Dynamic Generation of Stub Classes (since 5.0)
> > This release adds support for the dynamic generation of stub classes at
> > runtime, obviating the need to use the Java Remote Method Invocation (Java
> > RMI) stub compiler, rmic, to pregenerate stub classes for remote objects. Note
> > that rmic must still be used to pregenerate stub classes for remote objects
> > that need to support clients running on earlier versions.
>
> I reviewed
> <http://java.sun.com/javase/6/docs/technotes/guides/rmi/index.html>
> but didn't find anything that seems to help.
>
> It would help to have an SSCCE.
>
> --
> Lew

I generate the jar using this rmic approach; and am not relying
upon the new "stubless" approach

rem compiling and adding skel and stub to ZoneTrader.jar
rmic -v1.2 -keep -classpath ../bin -d ./bin
com.twc.remote.RemoteIndicatorServiceImpl
jar -uf FutureScalper.jar -C ./bin com/twc/remote/
RemoteIndicatorServiceImpl_Stub.class
rem Stub added to FutureScalper.jar


On Nov 2, 2:55*pm, FutureScalper <futurescal...@gmail.com> wrote:
> No, I am not trying to use an inprocess rmi registry. *The
> rmiregistry.exe process is running in a separate process so
> that isn't the issue.
>
> On Nov 2, 2:42*pm, Lew <no...@lewscanon.com> wrote:
>
> > FutureScalper wrote:
> > > No, code is way too complex. *In a nutshell, this is a standalone
>
> > Please do not top-post. *Without some clue of your code it is awfully hard to
> > diagnose what you're seeing.
>
> > > Java application which permits a portion of the code to be accessed
> > > externally as an RMI server. *Thus, two instances of my executable
> > > can "talk" to each other via RMI. *Pretty straight forward, really;
> > > and has been working for years.
>
> > Are you absolutely sure you cannot construct a short, self-contained
> > compilable example (SSCCE) of an RMI call that demonstrates your problem?
> > <http://sscce.org/>
>
> > > Previously, I instantiated the Impl and, in the constructor
> > > simply called Naming.rebind("servicename", this). *I've separated
> > > this out to make it much cleaner, and made SURE that all RMI handles
> > > are STATIC variables so they do not disappear prior/during the binding
> > > process, etc.
>
> > Static variables are an antipattern.
>
> > FutureScalper wrote:
> > >>> My RMI code has worked perfectly prior to Update 10.
> > >>> The _Stub class, which is in my jar, could not be loaded by the
> > >>> classloader, and it was not a security problem.
> > >>> What has changed in RMI for update 10 ? *I doubt I am the only one
> > >>> with this problem.
>
> > Is this relevant?
> > <http://java.sun.com/javase/6/docs/technotes/guides/rmi/relnotes.html>
>
> > > Dynamic Generation of Stub Classes (since 5.0)
> > > This release adds support for the dynamic generation of stub classes at
> > > runtime, obviating the need to use the Java Remote Method Invocation (Java
> > > RMI) stub compiler, rmic, to pregenerate stub classes for remote objects. Note
> > > that rmic must still be used to pregenerate stub classes for remote objects
> > > that need to support clients running on earlier versions.
>
> > I reviewed
> > <http://java.sun.com/javase/6/docs/technotes/guides/rmi/index.html>
> > but didn't find anything that seems to help.
>
> > It would help to have an SSCCE.
>
> > --
> > Lew

Please do not top-post.

FutureScalper wrote:
> I generate the jar using this rmic approach; and am not relying
> upon the new "stubless" approach

What would happen if you did try the stub-free approach?

We really need an SSCCE.

--
Lew

FutureScalper wrote:
> On Nov 2, 1:49 pm, Arne Vajhøj <a...@vajhoej.dk> wrote:
>> FutureScalper wrote:
>>> My RMI code has worked perfectly prior to Update 10.
>>> The _Stub class, which is in my jar, could not be loaded by the
>>> classloader, and it was not a security problem.
>>> What has changed in RMI for update 10 ? I doubt I am the only one
>>> with this problem.
>> Could you post code and directory structure to recreate the problem ?
> No, code is way too complex.

In that case nobody can
* confirm whether it is a bug
* identify under what circumstances it materializes
* check whether it already is known
* make an official bug report with SUN

Arne

On Nov 2, 3:17*pm, Lew <no...@lewscanon.com> wrote:
> Please do not top-post.
>
> FutureScalper wrote:
> > I generate the jar using this rmic approach; and am not relying
> > upon the new "stubless" approach
>
> What would happen if you did try the stub-free approach?
>
> We really need an SSCCE.
>
> --
> Lew

OK, thanks. Over the next few weeks I'll get around
to figuring it out and will post what I find.