hmmm.. so that means if we want to customize logging
it would be for every plugin potentially?
Perhaps a common logger would atleast make some degree
of sense.
I really think it make sense.
When I fixed the issue about plugin dependencies, I began to create a log4j
plugin
in order to remove all the log4j versions imported by many plugins (what you
suggest).
But it is not so simple.
In fact, parse-rss and parse-pdf uses in their code some log4j imports just
to redirect
the log4j output to the java's native logger (They don't really customize
it).
The imports of log4j are only used by some others jars imported by the
plugins (not a direct dependency).
If these jars the plugins depends on use some common log4j features, it
seems there's no problem to remove
the log4j jars in each plugin and add a dependency to a new lib-log4j
plugin. But the only ways to check for no regression are:
* Look in the source code of PDFBox and other jars imported by plugins and
that use log4j and checks that they are able to use any other log4j-1.2.xversion
* Create a lib-log4j plugin, remove all log4j jars and add a dependency to
lib-log4j plugin in all the plugins that previously imported log4j.jar , and
then perform a runtime test of these plugins and cross fingers
But sure, I really think it make sense.
Jérôme
--
http://motrech.free.fr/
http://www.frutch.org/
