27 Sep
2014
27 Sep
'14
10:47 a.m.
On Sat, Sep 27, 2014 at 9:14 AM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
This does not really help reading the logs.
Really, we use SLF4J without a logging framework ? Please Vincent, do not
be so misleading! What would be the need of filters in SLF4J, it is a
facade for logging, not filtering logs.
SLF4J supports Markers. So our code could use marker from now on, and
nobody could complain.
We are also so kind, that we provide a logging framework to our fellow
users, and it appears that this one support Markers. We provide them a
default configuration for that loggers as well, and I do not see why would
not be able to also provide some helpful filter (like
https://gist.github.com/takumakei/988965), that would allow exploiting
markers with the default framework we provide.
Now, experimented users to use their own framework, to extend it to use
Markers, and so on.
Hi Edy,
On 26 Sep 2014 at 22:59:01, Eduard Moraru (enygma2002(a)gmail.com(mailto:
enygma2002(a)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.
Yes their is alternatives, Markers is one of them.
You could also put keywords ("[SHUTDOWN]") in your log message and use
message filters, but this is really if your dislike markers. Actually, you
could do both, helping the poor guys with a framework that does not support
Markers. Therefore, the fact that Markers are only supported by Logback is
not an issue, if you need it, you can use Logback or filter on messages.
Moreover, we pack Logback by default.
I see your idea as being disruptive in the way we name loggers for years
now, and the usual way many programmers do.
When I need logging about a given class, I could I get it, if it logs to a
larger logger ?
No, definitely, I am -1 on your idea, it looks like a hack.
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
--
Denis Gervalle
SOFTEC sa - CEO
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs