> solrj DocumentObjectBinder prints to stdout rather than using slf4j
> ---
>
> Key: SOLR-1417
> URL: https://issues.apache.org/jira/browse/SOLR-1417
> Project: Solr
>
solrj DocumentObjectBinder prints to stdout rather than using slf4j
---
Key: SOLR-1417
URL: https://issues.apache.org/jira/browse/SOLR-1417
Project: Solr
Issue Type: Bug
[
https://issues.apache.org/jira/browse/SOLR-560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Ingersoll closed SOLR-560.
> Convert JDK logging to SLF4J
>
>
> K
Well, I'm not using Maven... I have added the API lib as a dependency to my
Eclipse project, only because I'm using an SLF4J logger now in my code. I've
also added the API and the SLF4J-Log4J bridge (that I had to get from the
SLF4J site) to my deployment so that I could deploy my a
If you are using maven you can simply add the following dependency to your
pom.xml:
org.slf4j
slf4j-simple
1.5.6
In addition to any solr / lucene packages you may need for your task
/www.lucidimagination.com
>
>
>
>
> Development Team wrote:
>
>> Hi everybody,
>> With Solr 1.4, when I try to *run* an app that uses SolrJ, it fails
>> with this exception:
>>
>> Exception in thread "Thread-4" java.lang.NoClassDefF
Solr 1.4, when I try to *run* an app that uses SolrJ, it fails
with this exception:
Exception in thread "Thread-4" java.lang.NoClassDefFoundError:
org/slf4j/LoggerFactory
at
org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.(CommonsHttpSolrServer.java:77)
I searched around
Hi everybody,
With Solr 1.4, when I try to *run* an app that uses SolrJ, it fails
with this exception:
Exception in thread "Thread-4" java.lang.NoClassDefFoundError:
org/slf4j/LoggerFactory
at
org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.(CommonsHttpSolrServer.java:7
all licenses. NOTICES needs to contain
notices, and not licenses. I don't think it needs to be duplicated.
> Convert JDK logging to SLF4J
>
>
> Key: SOLR-560
> URL: https://issues.apache.org/jira/browse/SOLR-560
>
LICENSE.txt? or should the
license in NOTICE.txt be removed?
http://svn.apache.org/viewvc/lucene/solr/trunk/NOTICE.txt?r1=696539&r2=696538&pathrev=696539
> Convert JDK logging to SLF4J
>
>
> Key: SOLR-560
>
See solr/lib/README.committers.txt
> Convert JDK logging to SLF4J
>
>
> Key: SOLR-560
> URL: https://issues.apache.org/jira/browse/SOLR-560
> Project: Solr
> Issue Type: Wish
>
es we can re-open it or make
a new issue
> Convert JDK logging to SLF4J
>
>
> Key: SOLR-560
> URL: https://issues.apache.org/jira/browse/SOLR-560
> Project: Solr
> Issue Type: Wish
>
mmit this soon...
+1
> Convert JDK logging to SLF4J
>
>
> Key: SOLR-560
> URL: https://issues.apache.org/jira/browse/SOLR-560
> Project: Solr
> Issue Type: Wish
>Reporter: Ryan Mc
without objection, i will commit SOLR-560 soon...
https://issues.apache.org/jira/browse/SOLR-560
ryan
like to commit this soon...
> Convert JDK logging to SLF4J
>
>
> Key: SOLR-560
> URL: https://issues.apache.org/jira/browse/SOLR-560
> Project: Solr
> Issue Type: Wish
>
On 5-Jun-08, at 6:42 PM, Ryan McKinley (JIRA) wrote:
Ryan McKinley commented on SOLR-560:
I removed this from the 1.3 list...
Hopefully we can add it just after the 1.3 release so we have plenty
of time to know if it is an ok choice.
Oh, thanks. I don
[
https://issues.apache.org/jira/browse/SOLR-560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-560:
---
Fix Version/s: (was: 1.3)
> Convert JDK logging to SL
y we can add it just after the 1.3 release so we have plenty of time to
know if it is an ok choice.
> Convert JDK logging to SLF4J
>
>
> Key: SOLR-560
> URL: https://issues.apache.org/jira/browse/SOLR-560
>
[
https://issues.apache.org/jira/browse/SOLR-560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Klaas reassigned SOLR-560:
---
Assignee: Ryan McKinley
It's Ryan's patch.
> Convert JDK log
Hymm, I guess folks aren't coming out of the woodwork to vote for this
one.
Wicket recently had a poll with ~100 votes cast:
http://www.nabble.com/Re%3A--vote--Release-1.4-with-only-generics-and-stop-support-for-1.3-p16220947.html
So I'm not sure where that leaves us. Unless Grant feels stron
(note: list change to solr-dev)
Giving the underwhelming response to this poll, it seems pretty clear to
me that the number of people who care one way or another about how Solr
does logging can probably be counted on one hand ... ok, maybe two hands.
-Hoss
ould apply the patch.
> Convert JDK logging to SLF4J
>
>
> Key: SOLR-560
> URL: https://issues.apache.org/jira/browse/SOLR-560
> Project: Solr
> Issue Type: Wish
>Reporter: Ry
slf4j
redirecting to log4j.
> Convert JDK logging to SLF4J
>
>
> Key: SOLR-560
> URL: https://issues.apache.org/jira/browse/SOLR-560
> Project: Solr
> Issue Type: Wish
>
?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12594603
#action_12594603 ]
Sean Timm commented on SOLR-560:
Thanks for taking a look at SOLR-554, Patrick.
I did test the log level selector with this SLF4J patch and it works
fine as is. It might be desirable to chang
test the log level selector with this SLF4J patch and it works fine as
is. It might be desirable to change the log level names in the log level
selector to match the names in SLF4J however.
>From the SLF4J FAQ:
"SLF4J is only a facade, meaning that it does not provide a complete loggi
with SOLR-554 might need to modify it
slightly for SLF4J.
> Convert JDK logging to SLF4J
>
>
> Key: SOLR-560
> URL: https://issues.apache.org/jira/browse/SOLR-560
> Project: Solr
> Issue Typ
does not handle logging.jsp yet...
> Convert JDK logging to SLF4J
>
>
> Key: SOLR-560
> URL: https://issues.apache.org/jira/browse/SOLR-560
> Project: Solr
> Issue Type: Wish
>
[
https://issues.apache.org/jira/browse/SOLR-560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12594136#action_12594136
]
Ryan McKinley commented on SOLR-560:
I attached a quick patch to convert to SLF4j
[
https://issues.apache.org/jira/browse/SOLR-560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-560:
---
Attachment: slf4j-api-1.5.0.jar
> Convert JDK logging to SL
[
https://issues.apache.org/jira/browse/SOLR-560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-560:
---
Attachment: slf4j-jdk14-1.5.0.jar
> Convert JDK logging to SL
[
https://issues.apache.org/jira/browse/SOLR-560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-560:
---
Attachment: SOLR-560-slf4j.patch
> Convert JDK logging to SL
Convert JDK logging to SLF4J
Key: SOLR-560
URL: https://issues.apache.org/jira/browse/SOLR-560
Project: Solr
Issue Type: Wish
Reporter: Ryan McKinley
Fix For: 1.3
After lots of
Configuring JUL to fit your needs *requires* that you get people in charge
of the container to cooperate.
If you can not, you are screwed no matter what.
Some of us are just not in a position to negotiate with them on this issue.
--
View this message in context:
http://www.nabble.com/logging-t
: Being able to override the default implementation fortunately allows to
: implement the must-have feature you describe as the "ClassLoader specific
: LogManagerManager", I agree; however, I think it should have been in the
: default implementation. I view this as a major regression from the prev
: And Jetty is what WE ship, not just me using it. By definition, the container
: that we ship for our examples doesn't do logging right. How would we expect
: anyone else to?
Jetty, in my opinion, doesn't do JUL logging wrong -- it just doesn't add
any bells and whistles. It defers to whatev
Erik Hatcher wrote:
>
> It seems to me Sun left it wide open for a thousand implementations
> to flourish, actually. What's to prevent a ClassLoader specific
> LogManagerManager from being put into the mix? Nothing - that's what
> JULI does.
>
Being able to override the default impleme
On Apr 30, 2008, at 12:50 PM, Henrib wrote:
the rant is on the containers not doing the
right thing by incorporating (something like) JULI.
Containers {w,sh}ould not have to invent specific and proprietary
if JDK
logging specified a way to define LogManager per class-loader;
imho, the
ran
Erik Hatcher wrote:
>
> JUL is the substrate that we (Java developers) should be logging to.
> Practically speaking, I'd like the world to look like this:
>App -> JUL -> Log4J adapter
>
Agreed.
Erik Hatcher wrote:
>
> the rant is on the containers not doing the
> right thing by incorpo
ledge it and deal with it.
bringing in another gorilla doesn't make the first one go away
funny, I see JUL as the gorilla I wish SOLR did not wake up. Nothing
else I have ever worked dared poke him ;)
I hoped SLF4J would let the the gorilla sleep peacefully along with
javax.swing and th
On Apr 29, 2008, at 8:00 PM, David Smiley @MITRE.org wrote:
2. If you're saying (from another message I responded to) that it's
the
container's job to handle the JUL configuration in a flexible
manner, then
wouldn't it be reasonable in this scenario to tell the container to
direct
JUL to w
But that's just it, hardly anything does use JUL. I can't for the
life of me think of a single project that does OTHER than Solr.
And Jetty is what WE ship, not just me using it. By definition, the
container that we ship for our examples doesn't do logging right. How
would we expect any
: 2. If you're saying (from another message I responded to) that it's the
: container's job to handle the JUL configuration in a flexible manner, then
: wouldn't it be reasonable in this scenario to tell the container to direct
: JUL to whatever it is I want (log4j in this scenario)?
: 3. You ment
hossman wrote:
>
> : a fan; but it's really not that important any way). Then, if someone
> (like
> : me :-) would like to configure logging with log4j then I am easily
> empowered
> : to do so by removing that jar and adding slf4j-log4j.jar. What I like
> about
&g
: a fan; but it's really not that important any way). Then, if someone (like
: me :-) would like to configure logging with log4j then I am easily empowered
: to do so by removing that jar and adding slf4j-log4j.jar. What I like about
This is the part of all the third party logging abstra
I agree, slf4j is a better solution; I was just trying to mitigate the
functional need (hooking log4j) & the strong (op)positions against changing
the logging API, thus the mildly disgusting solr-549 strawman. :-)
David Smiley @MITRE.org wrote:
>
> Whenever I see a project with
I do sympathize; it does seem wrong, but it's the norm in Java because Sun
screwed up Jdk14 logging. It's not a reflection of the design decisions of
Solr (i.e. your judgement) so please don't feel too bad accepting SLF4J.
~ David
Erik Hatcher wrote:
>
> My main p
Whenever I see a project with some home-grown LogManager that provides
loggers, I am always mildly disgusted no matter how simple it is (no
disrespect to you, that is my opinion). I believe use of SLF4J
will meet
common goals. Solr should log to SLFJ4J (slf4j-api.jar) and then
out-of-the-box
Whenever I see a project with some home-grown LogManager that provides
loggers, I am always mildly disgusted no matter how simple it is (no
disrespect to you, that is my opinion). I believe use of SLF4J will meet
common goals. Solr should log to SLFJ4J (slf4j-api.jar) and then
out-of-the-box
On 3/7/07, Chris Hostetter <[EMAIL PROTECTED]> wrote:
: Is there any interest in using slf4j (http://www.slf4j.org/) rather
: then forcing folks to use JDK logging?
i'd really rather now .. JDK logging is universal (at least in all JDK
versions Solr supports) and while i have no pro
: Is there any interest in using slf4j (http://www.slf4j.org/) rather
: then forcing folks to use JDK logging?
i'd really rather now .. JDK logging is universal (at least in all JDK
versions Solr supports) and while i have no problem adding dependencies
to SOlr if they allow for really
Well, it isn't quite that simple: entry.somethingThatTakesSomeTime()
will be executed in the example you provide. From what I've gleaned
by glancing at the site, it appears to be necessary to hide the calls
in the toString method of some object to delay the execution. Too bad
this isn't python
On 3/7/07, Ryan McKinley <[EMAIL PROTECTED]> wrote:
Is there any interest in using slf4j (http://www.slf4j.org/) rather
then forcing folks to use JDK logging?
The nice thing about slf4j is that user can easily switch the logger
implementation. The other nice thing is its use of m
Is there any interest in using slf4j (http://www.slf4j.org/) rather
then forcing folks to use JDK logging?
The nice thing about slf4j is that user can easily switch the logger
implementation. The other nice thing is its use of message formats.
This means you don't have to wrap stuff
53 matches
Mail list logo
