DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=34856>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=34856 ------- Additional Comments From [EMAIL PROTECTED] 2005-09-07 04:11 ------- > (In reply to comment #5) > Are you suggesting we change Jasper to only add files ending in .jar to the classpath? Yes. .jar and .zip (In reply to comment #6) > I bet adding only files ending in jar would break a lot of stuff. Why would it break stuff? Are class files ever found in a non-.zip/.jar file? The only situation I can think of is if someone has a zip file named a.foo, i.e. the file is a zip file, but the extension is not .zip. If you did have such a situation on Windows/Solaris/Linux, you would already have seen failures there (with 1.5). If the only platform we're concerned about is the Mac then I would say it's safe to add just .zip and .jar. Alternatively, you could go in the opposite direction and exclude all .jnilib/.dylib files (as a hack). That may work depending on what the user has lying the directory. More fundamentally, why do we explicitly add all the files found in /System/Library/Java/Extensions directory to the classpath? The JVM on MacOS will automatically pick up those jars so yet another option may be to just ignore that directory while creating the huge classpath. Thinking on these lines some more... it strikes me that /System/Library/Java/Extensions is part of the java.ext.dir system property. Any jar/zip file found in java.ext.dir will be automatically picked up by the VM during compilation/execution. What this means is that you can generalize your solution by not adding any of the files in the directories specified by java.ext.dir to the classpath. See <http://developer.apple.com/releasenotes/Java/Java131MOSX10.1RN/index.html#JavaExtensions> (old 1.3.1 release notes but I'm sure the text is still valid for 1.5) ---- Java extension locations Java can be extended by adding custom jar, zip, and class files, as well as native JNI libraries, in the location specified by the java.ext.dir property. In Mac OS X 10.0, this property pointed to /System/Library/Frameworks/JavaVM.framework/Versions/1.3/Home/lib/ext, and many third party applications placed their extensions there. There are two problems with this scheme: installing files in the System domain requires administrative privileges; and the extensions are tied to a specific version of the JDK. In Mac OS X 10.1, java.ext.dir has been changed to contain a list of directories, and several additional locations for saving extensions have been added. This new scheme makes it possible to override extensions, and provides distinct locations for third party extensions, Apple extensions, and Sun JDK extensions. By default, Java searches for extensions, in order, in the following directories: 1. Users home directory (~/Library/Java/Extensions/) 2. Local domain (/Library/Java/Extensions/) 3. Network domain (/Network/Library/Java/Extensions/) 4. System domain (/System/Library/Java/Extensions/) 5. $JAVA_HOME (/System/Library/Frameworks/JavaVM.framework/Versions/Current/Home/lib/ext/) In general, third party developers should install extensions in the Local domain. Apple extensions, such as QTJava.zip, are installed in the System domain, and Sun JDK extensions are installed in $JAVA_HOME. ----- > Is it possible to catch the exceptions thrown when opening broken files from the classpath and simply log > an error message? Not sure if it would work but it might be worth a shot. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
