On Tue, 5 Jul 2005, Dain Sundstrom wrote:
> You can get the server version from the ServerInfo class.
Does that return "208435" or "1.0-SNAPSHOT"? I'm assuming the
latter, which isn't as helpful. The specific SVN version would really be
the most useful, wouldn't it? Still, I can start with what we've got and
we can always tune it later.
> 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.
We can certainly set the initial log level, but I think the log
GBean overwrites that (based on the content of the properties file) as
soon as it is loaded.
> 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.
I'll give that a shot.
Thanks,
Aaron
> 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.
> >
>
>
