Hi Jerome, all;
and first off, thanks for your comment and thought on this.
Jerome Dochez schrieb:
[...]
> you can do that today by adding a handler in the logging.properties
> handlers list, your handler would then be invoked automatically for all
> logger messages and would be able to sort out which ones it want to log
> in a different file.
[...]
> would that not be enough ?
I would like to add a few things to that in order to make clearer what I am
dreaming of / what I would like to have:
- In some situations, I am about to do debugging / tracing of exceptions
across applications. In these situations, so far I use the gf web
administration to raise the log level for packages / classes in question to
non-production logging levels ("INFO" to "FINEST"). This generates bunches
of output, which by then I have to cut off server.log, eventually strip out
logging output dumped by classes not related to the problem, and hope in the
end not to have missed anything. For these cases, I would like to, say, set
up a "temporary" logger set to dump all its output to a
"trace-<timestamp>.log" log file, set all the packages / classes I would
want to monitor for that to dump their output to that very logger, get done
what I need to do to reproduce the error, switch the classes logging back to
the "normal" output and examine the "trace-<timestamp>.log" either online
using the web administration console or scp'ing to some other machine,
knowing it will just contain the output I wanted to catch.
- In other situations, I would like to set up logging for cross-application
issues (access to user data, in example) to go to a central logging file
(say, "useraccess.log"). As I would on the fly select which packages should
considered worth logging there, this should be something to be configurable
at runtime.
- Ideally, all these settings should be possible to accomplish by a
designated "glassfish administrator" who has only access to the gf web
administration panel but not to the machine glassfish is running on (no ssh
login, no console access, ...). This generally leaves dealing with
logging.properties out of the way here.
- Likewise, I would like to have these settings in a consistent environment
to ease maintaineance - the logging configuration should be backed up doing
"asadmin backup-domain" and recovered the same way. And, there should be one
place to do these settings, most favorably the glassfish administration
console where by now there already is some of these stuff to be set up
(logging levels) - I would prefer not having to explain to admins/devs to do
"one half" of these configurations in glassfish web console and "the other
half" using some text editor on logging.properties.
Generally, I am not sure whether this is desirable to a majority of users. I
just happened to stumble across this while moving from tomcat to glassfish,
figuring out that (a) log files generated by log4j in stock configuration
weren't readable using the glassfish log viewer, (b) I failed to configure
logging for my application using either log4j or JDK logging to provide
glassfish- web-console - readable log files lacking a formal output
definition for that, (c) according to the feedback I had on this on the
glassfish users mailing list, it seems no one so far either dealt with or
bothered about these things. So far I actually prefer the approach to have
logging independent of an actual application globally configured within the
container, not having to worry about the "how's" and "where's" in my very
applications (like I did with log4j). However for that I think glassfish
could provide a little more tooling for making logging configuration what it
should be - a piece of infrastructure which is just "there". ;)
Thanks for any comments on that, best regards.
Kristian
--
Kristian Rink
cell : +49 176 2447 2771
business: http://www.planconnect.de
personal: http://pictorial.zimmer428.net
"we command the system. calling all recievers.
we are noisy people for a better living".
(covenant - "monochrome")