Aaron,
You can get the server version from the ServerInfo class. Also we
already control initializing the default log level in the main
class. I believe we can implement -v -vv -vvv options by setting
the initial default log level to error, info or debug. If that
doesn't work, I believe that system properties are available to log4j
properties files, so we could have a geronimo.log.level.default which
we make available to be consumed by which ever log implementation we
choose.
-dain
On Jul 5, 2005, at 4:24 AM, Jeff Genender wrote:
David Blevins wrote:
On that note I wouldn't mind a -v -vv -vvv approach for printing log
messages to STDOUT. Maybe each 'v' could drop the log level down one
notch.
I do like the stuff Aaron whipped up as default.
Absolutely. I think Aaron's status bar is great as a default. But
we really need an easy way to get the logs to stdout in a quick and
easy manner.
-David
On Mon, Jul 04, 2005 at 10:24:35PM -0600, Jeff Genender wrote:
Ok...lets hash this last one out...
I would really like to have a command line parameter to start
Geronimo like "-verbose" that sends the log to the stdout (like
it was before). As a developer, its nice to have this instead of
having to muck with the log4j files. Although I could open up
another terminal and tail -f the log...this is a real PITA.
Luckily I can do this since I develop on MacOSX. The windows
users may have a more difficult time with this since they lack
some of the UNIX commands we are used to (like tail), and would
be forced to download cygwin or other.
For ease of use, a verbose parameter would make good sense,
especially for developers.
I love this new status bar...its really clean...but I would like
the option to spew the logs to the terminal.
I would like to get people's feelings on this since there are 2
sides having this option.
Jeff
Aaron Mulder wrote:
I just put in a change with nicer startup console output. It
gives some progress and status information during the server
start process
and lists the apps deployed and ports used at the end of the
startup. Since it uses \r characters to make it work, the
output looks lousy if you
view it in a log file, so there's a -noprogress argument you can
add to
the server command line to suppress it (which the Maven deploy
tool does, for example).
In any case, I'd appreciate any thoughts or feedback on the
new look.
* Jeremy's already suggested adding a middle ground between -
noprogress
and what's in there, where it would print more or less the same
information but one message per line so it looks nicer in a
log. There's just an interface to implement to get the startup
sequence
calls, so it should be easy enough to support that.
* David J recommended the current combination of a short
progress bar and
status messages instead of my initial attempt, which just had a
long
(but not very fine-grained) progress bar. I like the way it
came out.
Now that I've done this, I think we can use the same
technique to
hide the password on the deployer command line.
Thanks,
Aaron
Log message
-----------
New server startup output
- shows a progress bar, timer, and operation status during start
- shows a list of started application modules (other than o/a/g/
System*)
- shows a list of network ports that GBeans tried to bind to
The port list is voluntary on behalf of the GBeans. They must
declare an
attribute of type java.net.InetSocketAddress in order to be
included
in the list (though it can be a read-only attribute). We should
review
the current GBeans and make sure they do.
There is also some logic around calculating the name of a
service. For
example, if the same GBean has more than one InetSocketAddress
attribute,
it tries to add the name of each attribute in the port list, and
if the
GBean has a "name" attribute (for GBeans tht may be deployed
more than
once with different names) it includes that too.
The new progress bar does not render particularly well in log
files, and
can be disabled by passing -noprogress on the server command
line. The
maven deployment plugin does that.
