Build failed in Hudson: Solr-trunk #428
See http://hudson.zones.apache.org/hudson/job/Solr-trunk/428/changes -- started Building remotely on lucene.zones.apache.org ERROR: svn: PROPFIND request failed on '/repos/asf/lucene/solr/trunk' svn: Connection timed out org.tmatesoft.svn.core.SVNException: svn: PROPFIND request failed on '/repos/asf/lucene/solr/trunk' svn: Connection timed out at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:69) at org.tmatesoft.svn.core.internal.io.dav.DAVUtil.findStartingProperties(DAVUtil.java:126) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.fetchRepositoryUUID(DAVConnection.java:88) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.testConnection(DAVRepository.java:85) at hudson.scm.SubversionSCM$DescriptorImpl.checkRepositoryPath(SubversionSCM.java:1219) at hudson.scm.SubversionSCM.repositoryLocationsExist(SubversionSCM.java:1280) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:335) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:299) at hudson.model.AbstractProject.checkout(AbstractProject.java:566) at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:244) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:218) at hudson.model.Run.run(Run.java:749) at hudson.model.Build.run(Build.java:102) at hudson.model.ResourceController.execute(ResourceController.java:70) at hudson.model.Executor.run(Executor.java:71) Caused by: org.tmatesoft.svn.core.SVNException: svn: PROPFIND request failed on '/repos/asf/lucene/solr/trunk' svn: Connection timed out at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:55) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:40) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:529) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:237) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:225) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doPropfind(DAVConnection.java:97) at org.tmatesoft.svn.core.internal.io.dav.DAVUtil.getProperties(DAVUtil.java:57) at org.tmatesoft.svn.core.internal.io.dav.DAVUtil.getResourceProperties(DAVUtil.java:62) at org.tmatesoft.svn.core.internal.io.dav.DAVUtil.getStartingProperties(DAVUtil.java:92) at org.tmatesoft.svn.core.internal.io.dav.DAVUtil.findStartingProperties(DAVUtil.java:114) ... 13 more Publishing Javadoc Recording test results
[jira] Updated: (SOLR-556) Highlighting of multi-valued fields returns snippets which span multiple different values
[ https://issues.apache.org/jira/browse/SOLR-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Kotthoff updated SOLR-556: --- Attachment: solr-highlight-multivalued.patch Patch against SVN HEAD to treat multi valued fields like single valued fields when highlighting by looping over the field values and accumulating the highlighted snippets. This corrects the behaviour I've described and simplifies the code. The downside is that it may impose a performance penalty for large numbers of snippets. The code breaks out of the loop when enough snippets have been found without considering the other values of the fields, which means that the returned snippets may not be the best ones. > Highlighting of multi-valued fields returns snippets which span multiple > different values > - > > Key: SOLR-556 > URL: https://issues.apache.org/jira/browse/SOLR-556 > Project: Solr > Issue Type: Bug > Components: highlighter >Affects Versions: 1.3 > Environment: Tomcat 5.5 >Reporter: Lars Kotthoff >Priority: Minor > Attachments: solr-highlight-multivalued.patch > > > When highlighting multi-valued fields, the highlighter sometimes returns > snippets which span multiple values, e.g. with values "foo" and "bar" and > search term "ba" the highlighter will create the snippet "foobar". > Furthermore it sometimes returns smaller snippets than it should, e.g. with > value "foobar" and search term "oo" it will create the snippet "oo" > regardless of hl.fragsize. > I have been unable to determine the real cause for this, or indeed what > actually goes on at all. To reproduce the problem, I've used the following > steps: > * create an index with multi-valued fields, one document should have at least > 3 values for these fields (in my case strings of length between 5 and 15 > Japanese characters -- as far as I can tell plain old ASCII should produce > the same effect though) > * search for part of a value in such a field with highlighting enabled, the > additional parameters I use are hl.fragsize=70, hl.requireFieldMatch=true, > hl.mergeContiguous=true (changing the parameters does not seem to have any > effect on the result though) > * highlighted snippets should show effects described above -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-556) Highlighting of multi-valued fields returns snippets which span multiple different values
Highlighting of multi-valued fields returns snippets which span multiple different values - Key: SOLR-556 URL: https://issues.apache.org/jira/browse/SOLR-556 Project: Solr Issue Type: Bug Components: highlighter Affects Versions: 1.3 Environment: Tomcat 5.5 Reporter: Lars Kotthoff Priority: Minor When highlighting multi-valued fields, the highlighter sometimes returns snippets which span multiple values, e.g. with values "foo" and "bar" and search term "ba" the highlighter will create the snippet "foobar". Furthermore it sometimes returns smaller snippets than it should, e.g. with value "foobar" and search term "oo" it will create the snippet "oo" regardless of hl.fragsize. I have been unable to determine the real cause for this, or indeed what actually goes on at all. To reproduce the problem, I've used the following steps: * create an index with multi-valued fields, one document should have at least 3 values for these fields (in my case strings of length between 5 and 15 Japanese characters -- as far as I can tell plain old ASCII should produce the same effect though) * search for part of a value in such a field with highlighting enabled, the additional parameters I use are hl.fragsize=70, hl.requireFieldMatch=true, hl.mergeContiguous=true (changing the parameters does not seem to have any effect on the result though) * highlighted snippets should show effects described above -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
lucene 2.3.2
Solr seems happy with lucene 2.3.2, so I'll upgrade solr after it's released. -Yonik
Re: Solr Logging
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 build everything ourselves. The thing is, as Ryan has pointed out, many of us are not using Solr necessarily in a webapp, or at least not standalone as just solr.war and would like to have more control of logging w/o having to write a bunch of code to do it, when the answer is simply to include one 16k jar and change something like 100 lines of non-critical path code and we can have our choice of loggers, including JUL. One thing I am wondering, has anyone benchmarked the loggers? I'd be curious if there is any performance benefit to any one over another. On May 1, 2008, at 8:44 PM, Chris Hostetter wrote: 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 container has another version loaded -- especially in the case where webapps will likely be passing these objects up to code running in the Servlet Container context (for example: the "default" case of a centrally configured logging) This, by definition, cannot happen with JUL, because there is only one version of the j.u.l.* class files loaded by the JVM at anyone time. : 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's just embedded : with the JDK. Sun just hasn't updated it yet (if they did I am unaware; : simple searches suggest not). : : 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 where frameworks log to, not other parts which apps : tend not to write to. -Hoss -- Grant Ingersoll Lucene Helpful Hints: http://wiki.apache.org/lucene-java/BasicsOfPerformance http://wiki.apache.org/lucene-java/LuceneFAQ
Re: logging through log4j (or better yet, SLF4J)
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-through-log4j-tp13747253p1707.html Sent from the Solr - Dev mailing list archive at Nabble.com.
[jira] Updated: (SOLR-557) Add SolrCore.getSearchComponents()
[
https://issues.apache.org/jira/browse/SOLR-557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Ingersoll updated SOLR-557:
-
Priority: Minor (was: Major)
> Add SolrCore.getSearchComponents()
> --
>
> Key: SOLR-557
> URL: https://issues.apache.org/jira/browse/SOLR-557
> Project: Solr
> Issue Type: Improvement
>Reporter: Grant Ingersoll
>Assignee: Grant Ingersoll
>Priority: Minor
>
> Return an unmodifiable Map of the core's Search Components, similar to the
> request handlers.
> Code is:
> /**
>* Accessor for all the Search Components
>* @return An unmodifiable Map of Search Components
>*/
> public Map getSearchComponents() {
> return Collections.unmodifiableMap(searchComponents);
> }
> I will commit once SVN is up again.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-557) Add SolrCore.getSearchComponents()
Add SolrCore.getSearchComponents()
--
Key: SOLR-557
URL: https://issues.apache.org/jira/browse/SOLR-557
Project: Solr
Issue Type: Improvement
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Return an unmodifiable Map of the core's Search Components, similar to the
request handlers.
Code is:
/**
* Accessor for all the Search Components
* @return An unmodifiable Map of Search Components
*/
public Map getSearchComponents() {
return Collections.unmodifiableMap(searchComponents);
}
I will commit once SVN is up again.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Solr Logging
[ ] Keep solr logging as is. (JUL) [X] Convert solr logging to SLF4J
Re: Solr Logging
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 added dependancies SLF4J + Logging flexibility for folks using solr outside of the pre- canned solr.war + Enables logging configuration for folks who (for inflexible IT reasons) do not control their servlet container. (henri) - 16K additional library ryan
Re: Solr Logging
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...
Re: Solr Logging
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 stdlib is so bad that no-one uses it, that nevertheless seems to be the case. Though I'm following the discussion, I'm sticking out of the decision-making process. -Mike
Re: Solr Logging
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 logging implementation in the language's stdlib is so bad that no-one uses it, that nevertheless seems to be the case. Though I'm following the discussion, I'm sticking out of the decision-making process. For the record, we treat Solr as a stand-alone process, and interact with it via stderr and signals (log messages are scraped and fed back into our logging system). (off-topic-ly, this allows us to easily do things like: $ tcmd.py -a restart solr < shutdown 120 Solr servers across the cluster, wait for them to come back up and register, display any exceptions or timeouts > ) -Mike
[jira] Reopened: (SOLR-509) Event Listeners called before request handlers are informed of SolrCore
[ https://issues.apache.org/jira/browse/SOLR-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley reopened SOLR-509: --- Reopening... This patch introduced a bug that prevents the first searcher opened from ever being closed. I'm looking into a fix. > Event Listeners called before request handlers are informed of SolrCore > --- > > Key: SOLR-509 > URL: https://issues.apache.org/jira/browse/SOLR-509 > Project: Solr > Issue Type: Bug > Components: search >Reporter: Hoss Man >Assignee: Grant Ingersoll > Fix For: 1.3 > > Attachments: SOLR-509.patch, SOLR-509.patch > > > http://www.nabble.com/Nullpointer-when-using-QuerySenderListener-to16201207.html > Thijs noticed NullPointerException from SearchHandler on startup when trying > to configure some firstSearcher events using QuerySenderListener. > The problem is the events are getting triggered as soon as the firstSearcher > is opened, but the SOlrCore isn't finished being initialized, so > inform(SolrCore) hasn't been called on all the Handlers (and some handlers > aren't fully initialized and ready to process requests yet. > We need to more the firstSearcher event handling after inform has been called > on all SolrCoreAware objects. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-509) Event Listeners called before request handlers are informed of SolrCore
[ https://issues.apache.org/jira/browse/SOLR-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley updated SOLR-509: -- Attachment: SOLR-509-fix.patch This is one possible (untested) fix. I didn't test it because I'm looking into something that might be a bit better just stall the executor until later. > Event Listeners called before request handlers are informed of SolrCore > --- > > Key: SOLR-509 > URL: https://issues.apache.org/jira/browse/SOLR-509 > Project: Solr > Issue Type: Bug > Components: search >Reporter: Hoss Man >Assignee: Grant Ingersoll > Fix For: 1.3 > > Attachments: SOLR-509-fix.patch, SOLR-509.patch, SOLR-509.patch > > > http://www.nabble.com/Nullpointer-when-using-QuerySenderListener-to16201207.html > Thijs noticed NullPointerException from SearchHandler on startup when trying > to configure some firstSearcher events using QuerySenderListener. > The problem is the events are getting triggered as soon as the firstSearcher > is opened, but the SOlrCore isn't finished being initialized, so > inform(SolrCore) hasn't been called on all the Handlers (and some handlers > aren't fully initialized and ready to process requests yet. > We need to more the firstSearcher event handling after inform has been called > on all SolrCoreAware objects. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Solr Logging
[ ] 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.
Re: Solr Logging
> > [ ] 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.
Re: Solr Logging
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 Mangar wrote: > > +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 PROTECTED]> > 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, >> : is not flexible, doesn't play nice with other logging systems and, all >> in all, >> : just seems like crappy design by committee where the lowest common >> denominator >> : won out. >> >> I'm opposed to this. and I'vealready said everything i think needs to >> be said about the topic in this thread... >> >> >> http://www.nabble.com/Changing-Logging-in-Solr-to-Apache-Commons-Logging-to9728394.html >> >> ...I won't rehash all my points again, except to reiterate that: >> >> 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, the world would be a much better place. >> >> 2) If we do switch from something as universal as JDK logging to a >> differnet framework, then commons logging in particular is a really bad >> choice. It is not ment to be a "logging framework" used by applications, >> it exists to be an abstraction to protect small libraries from needing >> to worry about the logging framework choices of hte applications that use >> them. In the words of Rod Waldhoff... >> >> http://radio.weblogs.com/0122027/2003/08/15.html >> >> "In fact, there are very limited circumstances in which Commons >> Logging >> >> is useful. If you're building a stand-alone application, don't use >> >> commons-logging. If you're building an application server, don't use >> >> commons-logging. If you're building a moderately large framework, >> don't >> >> use commons-logging. If however, like the Jakarta Commons project, >> >> you're building a tiny little component that you intend for other >> >> developers to embed in their applications and frameworks, and you >> >> believe that logging information might be useful to those clients, and >> >> you can't be sure what logging framework they're going to want to use, >> >> then commons-logging might be useful to you. >> >> >> : Not too mention SolrJ uses commons-logging, so as it stands now Solr >> : uses two different logging mechanisms. >> >> SolrJ using commons logging isn't something 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.
[jira] Updated: (SOLR-509) Event Listeners called before request handlers are informed of SolrCore
[ https://issues.apache.org/jira/browse/SOLR-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley updated SOLR-509: -- Attachment: SOLR-509-fix.patch Here's the latest version, which restores firstSearcher event handling to getSearcher, and uses a latch to block any searcher warming events until the end of the SolrCore constructor. > Event Listeners called before request handlers are informed of SolrCore > --- > > Key: SOLR-509 > URL: https://issues.apache.org/jira/browse/SOLR-509 > Project: Solr > Issue Type: Bug > Components: search >Reporter: Hoss Man >Assignee: Grant Ingersoll > Fix For: 1.3 > > Attachments: SOLR-509-fix.patch, SOLR-509-fix.patch, SOLR-509.patch, > SOLR-509.patch > > > http://www.nabble.com/Nullpointer-when-using-QuerySenderListener-to16201207.html > Thijs noticed NullPointerException from SearchHandler on startup when trying > to configure some firstSearcher events using QuerySenderListener. > The problem is the events are getting triggered as soon as the firstSearcher > is opened, but the SOlrCore isn't finished being initialized, so > inform(SolrCore) hasn't been called on all the Handlers (and some handlers > aren't fully initialized and ready to process requests yet. > We need to more the firstSearcher event handling after inform has been called > on all SolrCoreAware objects. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-558) Open indexes in read-only mode to avoid corruption
Open indexes in read-only mode to avoid corruption -- Key: SOLR-558 URL: https://issues.apache.org/jira/browse/SOLR-558 Project: Solr Issue Type: New Feature Components: update Affects Versions: 1.3 Reporter: Lance Norskog Solr should allow using an index in read-only mode, so the application cannot possibly alter the index. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-509) Event Listeners called before request handlers are informed of SolrCore
[ https://issues.apache.org/jira/browse/SOLR-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12593960#action_12593960 ] Koji Sekiguchi commented on SOLR-509: - I confirmed the fix. I like the second patch (uses a latch version). Thanks Yonik to solve this problem! > Event Listeners called before request handlers are informed of SolrCore > --- > > Key: SOLR-509 > URL: https://issues.apache.org/jira/browse/SOLR-509 > Project: Solr > Issue Type: Bug > Components: search >Reporter: Hoss Man >Assignee: Grant Ingersoll > Fix For: 1.3 > > Attachments: SOLR-509-fix.patch, SOLR-509-fix.patch, SOLR-509.patch, > SOLR-509.patch > > > http://www.nabble.com/Nullpointer-when-using-QuerySenderListener-to16201207.html > Thijs noticed NullPointerException from SearchHandler on startup when trying > to configure some firstSearcher events using QuerySenderListener. > The problem is the events are getting triggered as soon as the firstSearcher > is opened, but the SOlrCore isn't finished being initialized, so > inform(SolrCore) hasn't been called on all the Handlers (and some handlers > aren't fully initialized and ready to process requests yet. > We need to more the firstSearcher event handling after inform has been called > on all SolrCoreAware objects. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Solr Logging
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 probably won't be online again for a few days... --- I was reading some interesting stuff about "controversy" in an OSS project called Pidgin. Based on what I read, the issue there is *vastly* different then the question of wether or not we should change the logging API used by Solr, but some of the comments I read did cause me to do a little "Soul Searching" on the topic of Developers and the user communities they (for lack of a better term) "serve". I started wondering if I was being overly dogmatic about logging and not respecting the "will of the community". I started to ask my self: what would it take for me to change my opinion on this issue from a "-1" to a "0" or "+1" ? The various objections I have to switching away from JUL (aka: JDK Logging) to anything else can be boil down to three main "themes" ... 1) JUL is "the right" API. 2) Making a major change like this could break logging for users that want to use JUL implementations as it was intended. 3) Reliance on a third party library for something as core as logging could expose us to class incompatibility issues. #1, although something I firmly believe, is admittedly subjective. If doing "the right thing" isn't what the community as a whole wants to do, then I just have to respectfully disagree with the community. This point alone basically garuntees that I'll never vote "+1" to switching away from JUL. #2 and #3 are admittedly hypothetical situations, but if either did arrise they would be *massive* failures of the Solr project, so we need to be dilligent to protect against those possibilities. 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), and community members are willing to extensive testing against the possibility of these problems (using a large set of different Servlet Containers), then I would be willing to withdraw my objection (ie: vote "0") ... I won't stop arguing that JUL is "the one true logging API" but I won't stand in the way of "progress" either. The caveat to this is that even if a good alternative logging "abstraction" exists, and we test it extensively, and have a high confidence that it will play nicely with JUL implementations, I would strongly suggest that we: a) Use it only if it's "default" behavior can be set to defer to the configured JUL LogManager (This is basicly "mandatory" in my opinion, since otherwise Solr won't be backwards compatible) b) Note in our documentation that Solr's usage of this abstraction is "experimental" and may be changed in future releases (If we encounter problems with it or decide there is some *better* abstraction) and that configuring a JUL LogManager is the recommended way to recieve logging messages from Solr. -Hoss
