Thanks Kristian for a good RFE idea. And thanks Jerom for help.
If you have any suggestion, please continue let us know. A good product
quality comes from user !
Thanks,
Judy
Jerome Dochez wrote:
> 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
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: quality-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: quality-help_at_glassfish.dev.java.net
>