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.
This bug was originally marked as duplicate of bug 193086, that is already resolved. This bug is still valid, so this seems to be another bug, but it might be related. Build: NetBeans IDE 7.1.2 (Build 201204101705) VM: Java HotSpot(TM) Client VM, 1.6.0-b105, Java(TM) SE Runtime Environment, 1.6.0-b105 OS: Windows XP User Comments: GUEST: jjj GUEST: IllegalArgumentException: Invalid ClassPath Stacktrace: java.lang.IllegalArgumentException: Invalid ClassPath root: file:/E:/BaoCao/DucPhong/CuoiKy/build/web/WEB-INF/classes/. The root must be a folder.(exists: true file: false directory: true read: true write: true root: null _root: E:\BaoCao\DucPhong\CuoiKy\build\web\WEB-INF\classes@bb892a35:10f9da5) at org.netbeans.api.java.classpath.ClassPath$Entry.getRoot(ClassPath.java:806) at org.netbeans.api.java.classpath.ClassPath.createRoots(ClassPath.java:284) at org.netbeans.api.java.classpath.ClassPath.getRoots(ClassPath.java:268) at org.netbeans.modules.web.jspparser_ext.WebAppParseSupport.createClassLoaders(WebAppParseSupport.java:324) at org.netbeans.modules.web.jspparser_ext.WebAppParseSupport.initOptions(WebAppParseSupport.java:285) at org.netbeans.modules.web.jspparser_ext.WebAppParseSupport.reinitOptions(WebAppParseSupport.java:262)
Created attachment 132373 [details] stacktrace
I got the same error while generating RESTservice code. http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/RESTfulWebServices_Part2/RESTfulWebservicesPart2.htm#t3 Invalid ClassPath root: file:/C:/SoftwareAG/CentraSite/redist/log4j.xml/. The root must be a folder.(exists: true file: true directory: false read: true write: true root: null _root: C:\SoftwareAG\CentraSite\redist\log4j.xml@2388fc45:562f631f)
I'll take a look.
It looks that symptoms stay the same as in the issue #193086, the original fix probably doesn't work well. Another thing which crossed my mind is whether the state by getting roots isn't correct. I took a look into the message.log - it looks that the parent folder of the one for which it looks for CP root was likely deleted (since FileNotFoundException). I'm probably missing something but isn't that correct state that the CP root can't be found since it's parent was already deleted? the #getRoot() would return just the null under this circumstances. Tomasi, I suppose that I miss some facts so feel free to reassign to filesystems again or back to JSP if you will see any solution at our side. Thanks a lot.
The point with CP.E.getRoot() is right. However this exception is thrown in case when FileSystem view does not reflect the real OS file system. In case in which the "classes" folder does not exist it simply returns null and CP.getRoots() just do not contain the root. But the exception claims: file:/E:/BaoCao/DucPhong/CuoiKy/build/web/WEB-INF/classes/. The root must be a folder.(exists: true file: false directory: true read: true write: true root: null _root: E:\BaoCao\DucPhong\CuoiKy\build\web\WEB-INF\classes@bb892a35:10f9da5) meaning that the "classes" folder in fact exists on disk, it's a directory and is both readable and writable. So there is inconsistency among java.io.File and FileObject claiming that the "classes" is a data. The CP.E.getRoot() even does one dirty hack to help FS (in fact we were forced by Jarda to do it). If we find the inconsistence we do not throw the exception, we first try to refresh the root, take the parent, take parents children and refresh the parent. Then we retry if it fails even the second time we throw the ISE.
(In reply to comment #5) Ah, understand. Thanks a lot for the explanation.
I haven't been able to reproduce the problem, but I managed to prepare a test case that seems to cover the reported bug. AbstractFileObject caches the information about object type - folder or regular file. Unfortunately, if backing file is deleted, and then isFolder() method is called, an invalid value is cached (java.io.File.isDirectory() returns false for nonexistent files). So after re-creation of the folder, the invalid value cached for the AbstractFileObject is still used. Even the refresh cannot help. Fixed in http://hg.netbeans.org/core-main/rev/96e8facb01c5. Thank you for reporting, and for the helpful comments.
Integrated into 'main-golden', will be available in build *201306262301* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/96e8facb01c5 User: Jaroslav Havlin <jhavlin@netbeans.org> Log: #227200: IllegalArgumentException: Invalid ClassPath root. The root must be a folder.