Joris, would you mind taking a look at this one? The latest JDK available in Ubuntu repos is 1.6.0_16, and the reporter was using Windows as well. I am guessing you'd be on the latest, and any issue is probably somewhere within the JNI depths of JLine/JANSI.

I just installed 1.6.0_18 and had a look: I can reproduce the issue. I then removed the jansi jar and the problem persisted, so this is not related to our use of jansi. Must be jline-related probably, or some weird change in behavior of the java.util.logging stuff used by the Roo shell to produce the output.
I'll try to found out more later, when I have some more time than i do right now.

OK, of course I had to take a look immediately instead of going to bed... The AbstractShell.logger has a levelValue of 900 (WARNING) instead of 500 (FINE) after being created, so the log output is simply never written to the console. That leaves the question of where this value is coming from, I'll leave that for later. By simply adding this line to the AbstractShell constructor output is fixed:

this.logger.setLevel(Level.FINE);

Seems unlikely that this is related to JLine, must be some change in the LogManager's default configuration or something. Will try to found out root cause, if I can't find it within a reasonable amount of time I'll just commit the extra line of code as shown.

This looks like a bug in the 1.6.0_18 version of the LogManager indeed: instead of using the org.springframework.roo parent logger's configuration (which is set to FINE in Bootstrap), it uses the configuration of org.springframework (set to WARNING). Sun must have screwed up while adding some additional refactorings when introducing weak references to loggers in this codebase.

Easy workaround is setting the level in AbstractShell after obtaining the logger as I mentioned already, but I'll leave it to Ben to decide if and if so, how he wants to work around this bug.

Assigning back to Ben to decide best workaround for LogManager bug in 1.6.0_18.

Thanks for the research on this one, Joris. Appreciate it.

This is a bug introduced in Sun Java 1.6.0_18. Essentially the Bootstrap class sets up loggers for org.springframework @ WARNING level and org.springframework.roo @ FINE level. Roo classes would then normally acquire the logger via the typical Logger.getLogger(getClass().getName()) pattern, which ordinarily would give back a logger of FINE level (as all Roo classes are under org.springframework.roo). Unfortunately this no longer works as of Sun Java 1.6.0_18.

The workaround is I have now modified all Logger acquisitions to use a new static method, HandlerUtils.getLogger(Class<?>). This checks to see if the class is part of org.springframework.roo and if so ensures the returned Logger has its level explicitly set to FINE should the level have been null (which is what Sun Java 1.6.0_18 reports). This tests OK. For non-1.6.0_18 JDKs, the fact the level correctly returns a non-null value will mean the new static method does not modify the level. All Roo classes were modified to use the new HandlerUtils.getLogger(Class) static method and therefore use a correctly-configured logger.

Fix in SVN rev 581. Will be present in Roo 1.0.1.

Thanks heaps!