I referred to the case when you want normal production logs, like
access logs, or whatever.
Debugging with all common logging implementations is also broken,
because switching logging on/off dramatically changes multithreading
picture.
On Mon, Dec 8, 2008 at 17:02, Shai Erera <[EMAIL PROTECTED]> w
On Sat, Dec 6, 2008 at 11:52 AM, Shai Erera <[EMAIL PROTECTED]> wrote:
> On the performance side, I don't expect to see any different performance
> than what we have today, since checking if infoStream != null should be
> similar to logger.isLoggable (or the equivalent methods from SLF4J).
I'm lee
{quote}
My research shows there are no ready-made java logging frameworks that can
be used in high-load production environment.
{quote}
I'm not sure I understand what you mean by that. We use Java logging in our
high-profiled products, which support 100s of tps. Logging is usually turned
off, and
The common problem with native logging, log4j and slf4j (logback impl)
is that they are totally unsuitable for actually logging something.
They do good work checking if the logging can be avoided, but use
almost-global locking if you really try to write this line to a file.
My research shows there
On the performance side, I don't expect to see any different performance
than what we have today, since checking if infoStream != null should be
similar to logger.isLoggable (or the equivalent methods from SLF4J).
I'll look at SLF4J, open an issue and work out a patch.
On Sat, Dec 6, 2008 at 1:22
On Dec 5, 2008, at 11:36 PM, Shai Erera wrote:
What do you have against JUL? I've used it and in my company (which
is quite a large one btw) we've moved to JUL just because it's so
easy to configure, comes already with the JDK and very intuitive.
Perhaps it has some shortcomings which I'
Doug,
bq. It's tempting to add our own logging API, as you suggest, but I fear
that would re-invent what so many have re-invented before.
Haven't we already added our own logging API by introducing infoStream in
IndexWriter? All I'm proposing (as an alternative to Java logging) is to
make it a se
As a developer who would like to eventually develop core code in Lucene (I
started but then things changed drastically and so will wait for flexible
indexing and other APIs?), a standard logging system would make development
easier by making debugging easier. I rely heavily on log analysis in
deve
For some additional context, go over to the Solr mail archive and
search for "Logging, SLF4J" or see http://lucene.markmail.org/message/gxifhjzmn6hgloy7?q=Solr+logging+SLF4J
I personally don't like JUL and would be against using it. I could,
maybe, just maybe, be talked into SLF4J.
The oth
John Wang wrote:
If we were to depend on a jar for logging, then why not log4j or
commons-logging?
Lucene is used by many applications. Many of those applications already
perform some kind of logging. We'd like whatever Lucene adds to fit in
with their existing logging framework, not confli
I thought the main point is to avoid a jar dependency.
If we were to depend on a jar for logging, then why not log4j or
commons-logging?
-John
On Fri, Dec 5, 2008 at 1:00 PM, Doug Cutting <[EMAIL PROTECTED]> wrote:
> Shai Erera wrote:
>
>> Perhaps instead of introducing Java logging then (if yo
Shai Erera wrote:
Perhaps instead of introducing Java logging then (if you're too against
it), we could introdue a static InfoStream class, with a static
message() and isVerbose() methods.
It's tempting to add our own logging API, as you suggest, but I fear
that would re-invent what so many h
BTW, one thing I forgot to add: with infoStream, it's very difficult to
extend the level of output if one wants, for example, to add logging
messages to the search part (or other parts). The reason is one would need
to permeate infoStream down too many classes. Instead, with Java logging,
each clas
Have you ever tried to debug your search application after it was shipped to
a customer? When problems occur on the customer end, you cannot very easily
reproduce problems because customers don't like to give you access to their
systems, not always they are willing to share the index with you and l
I also feel that the primary usage of the internal messaging in Lucene
today is debugging, and we don't need a logging framework for that.
Mike
Doug Cutting wrote:
The infoStream stuff goes back to 1997, before there was log4j or any
other Java logging framework.
There's never been a big
The infoStream stuff goes back to 1997, before there was log4j or any
other Java logging framework.
There's never been a big push to add logging to Lucene. It would add a
dependency, and Lucene's jar has always been standalone, which is nice.
Dependencies can conflict. If Lucene requires one
I think the main motivation has always been to have no dependencies in
the core so as to keep it as fast and lightweight as possible. Then,
of course, there is always the usual religious wars around which
logging framework to use, not to mention the nightmare that is trying
to manage multi
17 matches
Mail list logo
