27 Sep
2014
27 Sep
'14
9:14 a.m.
Hi Edy,
On 26 Sep 2014 at 22:59:01, Eduard Moraru
(enygma2002@gmail.com(mailto:enygma2002@gmail.com)) wrote:
Hi,
I`m not very happy with seeing "[Thread-1] DEBUG o.x.shutdown" everywhere
and knowing that a problem occurred "during shutdown" instead of knowing
the exact component and location of the problem.
Sure, although:
1) One important part is the order
2) The message contains the information about the component/system being shut down so it’s
very easy to find where in the code it corresponds
It might look a bit better
for users, but users are not the ones that will be fixing the problem, so
IMO we should keep it developer friendly with explicit class loggers.
Devs have access to the code. It takes about 5 seconds to do a search on a string in the
code in case you really don’t know where the log statement is.
I have not really looked into this topic that much,
but a google search on
some keywords from this discussion come up with this result[1] that leads
to logback Filters[2] which you`ve already mentioned and which seem to
support what we need (i.e. from a filter, only ACCEPT events that are
marked with the desired marker e.g. "shutdown" -- or whatever more complex
scenario that we need).
I already mentioned that we don’t use Logback, we use SLF4J and SLF4J has no filters. It
has Markers and I researched it and I didn’t find it good for our use case from different
angles: it’s only implemented in Logback apparently and it doesn’t fit our need.
I trust you have better knowledge on the topic, but
if, to achieve what you
described, we could avoid juggling between 3 loggers (init, general and
shutdown) for each component and instead just mark the log events of the
single general logger that we use in the component, I`d be +1 for that.
At this stage I don’t know of an alternative except printing the class name as part of the
message but I really don’t see the point. Have you really tried enabling debug logs and
see the result and then tried to find the code related to a message. If you do I believe
your fears will go away immediately ;)
Thanks
-Vincent
Thanks,
Eduard
----------
[1]
http://stackoverflow.com/questions/16813032/what-is-markers-in-java-logging…
[2] http://logback.qos.ch/manual/filters.html
On Fri, Sep 26, 2014 at 11:52 AM, vincent(a)massol.net
wrote:
> I wanted to go ahead and close this issue to move on so I’ve committed
> with http://jira.xwiki.org/browse/XWIKI-11122 (only for shutdown for now).
>
> We can always revisit it/tune it (it’s only on the master branch for
> 6.3M1).
>
> Thanks
> -Vincent
>
>
> On 24 Sep 2014 at 18:04:46, vincent(a)massol.net (vincent(a)massol.net(mailto:
> vincent(a)massol.net)) wrote:
>
> >
> >
> >
> >
> >
> > On 24 Sep 2014 at 17:09:51, vincent(a)massol.net (vincent(a)massol.net
> (mailto:vincent@massol.net)) wrote:
> >
> > >
> > >
> > > On 24 Sep 2014 at 16:32:53, Denis Gervalle (dgl(a)softec.lu(mailto:
> dgl(a)softec.lu)) wrote:
> > >
> > > > Hi Vincent,
> > > >
> > > > I do not think this is the right way to fix your problem.
> > > > Basically what you need is some transversal way to filter events.
> > > > I have never used them, but if IIRC, SL4J implements Markers, which
> allows
> > > > to mark some logging, and Logback should support filterinb on
> Markers.
> > > > Could you check that solution, it could a better fit for your need
> IMO.
> > >
> > > Good idea, I’ll check.
> >
> > Ok it may work with Markers but it would work only with Logback. We
> would have to configure our logback.xml with something like this:
> > http://logback.qos.ch/manual/appenders.html#OnMarkerEvaluator
> >
> > Actually I’m not even sure we can do what we want with this since in all
> the examples I’ve found you could decide to use a specific appender which
> is not our use case: we want the same appender but change the log level
> according to a marker. I think this can be achieved with Filter but that’s
> not in the SLF4J API AFAIK.
> >
> > Not sure it’s worth tying us to Logback just for this.
> >
> > OTOH having named loggers is something well understood and supported by
> all logging systems so I’d go for this.
> >
> > Thanks
> > -Vincent
> >
> > > Thanks
> > > -Vincent
> > >
> > > > On Wed, Sep 24, 2014 at 2:06 PM, vincent(a)massol.net
> > > > wrote:
> > > >
> > > > > Hi Devs,
> > > > >
> > > > > I’d like to add some logging to debug what happens when XWiki
> shuts down.
> > > > >
> > > > > One solution would be to just use the standard class loggers
with
> > > > > LOGGER.debug(…).
> > > > >
> > > > > However this means activating debug logging for everything and
> thus you
> > > > > cannot just focus on the shutdown part.
> > > > >
> > > > > WDYT about adding 2 new loggers
"org.xwiki.initialization" and
> > > > > “org.xwiki.shutdown”?
> > > > >
> > > > > Example usage:
> > > > >
> > > > > /**
> > > > > * Logger to use to log shutdown information.
> > > > > */
> > > > > private static final Logger SHUTDOWN_LOGGER =
> > > > > LoggerFactory.getLogger("org.xwiki.shutdown");
> > > > >
> > > > > ...
> > > > >
> > > > > SHUTDOWN_LOGGER.debug("Stopping component [{}]...",
> > > > > instance.getClass().getName());
> > > > > ...
> > > > > SHUTDOWN_LOGGER.debug("Component [{}] has been
stopped",
> > > > > instance.getClass().getName());
> > > > >
> > > > > Then it becomes easy to set, in logback.xml:
> > > > >
> > > > >
> > > > >
> > > > > A small variation would be to use SHUTDOWN_LOGGER.info() and in
> > > > > logback.xml, by default to have:
> > > > >
> > > > >
> > > > >
> > > > > Note that this would be the first time we use non-class loggers
> which is
> > > > > why I’m asking for your go-ahead.
> > > > >
> > > > > Thanks
> > > > > -Vincent