: Actually, Solr depends on Lucene :-)
Okay ... I must admit ... this is funnier then Ryan's "i prefer kittens"
comment.
yes, i suppose we have a core dependency on Lucene which could in theory
result in an incompatibility. That ship has sailed.
: SLF4J doesn't have a "LogMessage" to propaga
Actually, Solr depends on Lucene :-)
SLF4J doesn't have a "LogMessage" to propagate to the container since it's a
simple thin facade to the logging kit you want to use. In the case of JUL
which you're a fan of and what we all think should be the default
implementation if you don't take steps to
: Yes, but why ship any libraries w/ Solr then? We should write HTTPClient for
: ourselves, as well as all the other dependencies. Class loader hell is at the
: very heart of Java and is just something we all deal with unless we go to OSGi
: (I'm told, anyway, but I don't know enough about it) or
: In an effort to put this thread to rest with some sense of closure, perhaps we
yeah, right ... like that will ever happen :)
: [XX ] Keep solr logging as is. (JUL)
: [ ] Convert solr logging to SLF4J
-Hoss
A little late to the email party but...
[ ] Keep solr logging as is. (JUL)
[ X ] Convert solr logging to SLF4J
And SOLR-560 looks good too.
- will
On May 3, 2008, at 4:22 PM, Ryan McKinley wrote:
If a large subset of the community is in favor of moving away from
JUL
towards some alternative (and I'm not sure that's true),
Perhaps we should take a poll on solr-user? On the dev list, I
there are a few strong opinions, but I suspect
I'm not following the scenario you are suggesting as it would apply to SLF4J.
I understand that you describe a situation where SLF4J is loaded by both the
container and the webapp (and so they are technically different classes),
but not how this will pose a problem. Logger's are only used intern
is
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
> From: Chris Hostetter <[EMAIL PROTECTED]>
> To: Solr Dev
> Sent: Saturday, May 3, 2008 8:31:01 AM
> Subject: Re: Solr Logging
>
>
> FYI: I'm going to commit a minor list tab
If a large subset of the community is in favor of moving away from JUL
towards some alternative (and I'm not sure that's true),
Perhaps we should take a poll on solr-user? On the dev list, I there
are a few strong opinions, but I suspect most people don't really care
(as long as it works).
[ ] Keep solr logging as is. (JUL)
[ X ] Convert solr logging to SLF4J
FYI: I'm going to commit a minor list taboo and comment in a thread I'm
not caught up on -- I wrote this on the plane based on some thoughts I had
last night and this morning, and even though i don't have time to catch up
with this thread, I wanted to put this information out there since i
pro
Ehh... I don't think anyone would say that "commons logging is such a great
thing" in the first place. You'll find plenty of info to the contrary.
Besides, JCL is targeted at reusable libraries / embedded things and Tomcat
doesn't fit that and so it doesn't use it.
~ David
Shalin Shekhar Manga
>
> [ ] Keep solr logging as is. (JUL)
> [X] Convert solr logging to SLF4J
--
View this message in context:
http://www.nabble.com/Solr-Logging-tp16836646p17028119.html
Sent from the Solr - Dev mailing list archive at Nabble.com.
[ ] Keep solr logging as is. (JUL)
[X] Convert solr logging to SLF4J
--
View this message in context:
http://www.nabble.com/Solr-Logging-tp16836646p17027714.html
Sent from the Solr - Dev mailing list archive at Nabble.com.
On 2-May-08, at 11:50 AM, Mike Klaas wrote:
On 2-May-08, at 10:14 AM, Ryan McKinley wrote:
[ ] Keep solr logging as is. (JUL)
[ ] Convert solr logging to SLF4J
[ X ] Abstain
I am not at all part of the java-enterprise-y world, and though as
an outsider it strikes me as odd that that l
On 2-May-08, at 10:14 AM, Ryan McKinley wrote:
[ ] Keep solr logging as is. (JUL)
[ ] Convert solr logging to SLF4J
[ X ] Abstain
I am not at all part of the java-enterprise-y world, and though as an
outsider it strikes me as odd that that logging implementation in the
language's stdl
On May 2, 2008, at 1:14 PM, Ryan McKinley wrote:
[ x ] Convert solr logging to SLF4J
It won't be the end of it, though, as you have pointed out, the issue
comes up every few weeks/months...
In an effort to put this thread to rest with some sense of closure,
perhaps we could take a poll of our options:
[ ] Keep solr logging as is. (JUL)
[ ] Convert solr logging to SLF4J
I think the arguments for each option are:
JUL:
+ it is standard and *should* work everywhere
+ no adde
[ ] Keep solr logging as is. (JUL)
[X] Convert solr logging to SLF4J
Yes, but why ship any libraries w/ Solr then? We should write
HTTPClient for ourselves, as well as all the other dependencies. Class
loader hell is at the very heart of Java and is just something we all
deal with unless we go to OSGi (I'm told, anyway, but I don't know
enough about it) or
: As an aside, I do wonder why there isn't a JUL to Log4j adapter out there...
: maybe our energies would be better served directed at such a thing.
+1 :)
See Also: http://www.nabble.com/Solr-Logging-to16836646.html#a16838411
>> implementation. If people spent as much time writing implementat
It's not just a question of API compatibility, it's a question of *class*
compatibility (ie: byte code)
Even if the public APIs are consistent, it's very easy to get into
"classloader hell" when a webapp has one version of a class loaded (even
if it's a private class) while the servlet contain
David Smiley @MITRE.org wrote:
>
> (A) jul-log4j-bridge plus the "apache-log4j-component" library seems
> unmaintained
> (C) I had to update the log4j-boot.jar of JBoss to the latest Log4j-1.2.15
>
I went more or less through the same path; I did "custom" build the bridge
by stripping the need
Today I decided to take matters into my own hands and get jul-log4j-bridge to
work in my JBoss 3.x environment. The experience so far is:
(A) jul-log4j-bridge plus the "apache-log4j-component" library seems
unmaintained and I've seen a question asked of it on a list not get
responded to (that I h
The fact remains, there is still no solution available for those of us trying
to embed/deploy Solr in log4j-aware apps/environments besides
developing/deploying container-specific code. I still hope this community
can propose a better compromise.
If I had found the
http://people.apache.org/~psmit
That may meet the functional need but (a) it's unacceptable to the Solr dev's
for the same reason that ANYTHING other than JUL is on principle, and (b)
even someone like me finds the notion of a project specific log manager of
sorts too be worse on principle than any other possible choice (JUL or
ryantxu wrote:
>
> As long as there is strong opposition, I think we can deal with JUL...
>
We can; an attempt to mitigate JUL & the functional need is
https://issues.apache.org/jira/browse/SOLR-549 SOLR-549 .
It does respect the JUL choice and is a practical compromise that noone
seems to s
I don't know about you, but an issue that continues to flale up now and then
(with a long passionate thread as we are having now) strikes me as "strong
opposition".
If Solr had always used SLF4J (or even JCL), do you imagine there would be
any opposition that compared in any way to the opposition
I guess I'll shut up for now; we seem to have gone at it for awhile
and I'm
not sure what more there is to say on either party.
If history is any indication, the issue will lay fallow for 3-4 months
then flare up the next time someone bangs their head on JUL.
I agree with Hoss and Erik
Hmm. This is probably fixable doing either of these two (both are easy):
1. update the SLF4J in Jetty
2. at deploy time either remove slf4j from the war, or configure Jetty not
to use it (JBoss has that latter feature which is quite nice)
This is also a scenario that could play out with JUL, it'
On Apr 29, 2008, at 8:45 PM, Grant Ingersoll wrote:
Just because something is a standard doesn't mean it is good.
Just because someone containers haven't done what they need to do to
integrate in a standard logging API into their configurability
doesn't make it bad.
Erik
On Apr 29, 2008, at 6:14 PM, Chris Hostetter wrote:
: > JULI can be configured per-webapp also by adding a
logging.properties to the
: > classpath (add it to WEB-INF/classes). So you can configure
Handlers
: JULI is a Tomcat thing
:
(http://tomcat.apache.org/tomcat-6.0-doc/api/org/apach
: That is a convincing argument, admittedly. But by using SLF4J, Solr won't
: alienate users using such containers (like me, using JBoss 3.x), ANY
: container should be fine based on the way SLF4J works.
Unless that container already uses SLF4J (ahem: jetty) and the version
used by the containe
hossman wrote:
>
> ...
> There may be servlet containers that don't do a particularly good job of
> dealing with JUL (aka: JDK logging) but that is their deficiency, not
> Solr's.
>
That is a convincing argument, admittedly. But by using SLF4J, Solr won't
alienate users using such contain
: FWIW, Hoss, I don't think your main argument for JUL stands anymore (I finally
: got caught up on the archives). Namely, Solr is used in embedded situations
: much more now and it should no longer be assumed that it is in a standalone
: servlet completely isolated from the rest of the world. I
: > JULI can be configured per-webapp also by adding a logging.properties to the
: > classpath (add it to WEB-INF/classes). So you can configure Handlers
: JULI is a Tomcat thing
:
(http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/juli/package-summary.html
: ), right? In other words, it d
FWIW, Hoss, I don't think your main argument for JUL stands anymore
(I finally got caught up on the archives). Namely, Solr is used in
embedded situations much more now and it should no longer be assumed
that it is in a standalone servlet completely isolated from the rest
of the world.
On Apr 22, 2008, at 12:54 PM, Chris Hostetter wrote:
: I know logging is sometimes a religious debate, but would others
consider a
: patch that switched Solr to use log4j? Or, commons-logging? I
just don't
: think JUL is up to snuff when it comes to logging. It's a PITA to
configure,
:
On Apr 22, 2008, at 12:41 PM, Shalin Shekhar Mangar wrote:
JULI can be configured per-webapp also by adding a
logging.properties to the
classpath (add it to WEB-INF/classes). So you can configure Handlers
(FileHandler/ConsoleHandler including filenames) and Formatter per-
webapp.
However I'v
Actually, Tomcat does use commons in their code, at least that's what they
state here:
http://tomcat.apache.org/tomcat-6.0-doc/logging.html:
Tomcat 6.0 uses Commons Logging throughout its internal code.
They also state the core issue quite clearly:
> The default implemenatation of java.util.lo
I've no opinion on the respective merits of logging frameworks but not
having the choice causes deployment difficulties.
IMHO, the core issue is that JUL configuration is container dependant
(Tomcat JULI allows per-webapp logging.properties configuration, what about
Websphere ?), not application/
Hi!
Shalin Shekhar Mangar wrote:
Thomas, I don't understand why you say that JDK Logging is only on JVM
level. You can have as many different log files as you have Solr instances.
All you need to do it to put a logging properties inside Solr's
web-inf/classes. For example:
# Global Default loggi
I don't want to drag this on and on - I understand the point that solr
should stick with JDK logging because already uses it. I'll disagree
with anyone who says it is easy to hook up to log4j.
I fully support the addition of the trivial classes (what are we
talking, 10 lines of code or s
Thomas, I don't understand why you say that JDK Logging is only on JVM
level. You can have as many different log files as you have Solr instances.
All you need to do it to put a logging properties inside Solr's
web-inf/classes. For example:
# Global Default logging behavior
handlers= org.apache.jul
Let me clarify my stance here. JDK logging (aka JUL) is a logging
API, though it is not a full-featured logging implementation. One
would of course want some fuller featured logging APIs, but it is a
separation (of concerns) for Solr in a sense. Solr logs to JUL, and
the deployer of So
Erik Hatcher wrote:
I'm also opposed (sorry Grant) to tossing in a 3rd party library for
logging when the built-in logging facility is sufficient, configurable,
and adaptable already.
I must say I never liked JDK logging because it feels like a step back
when you are used to log4j.
So from
On Apr 22, 2008, at 1:52 PM, Erik Hatcher wrote:
On Apr 22, 2008, at 12:54 PM, Chris Hostetter wrote:
1) JDK logging is first and foremost an API, with a default
implementation. If people spent as much time writing
implementations of
that API as they do writing other logging frameworks, o
>If you mean "i have to write code to create a logging implementation" then
>yes ... that is true ... someone, somewhere, has to write an
?implementation of the JDK Logging API in order for you to use that
>implentation -- and if you don't like any of the other implentations out
>there, then yo
On Apr 22, 2008, at 1:06 PM, Chris Hostetter wrote:
: I'd be in favor seeing is how I spent a good bit of time 2 months
ago
: writing JUL handlers and log managers to forward log messages to
our logging
Have you considered contributing your LogManager and Handlers to
log4j so
other pe
On Apr 22, 2008, at 12:54 PM, Chris Hostetter wrote:
1) JDK logging is first and foremost an API, with a default
implementation. If people spent as much time writing
implementations of
that API as they do writing other logging frameworks, or tweaking
apps to
work with multiple frameworks
unless I'm missing something, solrj does not (at least should not) use
commons logging, but commons-httpclient does.
I have been in favor of moving to slf4j for a while:
http://www.nabble.com/logging---slf4j--td9366144.html
http://www.nabble.com/Changing-Logging-in-Solr-to-Apache-Commons-Loggin
+1
Thanks for the links Hoss, I personally wouldn't prefer to use a framework
for something built into Java itself. Infact, this discussion prompted me to
think about why Tomcat is not using commons-logging if it is such a great
thing.
On Tue, Apr 22, 2008 at 10:24 PM, Chris Hostetter <[EMAIL PRO
: I'd be in favor seeing is how I spent a good bit of time 2 months ago
: writing JUL handlers and log managers to forward log messages to our logging
Have you considered contributing your LogManager and Handlers to log4j so
other people can benefit from the work you've done?
: framework (log4j
: I know logging is sometimes a religious debate, but would others consider a
: patch that switched Solr to use log4j? Or, commons-logging? I just don't
: think JUL is up to snuff when it comes to logging. It's a PITA to configure,
: is not flexible, doesn't play nice with other logging systems
JULI can be configured per-webapp also by adding a logging.properties to the
classpath (add it to WEB-INF/classes). So you can configure Handlers
(FileHandler/ConsoleHandler including filenames) and Formatter per-webapp.
However I've never been able to configure it to rotate log files by size.
Alth
Cool. I'm almost done with a refactor to commons-logging. I will
post the patch soon.
And I totally agree on the sentiment of configuration vs. writing code
(I had to do the same thing as you) just to handle something like
logging.
On Apr 22, 2008, at 12:00 PM, Will Johnson wrote:
(p
(putting on flame suit)
I'd be in favor seeing is how I spent a good bit of time 2 months ago
writing JUL handlers and log managers to forward log messages to our logging
framework (log4j). Pretty much any alternative (Commons, Log4j, SLF4J) is
better since all of them allow you to _configure_ yo
Not too mention SolrJ uses commons-logging, so as it stands now Solr
uses two different logging mechanisms.
On Apr 22, 2008, at 11:47 AM, Grant Ingersoll wrote:
Anyone have good tips on working w/ java.util.logging (JUL)? For
one, the configuration seems to be per JVM, which isn't all that
58 matches
Mail list logo
