[
https://issues.apache.org/jira/browse/TIKA-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15830056#comment-15830056
]
Konstantin Gribov commented on TIKA-2245:
-----------------------------------------
[[email protected]], I accept using JUL in {{tika-core}} since we have no
deps there (and will have only {{commons-io}} at some later point). And
bringing {{slf4j-api}} may be worth considering if we will use external deps in
core anyway. At least discussable thing, I guess.
But I'm against using JUL in {{tika-parsers}}: it's hard to configure, it
cannot be directed to other logging backend without using {{jul-to-slf4j}}, it
have extra runtime cost like string concatenation and calling {{toString()}}
for any object which state is logged.
Anyway, we'll always have deps which use JUL, commons-logging-api and slf4j-api
because logging api choose is up to upstream developers in their libs. Why not
use common and present dependency to log anything through it?
When I use Tika in my downstream projects I configure logging as I described at
wiki page: {{logback-classic}} as impl (usually runtime dependency) and
{{jul-to-slf4j}}, {{jcl-over-slf4j}}, {{log4j-over-slf4j}} to forward all other
logging frameworks apis via {{slf4j-api}} to logback. It works perfectly, has
one point to configure etc.
> Standardise logging
> -------------------
>
> Key: TIKA-2245
> URL: https://issues.apache.org/jira/browse/TIKA-2245
> Project: Tika
> Issue Type: Improvement
> Components: parser
> Affects Versions: 1.14, 1.15
> Reporter: Matthew Caruana Galizia
> Labels: logging
>
> Tika parsers sometimes use Log4j's Logger, sometimes the JUL
> (java.util.logging) Logger and sometimes SLF4j.
> It would be better to standardise on a single facade, for the sake of not
> having to configure multiple loggers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
