Prev: Handling extremely large input files
Next: Head First Java vs. Think in Java
From: Rhino on 29 Apr 2010 07:01
Tom Anderson <twic(a)urchin.earth.li> wrote in
news:alpine.DEB.1.10.1004290048090.18125(a)urchin.earth.li:

> On Wed, 28 Apr 2010, markspace wrote:
>
>> Rhino wrote:
>>
>>> The comment above that line says only that the "default file output
>>> in the user's home directory"
>>
>> User's home directory! Like /usr/rhino or C:\Users\Rhino or
>> /home/rhino.
>
> Is there anywhere it would be /usr/rhino?
>
>
> More importantly, why on earth is java writing logs to home
> directories? That's dreadful behaviour!
>
It may be dreadful behaviour but %h does indeed stand for the value
obtained from System.getProperty("user.home"). That is a bit unexpected
from my point of view too but what can you do?

--
Rhino
From: Rhino on 29 Apr 2010 07:03
Arne Vajh�j <arne(a)vajhoej.dk> wrote in
news:4bd8ce18$0$274$14726298(a)news.sunsite.dk:

> On 28-04-2010 12:10, Rhino wrote:
>> I'm wrestling with a challenging problem involving the
>> java.util.logging code, specifically a condition discussed in Bug ID
>> 6244047. Something that might help me a lot is some information about
>> some code used in the logging.properties file found in JRE/lib.
>>
>> Referring specifically to the logging.properties file in a Java 6
>> JDK, one of the lines says:
>>
>> java.util.logging.FileHandler.pattern = %h/java%u.log
>>
>> It would appear that %h and %u in the preceding line are variables
>> but I am at a loss to understand what values they have or where those
>> values are set. Can anyone clue me in?
>
> They are described in:
>
> http://java.sun.com/javase/6/docs/api/java/util/logging/FileHandler.htm
> l
>
>> The comment above that line says only that the "default file output
>> in the user's home directory" but I'm not clear on whether they are
>> referring to OS home directory (I'm using Windows XP SP2) or the Java
>> home directory. It's also possible that the values of %h and %u may
>> be getting overridden inappropriately somewhere, even if they were
>> set correctly in the first place, so I'd like to know how %h and %u
>> are being set and where they might be getting overridden.
>
> The above link says:
>
> "%h" the value of the "user.home" system property
>
> so it is OS home directory.
>
> Arne
>

Thanks. I found this myself eventually but not until after I'd posted. I
would have expected to see the variables described in the
logging.properties file or at least have a comment in there directing you
to the FileHandler API.....

--
Rhino
From: Lew on 29 Apr 2010 07:13
Tom Anderson wrote
>> More importantly, why on earth is java [sic] writing logs to home
>> directories? That's dreadful behaviour!

Rhino wrote:
> It may be dreadful behaviour but %h does indeed stand for the value
> obtained from System.getProperty("user.home"). That is a bit unexpected
> from my point of view too but what can you do?

You can try answering what Arne Vajhøj wrote:
>> If it [Java] has to pick a directory that:
>> - is known to exist
>> - where the app has write permission
>> - where files does not get deleted
>> - conceptually will exist on all platforms (or at least as many as
>> possible)
>> then what would you suggest?

--
Lew
From: Lew on 29 Apr 2010 07:18
Rhino wrote:
> As it turns out, the variables in the pattern are described in the
> FileHandler API. This tells me that %h represents the Java system property

As it turns out, Arne Vajhøj wrote, approximately eleven hours earlier:
>> They are described in:
>>
>> <http://java.sun.com/javase/6/docs/api/java/util/logging/FileHandler.html>

Rhino continued:
> "user.home", which is c:\Documents and Settings\Rhino in my case. (I'm just
> adding this information in case anyone down the road has the same issue.)

As was posted upthread:
>> For user name "lewbloch",
>> on Linux the home directory, and thus the Java system property
>> "user.home", is "/home/lewbloch".
>>
>> On Windows it's
>> "C:\Documents and Settings\lewbloch".

> I couldn't for the life of me remember where the variables in the pattern
> were documented and was disappointed to find the meanings not mentioned in
> the logging.properties file itself. Second best would have been a note in
> logging.properties telling me to look in the FileHandler API.

Excellent point.

--
Lew
From: Tom Anderson on 29 Apr 2010 18:19
On Wed, 28 Apr 2010, Arne Vajh?j wrote:

> On 28-04-2010 19:57, Tom Anderson wrote:
>> On Wed, 28 Apr 2010, markspace wrote:
>>
>>> Rhino wrote:
>>>
>>>> The comment above that line says only that the "default file output
>>>> in the user's home directory"
>>>
>>> User's home directory! Like /usr/rhino or C:\Users\Rhino or /home/rhino.
>>
>> Is there anywhere it would be /usr/rhino?
>>
>> On OS X, it would be /Users/Rhino, FWIW. On unix systems configured for
>> large numbers of users, it might well be /home/r/rhino (it's broken up
>> alphabetically). On unix systems which organise users by primary group
>> (and there are some), it would be /home/pachyderms/rhino. All of which
>> is useless information, of which i am a veritable mine.
>>
>> More importantly, why on earth is java writing logs to home directories?
>> That's dreadful behaviour!
>
> If it has to pick a directory that:
> - is known to exist
> - where the app has write permission
> - where files does not get deleted
> - conceptually will exist on all platforms (or at least as many as possible)
> then what would you suggest?

I'd suggest those assumptions are wrong. A library has no business
deciding to write logs anywhere on disk at all; it should write logs where
i tell it to, and only when i tell it to. If it has to log and i haven't
told it to write to a file, it should write to syserr.

tom

--
Formal logical proofs, and therefore programs - formal logical proofs
that particular computations are possible, expressed in a formal system
called a programming language - are utterly meaningless. To write a
computer program you have to come to terms with this, to accept that
whatever you might want the program to mean, the machine will blindly
follow its meaningless rules and come to some meaningless conclusion. --
Dehnadi and Bornat
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Handling extremely large input files
Next: Head First Java vs. Think in Java