Bug 412096

Comment 1 John Arthorne 2013-07-04 12:36:32 EDT

I would like to understand why a build-time profile is a good solution for this. Isn't this something that a server administrator would want to be able to configure and change *after* the build is done. More generally, the producer of the build doesn't necessarily know what logging strategy is appropriate for all consumers, and we don't want to require consumers to run their own builds just to configure logging differently. I would expect instead an orion server configuration property or system property to configure this.

Comment 2 Maciej Bendkowski 2013-07-08 04:55:36 EDT

There are at least two cases where, in my mind, a build-time solution is better suited. 

Firstly, the log analyzer functionality requires a file-based log strategy. Orion is shipped with a default console-based logback configuration file. If we would build-in the monitoring capabilities, we'd have no way of ensuring the log analyzer is working 'out the box' (only the first encountered logback configuration file is loaded if none is explicitly set using a VM property). 

Secondly, monitoring capabilities may hinder performance, which might be critical in some custom use cases. Log analyzer is probably a bad example, because it's rather an on-demand functionality, but consider some kind of live-time user activity monitoring. Such resource-consuming capabilities should not be enabled by default in my mind.

Besides, in a separate build the server configuration is still required (setting the log file directory, rotation frequency and so on). It is possible to configure it all without a separate build, but in my opinion it's less effective.

Comment 3 John Arthorne 2015-05-08 09:33:14 EDT

We need to have monitoring capabilities built into our production systems, not in a separate build.