java.util.logging vs swing

[Andy Michalec]

At first I want to say hello to everybody... for last few months I have been only reader of this forum but now it's time to step out of shadows

My question is SCJD related, although it seems to be more general. I am using 'java.util.logging' to trace flow of activities. Everything was fine but since I have started writing GUI part strange things happen.

In my app, first starts Runner class which parses command line etc. and then it creates MainFrame (inheriting from JFrame) and shows it; then runner finishes and activity remains in Swing parts (event queue threads keep app alive).
During development session (running MainFrame directly) it writes to log properly, but when it is run through Runner class, only Runner entries appear in log.

I spent few hours figuring problem out and eventually I discovered that when Runner finishes loggers stop working. I did simple test - I have added some sleep in Runner after spawning MainFrame and... MainFrame did logging until Runner thread was sleeping.
I did not further research but as for me the problem is within logging mechanism. Probably loggers store some data in context of thread which has loaded classes writing to logs - until this thread remains accessible logging by other threads (AWT event queue threads) works fine. But after loading thread's death logger are no more valid and swing/AWT's thread calls to loggers methods do fail

I did simple trick in Runner class logic - after spawning GUI it joins to AWT's event queue, so it does not die at all (until GUI is closed with JVM)

Now the questions are:
1) will this workaround be treated as too complex code, having impact on final score
2) does anybody know this 'java.util.logging' issue and other workarounds? I would like to keep using logging parts but covering whole running code

cheers,
andy.

[Andrew Monkhouse]

Hi Andy,

Welcome to JavaRanch and this forum. Could you please check the JavaRanch Official policy on registered names and adjust your displayed name to suit? We only allow initials in place of the first name. You can change your displayed name here.

When trying to debug a problem, it is often useful to start with a very simple test that either shows the problem (and then can be shown to others to get help), or doesnt show the problem (in which case you might have to rethink your assumptions). I have tried to recreate your problem, starting with a simple Runner class:

package text;
 
import java.util.logging.*;
 
public class Runner {
    private static Logger myLogger = Logger.getLogger("text");
 
    public static void main(String[] args) throws Exception {
        myLogger.severe("Runner started");
        new gui.Gui();
        myLogger.severe("Runner finishing");
    }
}

The Runner class creates a GUI:

package gui;
 
import java.awt.event.*;
import java.util.logging.*;
import javax.swing.*;
 
public class Gui extends JFrame implements ActionListener {
    private static Logger myLogger = Logger.getLogger("gui");
 
    public Gui() {
        myLogger.severe("Constructing Gui");
 
        setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
 
        JButton clickMe = new JButton("Click me");
        clickMe.addActionListener(this);
        add(clickMe);
 
        pack();
        setVisible(true);
 
        myLogger.severe("Constructed Gui");
    }
 
    public void actionPerformed(ActionEvent e) {
        myLogger.severe("Button clicked - ignoring");
    }
}

When I run this, I see the output from the Runner class, it calls the GUI constructor, then the Runner class exits. Some time after that (well, 5 seconds ) I did some work in the GUI, which resulted in further logging:

16/01/2006 00:21:07 text.Runner main
SEVERE: Runner started
16/01/2006 00:21:07 gui.Gui <init>
SEVERE: Constructing Gui
16/01/2006 00:21:08 gui.Gui <init>
SEVERE: Constructed Gui
16/01/2006 00:21:08 text.Runner main
SEVERE: Runner finishing
16/01/2006 00:21:13 gui.Gui actionPerformed
SEVERE: Button clicked - ignoring
16/01/2006 00:21:14 gui.Gui actionPerformed
SEVERE: Button clicked - ignoring

So - have I misunderstood your problem? Because I think that this working correctly.

Regards, Andrew

[Andy Michalec]

Thanks for supersonic reaction!

I have already aligned to forum rules

Comming back to my problem... You have inspired me to look through the code written weeks ago that now I feel ashamed. As you can suppose it was my fault. In my case, Runner main routine has finally block that does some clean up, and also logging shutdown (

LogManager.getLogManager().reset()

) which apparently causes logger to keep mouth shut when Runner is done :/
Now I am amazed again, why I had not just taken a break instead of drilling down this problem long night hours

So switching a bit problem topic, I wonder why logger does not clean up lock file (this one with ".lck" extension). Placing

LogManager.getLogManager().reset()

was first approach to eliminate this misbehavior. I have googled after this but did not find working solution...
How to hint logger that no more logging will occure and logger can remove lock file? Any ideas?

cheers,
andy