You only write one version - the one with logging statements.
They will be removed at RUNTIME - given the proper class loader.
The Frog library I referenced allows a degree of logging without
writing any logging code - it is injected at runtime.
On Jan 9, 2009, at 2:31 PM, Shalin Shekhar Mangar wrote:
On Sat, Jan 10, 2009 at 12:41 AM, robert engels
<reng...@ix.netcom.com> wrote:
This is not really true these days. Dynamic class instrumentation/
byte modification can remove the calls entirely (for loggers not
enabled). They can be enabled during startup (or a reload from a
different class loader).
See the paper at http://www.springerlink.com/content/ur00014m03275421
1. A user will need to write code using the technique in that paper
to remove logging statements from Lucene if he does not want them?
2. Or, Lucene can create two distributions, one with logging and
the other with logging removed through bytecode modification.
I think it is unfair to expect users to do #1. Is there an existing
open source project which Lucene can add to the build process to do
#2?
If we forget the bytecode modification for a moment, how much cost
does this add to Lucene when used by a real application with slf4j
logging? (e.g. Solr uses the jdk adapter and no-op adapter cannot
be used)
--
Regards,
Shalin Shekhar Mangar.
