Hi Kristian
I see what you meant now. well that's obviously a feature we don't have
right now so I think the next thing to do is to file an RFE (you should
do it yourself to get notification/credit) and then we will see if this
is something we can do past-prelude.
Thanks, jerome
Kristian Rink wrote:
> 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
>
>