GWT 2.1 logging and JUnit tests

[SteveC]

I have managed to implement the logging in GWT 2.1 into my project.
However I have JUnit tests that don't play well with the new logging.

The JUnit test cases are based on TestCase and Mock out the View so
that the GWTestCase and the headless browser can be avoided. However,
since the gwt.xml file is not read when a JUnit test case is run, the
logging config is not seen and logging doesn't work as planned.

To test logging all the different levels, the constructor for my
presenter has logging calls for each level. The only levels that are
output are SEVERE, WARNING, and INFO. Even calling the
setLevel(Level.ALL) method on the Logger class does not fix this. It
looks like the default level is INFO.

Is there some way to get your JUnit tests to work correctly with the
new logging facility?

[unnurg]

Hi Steve -
If you're using a JUnit test, then it's just running java and using
the JRE implementations for any java.util.logging calls, not the GWT
emulations. I'm not sure why the setLevel method isn't working -
perhaps something with your logging.properties file? Actually - I
suspect that this is what's happening:
- Your java environment by default adds a ConsoleHandler to the
RootLogger
- Your java environment by default sets the level of the RootLogger
to INFO
- You're adding a child logger to the root logger and setting it's
level to ALL
- You log to your child logger, it logs all messages to it's
handlers (but it doesn't have any handlers, so nothing is output)
- Your child logger passes it's message up to the RootLogger, which
logs only INFO and above messages to it's handlers (the
ConsoleHandler)
- The ConsoleHandler ends up outputting INFO and above messages to
the error console, where you're looking for log messages
- The solution would be to do setLevel on the RootLogger rather than
your logger, or configure the RootLogger to have Level.ALL in your
logging.properties file and then changing the level of your child
logger should work fine.

That's my best guess, but whatever it is, it should be due to your
server side configuration of logging and independent of GWT.

- Unnur



The following information may be helpful to you if you want to get
more involved:

Essentially, Logging.gwt.xml contains an entry point class
LogConfiguration (this is not an emulated class). In it's OnModuleLoad
function, the LogConfiguration class will read your gwt.xml
properties, add the correct handlers to the root logger and set the
level of the root logger. You may be able to mock out the
LogConfiguration class somehow if you really want to test the client
side handlers. However - if you're just interested in the logging, and
you don't care about the handlers, then using your logging.properties
file to add a regular Java handler (maybe a ConsoleHandler) to the
root logger would be fine (see my comments above, I suspect your
system is already doing this for you)

If you do want to test the client side handlers, you'll probably need
to mock some of them out since they use JSNI calls to log to things
like the javascript console). You should know that things will
possibly get quite dicey since now the GWT code will be sharing a root
logger with any server side logging you have set up (this may not be a
problem in the unit test). We do some byte code rewriting tricks to
work around this in DevMode (which also uses the JRE implementations
of the java.util.logging classes rather than the GWT implementations).

[SteveC]

The problem was that my JUnit test are using the JRE's
logging.properties file located in jre/lib/. I made a custom copy of
it and put it in my project. I had to modify the
java.util.logging.ConsoleHandler.level from it's default of INFO to
ALL in the logging.properties file. I use a -D-
Djava.util.logging.config.file=<somePath>/trace.properties flag in
Eclipse as a VM argument in my Run/Debug configurations.

On Oct 14, 12:03 pm, unnurg <unn...@google.com> wrote:
> Hi Steve -
>   If you're using a JUnit test, then it's just running java and using

> the JRE implementations for any java.util.loggingcalls, not the GWT

> emulations.  I'm not sure why the setLevel method isn't working -

> perhaps something with yourlogging.properties file?  Actually - I

> suspect that this is what's happening:
>   - Your java environment by default adds a ConsoleHandler to the
> RootLogger
>   - Your java environment by default sets the level of the RootLogger
> to INFO
>   - You're adding a child logger to the root logger and setting it's
> level to ALL
>   - You log to your child logger, it logs all messages to it's
> handlers (but it doesn't have any handlers, so nothing is output)
>   - Your child logger passes it's message up to the RootLogger, which
> logs only INFO and above messages to it's handlers (the
> ConsoleHandler)
>   - The ConsoleHandler ends up outputting INFO and above messages to
> the error console, where you're looking for log messages
>   - The solution would be to do setLevel on the RootLogger rather than

> your logger, or configure the RootLogger to have Level.ALL in yourlogging.properties file and then changing the level of your child

> logger should work fine.
>
> That's my best guess, but whatever it is, it should be due to your

> server side configuration ofloggingand independent of GWT.

>
> - Unnur
>
> The following information may be helpful to you if you want to get
> more involved:
>

> Essentially,Logging.gwt.xml contains an entry point class

> LogConfiguration (this is not an emulated class). In it's OnModuleLoad
> function, the LogConfiguration class will read your gwt.xml
> properties, add the correct handlers to the root logger and set the
> level of the root logger.  You may be able to mock out the
> LogConfiguration class somehow if you really want to test the client

> side handlers. However - if you're just interested in thelogging, and

> you don't care about the handlers, then using yourlogging.properties
> file to add a regular Java handler (maybe a ConsoleHandler) to the
> root logger would be fine (see my comments above, I suspect your
> system is already doing this for you)
>
> If you do want to test the client side handlers, you'll probably need
> to mock some of them out since they use JSNI calls to log to things
> like the javascript console). You should know that things will
> possibly get quite dicey since now the GWT code will be sharing a root

> logger with any server sideloggingyou have set up (this may not be a

> problem in the unit test).  We do some byte code rewriting tricks to
> work around this in DevMode (which also uses the JRE implementations

> of the java.util.loggingclasses rather than the GWT implementations).

>
> On Oct 14, 7:28 am, SteveC <st...@cannon.name> wrote:
>

> > I have managed to implement theloggingin GWT 2.1 into my project.

> > However I have JUnit tests that don't play well with the newlogging.
>
> > The JUnit test cases are based on TestCase and Mock out the View so
> > that the GWTestCase and the headless browser can be avoided.  However,
> > since the gwt.xml file is not read when a JUnit test case is run, the

> >loggingconfig is not seen andloggingdoesn't work as planned.
>
> > To testloggingall the different levels, the constructor for my
> > presenter hasloggingcalls for each level.  The only levels that are