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.
3.4 RC1 IBM JDK 1.3.1 Executing tomcat gives: java.util.zip.ZipException: The file or directory specified is read-only. at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.<init>(ZipFile.java:127) at java.util.jar.JarFile.<init>(JarFile.java:138) at java.util.jar.JarFile.<init>(JarFile.java:80) at org.apache.catalina.loader.StandardClassLoader.addRepositoryInternal(StandardClassLoader.java:1216) at org.apache.catalina.loader.StandardClassLoader.<init>(StandardClassLoader.java:200) at org.apache.catalina.startup.ClassLoaderFactory.createClassLoader(ClassLoaderFactory.java:202) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:138) Bootstrap: Class loader creation threw exception java.lang.IllegalArgumentException: addRepositoryInternal: java.util.zip.ZipException: The file or directory specified is read-only. at org.apache.catalina.loader.StandardClassLoader.addRepositoryInternal(StandardClassLoader.java:1246) at org.apache.catalina.loader.StandardClassLoader.<init>(StandardClassLoader.java:200) at org.apache.catalina.startup.ClassLoaderFactory.createClassLoader(ClassLoaderFactory.java:202) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:138)
Gili, can you find what is read-only? What were steps for reporducing this bug?
Radim, as far as I can tell no files are read-only. All I did to produce this result was try to execute a JSP file which triggered Tomcat starting up. Is there no way for us to ask Tomcat to let us know which file it is trying to access when it gets this error? Does Tomcat have additional debugging logs?
Ok... I've tracked down the problem (thank god for JAD!) org.apache.catalina.startup.BootStrap tells org.apache.catalina.startup.ClassLoaderFactory to process \netbeans\tomcat404\common\classes now, createClassLoader(File unpacked[], File packed[], ClassLoader parent) will push a list of the specified directory and all the files contained therein into an array. It will then call StandardClassLoader and its constructor will call addRepositoryInternal(String repository). Now, since \netbeans\tomcat404\common\classes is empty, the only element in the array will be "file:D:/netbeans/tomcat404/common/classes/". The bug here is that the Tomcat group assumes that if File(filename).toString().endsWith(File.separator) is false, then they're dealing with a file and they pass it on to ZipFile. Now, on IBM's JDK, when you run File("\netbeans\tomcat404\common\classes\").toString(), the ending slash will be stripped off. The Tomcat team should *not* rely on ending slash to determine if they're dealing with a directory or file; instead they should be using File.isDirectory() Fix that and I'm convinced Tomcat will run under IBM's JDK. Could you please pass this information on to their team? You probably know the exact revision of Tomcat being used in Netbeans. Changing OS from "OS/2" to "All".
NOTE: Updating to the latest (daily build) of bootstrap.jar fixes the problem and this works even though the rest of the JARs belong to an older version. Would you consider checking this in?
The bug will only be fixed by bundling a new version of Tomcat internal server. There is also a workaround to mount external Tomcat installation that solves that problem. I am going to change the resolution to LATER, because we can do nothing with this bug until new version of Tomcat (Tomcat4.1) will be bundled with Netbeans.
Issue based on 3.4 version, closing..