[vfs] if file name Non-breaking space -> "Stream closed"

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

[vfs] if file name Non-breaking space -> "Stream closed"

JavaDev7
Hi,

Exception is thrown if zip archive contains file with non breaking space char.

So if file has name: "File" + 0x00A0 + "name.txt" in zip archive IOException is thrown.

"Exception in thread "main" java.io.IOException: Stream closed"

Is it vfs bug or I am doing something wrong..?

Thanks in advance..
_____________________________________________________________________

http://zajtrajsie.sme.sk - tipujte najblizsie sportove vysledky aj politicke udalosti

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[daemon] Odd user.dir behaviour with procrun / log4j

Jacob Zwiers
I have installed a java batch process using the version of procrun that ships with tomcat 5.5.33:

   Commons Daemon Service Runner version 1.0.5.0/Win32 (Jan  5 2011)
   Copyright (c) 2000-2011 The Apache Software Foundation.

In the installation, I specify (among other JVM options):
  --JvmOptions="-Duser.dir=C:\LOCAL\serverapps"

My log4j.properties configuration includes:
   log4j.appender.InfoLogFile.File=../logs/info.log

However, the info.log file is being written to:
   C:\WINDOWS\logs

I've checked the value of user.dir at many different points and it's always "C:\LOCAL\serverapps".

But, log4j is behaving as if user.dir="C:\Windows\System32" (or some other subir of C:\Windows).

From what I can tell from the log4j source (1.2.16), the FileAppender deals only with the java.io.FileOutputStream and File classes which claim to make paths relative from the user.dir location.

I've worked around the issue, but I am curious:  has anyone else has encountered this type of behaviour?
 
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [daemon] Odd user.dir behaviour with procrun / log4j

Konstantin Kolinko
2011/8/19 Jacob Zwiers <[hidden email]>:

> I have installed a java batch process using the version of procrun that ships with tomcat 5.5.33:
>
>   Commons Daemon Service Runner version 1.0.5.0/Win32 (Jan  5 2011)
>   Copyright (c) 2000-2011 The Apache Software Foundation.
>
> In the installation, I specify (among other JVM options):
>  --JvmOptions="-Duser.dir=C:\LOCAL\serverapps"
>
> My log4j.properties configuration includes:
>   log4j.appender.InfoLogFile.File=../logs/info.log
>
> However, the info.log file is being written to:
>   C:\WINDOWS\logs
>
> I've checked the value of user.dir at many different points and it's always "C:\LOCAL\serverapps".
>
> But, log4j is behaving as if user.dir="C:\Windows\System32" (or some other subir of C:\Windows).
>
> From what I can tell from the log4j source (1.2.16), the FileAppender deals only with the java.io.FileOutputStream and File classes which claim to make paths relative from the user.dir location.
>
> I've worked around the issue, but I am curious:  has anyone else has encountered this type of behaviour?
>

1. I think java.io uses OS-level API to open files and resolve
non-absolute paths into absolute ones,  and your hacky attempt to set
user.dir property does not affect OS.

2. There is --StartPath option in procrun (see SO_STARTPATH in
prunsrv.c). I think it might be that it will allow to configure
working directory. I have not tested though.

3. I might be that you can define your own variable and reference it
in log4j.properties. I have not tested it though.  You wrote that you
have already worked around your original problem.

Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]