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 25249

Summary: ClassElement.forName() not up to date.
Product: java Reporter: _ gfink <gfink>
Component: UnsupportedAssignee: Svata Dedic <sdedic>
Status: CLOSED WONTFIX    
Severity: blocker CC: ttran
Priority: P2    
Version: 3.x   
Hardware: Sun   
OS: Solaris   
Issue Type: DEFECT Exception Reporter:
Attachments: Java file to replicate the bug.
jar file that serves as input to the program.

Description _ gfink 2002-06-27 22:44:35 UTC
In Forte EE, I've got a module that extracts
a jar file with class files and mounts it, then
proceeds to do more activity that assumes that
all the classes in the mounted directory structure
are available through ClassElement.  However, 
sometimes a long delay is necessary before the
ClassElement call returns productively.

I'll attach sample code that demonstrates the 
bug.
Comment 1 _ gfink 2002-06-27 22:47:59 UTC
Created attachment 6476 [details]
Java file to replicate the bug.
Comment 2 _ gfink 2002-06-27 22:49:31 UTC
Created attachment 6477 [details]
jar file that serves as input to the program.
Comment 3 Svata Dedic 2002-07-08 15:09:06 UTC
Cannot reproduce in trunk builds (Solaris 5.8). All classes were found
on the first try. Strange enough, I cannot reproduce it even with
3.3.2 NetBeans build.
Note: I uncommented the line with "mountFolder(target);" in the testcase.
Comment 4 _ gfink 2002-07-08 18:46:49 UTC
OK, I can see that it works the first time through.

Second time, delete the com/ directory, comment out the mountFolder
and re-run.

(You can also see this by running importear on petstore.ear in FFJ4.0
Comment 5 Svata Dedic 2002-07-09 12:14:31 UTC
You are extracting files onto filesystem (1), and trying to observe
them on filesystem (2) [that is what is happending when you use
ClassElement.forName -- it searches mounted filesystems for matching
package/classname]. For fs(2), changes made through fs(1) appear just
like they were made outside the IDE, or using java.io.File APIs - so
the fs(2) contents are refreshed periodically and files appear only
after the refresh.
I can see some solutions: either extract the files right onto the
mounted filesystem, or explicitly refresh all folders on fs (2) after
extraction to ensure that fs(2) notices what had happened "on fs(1)".
Or you can use some delegating filesystem implementation, like treefs
as fs(2) implementation instead of plain LFS, so it will refire events
from fs(1) and will maintain consistency. See treefs module in NB's
CVS for more details.
Comment 6 _ gfink 2002-07-09 22:07:40 UTC
The workaround to mount before extracting is good enough, thanks.
Comment 7 Quality Engineering 2007-09-20 10:25:22 UTC
Reorganization of java component