: 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
uot;easier third party logging abstractin is a feature", but i
> disagree, and am willing to ignore that issue, but i mention it for
> completeness since I (and Erik) have brought it up before)
>
>
> -Hoss
>
>
>
--
View this message in context:
http://www.nabble.com/Solr-Logging-tp16836646p17068918.html
Sent from the Solr - Dev mailing list archive at Nabble.com.
: 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
t; : Any way, I think that logging APIs stabilize really fast by necessity --
> : nobody wants a fast changing logging API. I'd be really surprised to
> hear
> : of this sort of thing from any of the usual suspects going forward. I
> am
> : referring to the API w
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
I was particularly aware of,
>> but it does in fact make sense given it's intended usage as library for
>> use in other papplications. That doesn't mean Solr is using two
>> differnet
>> mechanisms, it means that Solr as an application is using the JDK Logging
>> API, and SolrJ as a library in use by Solr is using the commons-logging
>> API on top of that ... the underlying logging implementation is still up
>> to the end user running Solr in their servlet container.
>>
>>
>> -Hoss
>>
>>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
>
>
--
View this message in context:
http://www.nabble.com/Solr-Logging-tp16836646p17028232.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-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
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&#
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
[ ] 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 t
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
get
file/line in log4j which I find convenient in debug (see the event converter
code in solr-549).
My take is that a fully generic bridge needs to be a JDK LogManager...
--
View this message in context:
http://www.nabble.com/Solr-Logging-tp16836646p16993247.html
Sent from the Solr - Dev mailing list archive at Nabble.com.
is not a log manager of sort but merely a thin proxy (look at the
> code).
>
--
View this message in context:
http://www.nabble.com/Solr-Logging-tp16836646p16992281.html
Sent from the Solr - Dev mailing list archive at Nabble.com.
proxy (look at the
code).
--
View this message in context:
http://www.nabble.com/Solr-Logging-tp16836646p16986393.html
Sent from the Solr - Dev mailing list archive at Nabble.com.
mise that noone
> seems to seek...
>
>
--
View this message in context:
http://www.nabble.com/Solr-Logging-tp16836646p16982528.html
Sent from the Solr - Dev mailing list archive at Nabble.com.
oone
seems to seek...
--
View this message in context:
http://www.nabble.com/Solr-Logging-tp16836646p16976929.html
Sent from the Solr - Dev mailing list archive at Nabble.com.
>
> ryan
>
>
--
View this message in context:
http://www.nabble.com/Solr-Logging-tp16836646p16975198.html
Sent from the Solr - Dev mailing list archive at Nabble.com.
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
I might not care so much.
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.
~ David
--
View this message in context:
http://www.nabble.com/Solr-Logging-tp16836646p16973746.html
Sent from the Solr - Dev mailing list archive at Nabble.com.
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
erns about "other logging frameworks" & bridges is
related to JCL. If you had SLF4J in mind then please do "name names".
Respectfully,
David Smiley
--
View this message in context:
http://www.nabble.com/Solr-Logging-tp16836646p16972876.html
Sent from the Solr - Dev mailing list archive at Nabble.com.
: 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
y 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.
>
--
View this message in context:
http://www.nabble.com/Solr-Logging-tp16836646p16894713.html
Sent from the Solr - Dev mailing list archive at Nabble.com.
itching to another logging API
(slf4j rather than commons if we go that way).
--
View this message in context:
http://www.nabble.com/Solr-Logging-tp16836646p16847799.html
Sent from the Solr - Dev mailing list archive at Nabble.com.
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
configured
> > logger as JUL via whatever framework we end up going with
> >
> > - will
> >
> > -Original Message-
> > From: Grant Ingersoll [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, April 22, 2008 11:48 AM
> > To: solr-dev@
Ingersoll [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 22, 2008 11:48 AM
To: solr-dev@lucene.apache.org
Subject: Solr Logging
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 useful in
a webapp environment.
http://w
AIL PROTECTED]
Sent: Tuesday, April 22, 2008 11:48 AM
To: solr-dev@lucene.apache.org
Subject: Solr Logging
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 useful in
a webapp environment.
http://www.crazysq
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
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 useful in
a webapp environment. http://www.crazysquirrel.com/computing/java/logging.jspx
has some tips for Tomcat, but I am using Jetty. Not too mention, it
s
59 matches
Mail list logo
