tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 34856] - MacOSX 10.4 and Java 5 jnilibs causes ZipException when Tomcat loads non-jars
Date Wed, 07 Sep 2005 02:11:29 GMT
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 pratik.solanki.ml@gmail.com  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. Userís 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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message