Bug when running on Mac OS-X

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug when running on Mac OS-X

Siarhei-2
Hi All,

I'm trying to run orbeon (3.7.1)  on OS-X (10.5.7, jre 1.5.0_19-b02-304) and running into exception during ajax requests:

2009-07-06 15:28:34,090 ERROR [org.orbeon.oxf.webapp.ProcessorService] Exception at file:/var/folders/gL/gLHmVGbAFdSBQbeQakQSnU+++TM/-Tmp-/upload_285b603d_1
224f5e06e1__7f32_00000011.tmp
java.io.FileNotFoundException: /var/folders/gL/gLHmVGbAFdSBQbeQakQSnU   TM/-Tmp-/upload_285b603d_1224f5e06e1__7f32_00000011.tmp
        at org.jboss.net.protocol.file.FileURLConnection.connect(FileURLConnection.java:94)
        at org.orbeon.oxf.util.NetUtils.openConnection(NetUtils.java:1413)
        at org.orbeon.oxf.util.NetUtils.openConnection(NetUtils.java:1094)
        at org.orbeon.oxf.processor.generator.URLGenerator$URLResourceHandler.openConnection(URLGenerator.java:794)
        at org.orbeon.oxf.processor.generator.URLGenerator$URLResourceHandler.readXML(URLGenerator.java:831)
        at org.orbeon.oxf.processor.generator.URLGenerator$1.readImpl(URLGenerator.java:448)
        at org.orbeon.oxf.processor.ProcessorImpl$6.read(ProcessorImpl.java:995)
        at org.orbeon.oxf.processor.ProcessorImpl$ProcessorOutputImpl$ConcreteProcessorFilter$ForwarderProcessorOutput.read(ProcessorImpl.java:949)
        at org.orbeon.oxf.processor.ProcessorImpl.readInputAsSAX(ProcessorImpl.java:350)
        at org.orbeon.oxf.processor.validation.MSVValidationProcessor.access$700(MSVValidationProcessor.java:44)
        at org.orbeon.oxf.processor.validation.MSVValidationProcessor$5.readImpl(MSVValidationProcessor.java:219)
        at org.orbeon.oxf.processor.ProcessorImpl$6.read(ProcessorImpl.java:995)
        at org.orbeon.oxf.processor.ProcessorImpl$ProcessorOutputImpl.read(ProcessorImpl.java:1178)
        at org.orbeon.oxf.processor.ProcessorImpl$ProcessorOutputImpl$ConcreteProcessorFilter.read(ProcessorImpl.java:973)
        at org.orbeon.oxf.processor.ProcessorImpl$ProcessorOutputImpl.read(ProcessorImpl.java:1178)
        at org.orbeon.oxf.processor.ProcessorImpl.readInputAsSAX(ProcessorImpl.java:350)
        at org.orbeon.oxf.processor.ProcessorImpl.readInputAsDOM4J(ProcessorImpl.java:368)
        at org.orbeon.oxf.processor.ProcessorImpl.readInputAsDOM4J(ProcessorImpl.java:387)
        at org.orbeon.oxf.xforms.processor.XFormsServer.doIt(XFormsServer.java:104)
        at org.orbeon.oxf.xforms.processor.XFormsServer.access$000(XFormsServer.java:57)
        at org.orbeon.oxf.xforms.processor.XFormsServer$1.readImpl(XFormsServer.java:83)
        at org.orbeon.oxf.processor.ProcessorImpl$6.read(ProcessorImpl.java:995)
        at org.orbeon.oxf.processor.ProcessorImpl$ProcessorOutputImpl.read(ProcessorImpl.java:1178)
        at org.orbeon.oxf.processor.ProcessorImpl.readInputAsSAX(ProcessorImpl.java:350)
        at org.orbeon.oxf.processor.pipeline.TeeProcessor.access$000(TeeProcessor.java:36)
        at org.orbeon.oxf.processor.pipeline.TeeProcessor$1.readImpl(TeeProcessor.java:59)
        at org.orbeon.oxf.processor.ProcessorImpl$6.read(ProcessorImpl.java:995)
        at org.orbeon.oxf.processor.ProcessorImpl$ProcessorOutputImpl.read(ProcessorImpl.java:1178)
        at org.orbeon.oxf.processor.ProcessorImpl.readInputAsSAX(ProcessorImpl.java:350)
        at org.orbeon.oxf.processor.ProcessorImpl.readInputAsTinyTree(ProcessorImpl.java:377)
        at org.orbeon.oxf.processor.ProcessorImpl$4.read(ProcessorImpl.java:410)
        at org.orbeon.oxf.processor.ProcessorImpl.readCacheInputAsObject(ProcessorImpl.java:453)

In the end it appeared that NetUtils is using "java.io.tmpdir" for locating a temporary directory but reading the files created there is done using httpclient (same NetUtils) without url encoding! Problem with OS-X is that it contains weird characters in the temp file ('+++' in this case, you can even see it in different path values in the first log output and in the exception stacktrace in the log above).

A quick workaround is to use -Djava.io.tmpdir="/tmp" (replace /tmp with whatever you want) for the JVM that starts the server which tells the jvm where the temp dir to use, but still seems to be a bug in Orbeon.

Hope this helps.
Reply | Threaded
Open this post in threaded view
|

Re: Bug when running on Mac OS-X

Alessandro Vernet
Administrator
Siarhei,

Siarhei wrote
I'm trying to run orbeon (3.7.1)  on OS-X (10.5.7, jre 1.5.0_19-b02-304) and running into exception during ajax requests:

2009-07-06 15:28:34,090 ERROR [org.orbeon.oxf.webapp.ProcessorService] Exception at file:/var/folders/gL/gLHmVGbAFdSBQbeQakQSnU+++TM/-Tmp-/upload_285b603d_1
224f5e06e1__7f32_00000011.tmp
java.io.FileNotFoundException: /var/folders/gL/gLHmVGbAFdSBQbeQakQSnU   TM/-Tmp-/upload_285b603d_1224f5e06e1__7f32_00000011.tmp
        at org.jboss.net.protocol.file.FileURLConnection.connect(FileURLConnection.java:94)
        at org.orbeon.oxf.util.NetUtils.openConnection(NetUtils.java:1413)
        at org.orbeon.oxf.util.NetUtils.openConnection(NetUtils.java:1094)
[...]

In the end it appeared that NetUtils is using "java.io.tmpdir" for locating a temporary directory but reading the files created there is done using httpclient (same NetUtils) without url encoding! Problem with OS-X is that it contains weird characters in the temp file ('+++' in this case, you can even see it in different path values in the first log output and in the exception stacktrace in the log above).

A quick workaround is to use -Djava.io.tmpdir="/tmp" (replace /tmp with whatever you want) for the JVM that starts the server which tells the jvm where the temp dir to use, but still seems to be a bug in Orbeon.
Are you saying that JBoss sets the java.io.tmpdir to a directory that contains + in the name, and that those + characters are incorrectly replaced by space characters when trying to access the file?

Alex
Reply | Threaded
Open this post in threaded view
|

Re: Bug when running on Mac OS-X

Siarhei-2
Hi Alessando,

Alessandro Vernet wrote
Siarhei,

Are you saying that JBoss sets the java.io.tmpdir to a directory that contains + in the name, and that those + characters are incorrectly replaced by space characters when trying to access the file?

Alex
Yes, that's what (generally) I mean with few exceptions:
* I believe it's JVM's doing (not JBoss)
* Problem with the characters is the opposite. They are not replaced and that's the problem  - '+' is interpreted as space in URL if no encoding is done (which is the case)

In general the problem is that temp files are created (with java.io API) but you have no control over the path and then (on top of that) java.net.URLConnection is used to read those files (instead of the same java.io). If you use these tactics you can expect (platform specific) surprises like this :)
Reply | Threaded
Open this post in threaded view
|

Re: Bug when running on Mac OS-X

Alessandro Vernet
Administrator
Siarhei,

Siarhei wrote
Yes, that's what (generally) I mean with few exceptions:
* I believe it's JVM's doing (not JBoss)
* Problem with the characters is the opposite. They are not replaced and that's the problem  - '+' is interpreted as space in URL if no encoding is done (which is the case)
The opposite? So you're saying that the java.io.tmpdir contains a path with spaces, but on disk the directory has + in its name?

Alex
Reply | Threaded
Open this post in threaded view
|

Re: Bug when running on Mac OS-X

Siarhei-2
Alessandro,

I apologize if I didn't express myself clear enough.

What I mean is that on the file system the directory contains '+'. But read actions on files in that dir are done with URLConnection without URL encoding. In short, the answer to your question is Yes :)

In the stack trace you see spaces because the exception probably just does .toString() on the URL (which has non-escaped '+' which results).

Alessandro Vernet wrote
Siarhei,

Siarhei wrote
Yes, that's what (generally) I mean with few exceptions:
* I believe it's JVM's doing (not JBoss)
* Problem with the characters is the opposite. They are not replaced and that's the problem  - '+' is interpreted as space in URL if no encoding is done (which is the case)
The opposite? So you're saying that the java.io.tmpdir contains a path with spaces, but on disk the directory has + in its name?

Alex
Regards,
Siarhei
Reply | Threaded
Open this post in threaded view
|

Re: Bug when running on Mac OS-X

Alessandro Vernet
Administrator
Siarhei,

Siarhei wrote
What I mean is that on the file system the directory contains '+'. But read actions on files in that dir are done with URLConnection without URL encoding. In short, the answer to your question is Yes :)

In the stack trace you see spaces because the exception probably just does .toString() on the URL (which has non-escaped '+' which results).
Ah, I get it: the path contains the + characters both on disk and in the environment variable, but those + are replaced by spaces at some point, hence the exception. This behavior would be reasonable for a URI, but isn't for a the path to the temporary directory coming from java.io.tmpdir.

I created a bug for this, but unless this is a critical issue for one our clients, this isn't one that we will jump on. Of course, if you have a fix for this, we'll be glad to push it to the source code repository.

http://forge.ow2.org/tracker/index.php?func=detail&aid=314032&group_id=168&atid=350207

Alex