1 Apr 02:21
Loading JAR files with large packages
Tom Price <Tom.Price <at> metaswitch.com>
2008-04-01 00:21:21 GMT
2008-04-01 00:21:21 GMT
Hi,
I'm trying to access some classes from Jython that are in a .jar file,
which works the first time the application is started, but I
consistently get the following error on the second and subsequent
executions:
ImportError: No module named settings
I looked in the .pkc file for this .jar, and indeed the "settings"
package is not listed there, but it *is* present in the .jar. I then
did some experimentation and found that the problem is when
CachedJarsPackageManager.java attempts to write the .pkc file (in
writeCacheFile), it gets an IOException as follows:
java.io.UTFDataFormatException: encoded string too long: 67064 bytes
at java.io.DataOutputStream.writeUTF(Unknown Source)
at java.io.DataOutputStream.writeUTF(Unknown Source)
at Test.writeCacheFile(Test.java:397)
(where Test.java is a copy of CachedJarsPackageManager.java modified to
experiment with this problem).
This is triggered by the fact that one of the packages in my .jar file
is very large (thousands of classes), so the string listing all the
classes in this package is too long for DataOutputStream to write in one
go. Has anyone come across this before, and is there any way to work
around it?
Thanks in advance for any suggestions.
(Continue reading)
but I tend to agree with you. Supposedly (I'm not
a developer) a lot of internals have been cleaned up for 2.5; you
should have a look at the latest code and then maybe bring the issue
up on jython-dev.
-David
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
> Yea, I guess I muddle through trying to get it to work with Jakarta
> httpclient.
If the Jython version of socket.ssl uses the default Java SSL
configuration (as I suspect it does -- it's the most likely
explanation for the "bug"), then the directions for disabling cert
checking (see the first link in my first message) will allow you to
use socket.ssl without worrying about certs.
-David
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
RSS Feed