This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 11834 - RMI compilation uses wrong classpath
Summary: RMI compilation uses wrong classpath
Status: CLOSED INVALID
Alias: None
Product: obsolete
Classification: Unclassified
Component: rmi (show other bugs)
Version: 3.x
Hardware: PC Windows ME/2000
: P1 blocker (vote)
Assignee: issues@obsolete
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2001-04-30 01:36 UTC by Dave
Modified: 2003-07-01 14:26 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dave 2001-04-30 01:36:33 UTC
After marking a class as RMI within the UI compilation fails because the class 
doesn't exist in correct package.
Compiler reports StaffplannerKernel.com.staffplanner.server
Real package is com.staffplanner.server
The compiler is using the mounted filesystem in Netbeans not the link in the 
project (com_1).
JDK=1.3.0_01 OS=Win2k NB=3.2(38)
Comment 1 Martin Ryzl 2001-05-03 09:45:25 UTC
I'm afraid I need more information.

I assume that there is a directory structure similar to the following:

c:\StaffplannerKernel\com\staffplanner\server

and that c:\StaffplannerKernel is mounted in FileSystems and classes in the
c:\StaffplannerKernel\com\staffplanner\server have statements

package com.staffplanner.server;

in their sources. Is it right?
Comment 2 Dave 2001-05-03 18:27:10 UTC
Direcory structure is:
c:\java\staffplannerkernel\com\staffplanner\server
and c:\java is the mounted filesystem.
The com directory is linked into the project as com_1 and the classes under the 
server directory have the package com.staffplanner.server.
If I mount c:\java\StaffplannerKernel instead of c:\java then the compile works.
Comment 3 Martin Ryzl 2001-05-04 12:40:37 UTC
You should mount c:\java\StaffplannerKernel - all filesystems paths are used
as a classpath for compilation and according to the java specification, the 
package must correspond with the directory structure inside an item of 
classpath.
Comment 4 Dave 2001-05-06 12:52:53 UTC
This is an inconsistency between externel compilation and rmi compilation. My 
project compiles except for the rmi.
I would also like to point out that from what you have said, it is invalid to 
add a directory from a sub-level of a filesystem to the project.
Comment 5 Jan Chalupa 2001-05-06 14:42:42 UTC
Target milestone -> 3.3
Comment 6 Martin Ryzl 2001-05-07 09:59:29 UTC
There is no inconsistency.

You can use the following commandline for compilation:

java -classpath c:\java 
c:\java\staffplannerkernel\com\staffplanner\server\Server.java

there is no problem because Server.java source is compiled and the compiler
produces Server.class file in the same directory where the source is located. 
However, if the Server class implements (or use) an interface which is in the 
same package, the compilation fails because
the compiler is looking for com.staffplanner.server.ServerInterface in  
directory c:\java. Java packages are directly mapped onto the directory 
structure and file c:\java\com\staffplanner\server\ServerInterface.class doesn't
exist (but it may work if you use another target directory!!)

rmic compiler compiles classes (not sources) to stubs and skeletons, so it is 
more strict than the regular java compilation. The correct command line would 
be:

rmic -classpath c:\java\staffplannerkernel com.staffplanner.server.Server

but in your project the following is probably used:

rmic -classpath c:\java staffplannerkernel.com.staffplanner.server.Server

and rmic compares the classname which is part of the command line to
the fully qualified name obtained from the class file. Obviously, it results in 
compile error.
This behavior corresponds to the Java Specification.


In the current project concept, all items under the project tab are symbolic 
links to the filesystems, e.g. you can create whatever structure in the project 
tab.

You may discuss these issues at nbdev@netbeans.org or nbusers@netbeans.org,
Comment 7 Quality Engineering 2003-07-01 14:26:32 UTC
Resolved for 3.4.x or earlier, no new info since then -> closing.