Re: Solr Logging
: 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 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 configure logging, any : "LogMessage" (or whatever JUL calls it -- LogRecord?) would in fact be : loaded by the system classloader. H i'm going to have to wrap my head arround this (and your other comments about how SLF4J works in [EMAIL PROTECTED]) later ... at the moment it seems just as scary to me: multiple implementations of the same class potentially loaded in the same JVM. But I'm willing to have a little faith and see how this goes. -Hoss
Re: contrib for solr
On Sat, May 3, 2008 at 11:30 AM, Noble Paul നോബിള് नोब्ळ् <[EMAIL PROTECTED]> wrote: > A case in point is DataImportHandler (SOLR-469). As per our discussion > with Grant Ingersoll, it makes a lot of sense to make this a contrib > project rather than adding it to the core codebase. I haven't had a chance to check out DataImportHandler, but adding it as a contrib module seems to make sense. > So we propose that we have a contrib area for Solr +1 -Yonik
Re: contrib for solr
On 3-May-08, at 9:27 PM, Noble Paul നോബിള് नोब्ळ् wrote: There is another class of patches like this RichDocumentRequestHandler (SOLR-284) which brings in dependencies on other libraries, which can safely live as a contrib project. Do we need to raise a jira issue to track this (contrib creation)? I think it would be nice for this to be a contrib that slurped in its dependencies using an ant task. This would preserve the benefit of shipping the handler with Solr while avoiding extraneous bloat to the core distribution. -Mike
Re: Solr Logging
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 configure logging, any "LogMessage" (or whatever JUL calls it -- LogRecord?) would in fact be loaded by the system classloader. http://svn.slf4j.org/viewvc/slf4j/trunk/slf4j-jdk14/src/main/java/org/slf4j/impl/JDK14LoggerAdapter.java?revision=994&view=markup Here's the source implementation of SLF4J's JDK14 logger. hossman wrote: > > : 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. > > we do in fact depend on third party libraries for soemthings, and yes it's > possible that those libraries might be version incompatible with libraries > already in use by the containing app (regardless of whether it's a servlet > container or something else) -- i have sweated over every one of those > decisions in the past because of potential conflicts. > > BUT! ... There are two (really) three key differneces here... > > 1) we currently have no dependencies (that i know of) that are "core" > dependencies -- ie: Solr won't work at all if there is a conflict. All of > our external dependencies right now are things that if there is a > conflict, that just means you may not be able to use an optional feature > (ie: remote ContentStreams if commons-http has a conflict, the > ShowFileHandler if commons-io has a conlfict, the PhoneticFilter if > commons-codec has a conflict) > > 2) Almost all of our existing use cases of third party code are very > isolated such that they are very unlikely to come into play when dealing > with parent context classloaders -- in an enviornment where logging is > centrally managed a "LogMessage" object is very likely > to get propogated up the tree out of the Solr context to the point where > class compatibility becomes an issue ... we don't exactly pass instances > of HttpClient arround in ways that the ServletContainer is likely to > encounter problems if they differ (multiple versions of a class can be > loaded the same JVM, you just don't ever want to "cross the streams" as > the ghost bsters use to say) > > > (The third differnce I see is in the idea of adding a depndency that > doesn't actually add a feature -- this is a philosophical argument, people > could say that "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.
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. we do in fact depend on third party libraries for soemthings, and yes it's possible that those libraries might be version incompatible with libraries already in use by the containing app (regardless of whether it's a servlet container or something else) -- i have sweated over every one of those decisions in the past because of potential conflicts. BUT! ... There are two (really) three key differneces here... 1) we currently have no dependencies (that i know of) that are "core" dependencies -- ie: Solr won't work at all if there is a conflict. All of our external dependencies right now are things that if there is a conflict, that just means you may not be able to use an optional feature (ie: remote ContentStreams if commons-http has a conflict, the ShowFileHandler if commons-io has a conlfict, the PhoneticFilter if commons-codec has a conflict) 2) Almost all of our existing use cases of third party code are very isolated such that they are very unlikely to come into play when dealing with parent context classloaders -- in an enviornment where logging is centrally managed a "LogMessage" object is very likely to get propogated up the tree out of the Solr context to the point where class compatibility becomes an issue ... we don't exactly pass instances of HttpClient arround in ways that the ServletContainer is likely to encounter problems if they differ (multiple versions of a class can be loaded the same JVM, you just don't ever want to "cross the streams" as the ghost bsters use to say) (The third differnce I see is in the idea of adding a depndency that doesn't actually add a feature -- this is a philosophical argument, people could say that "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
Re: Solr Logging
: 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
RE: Solr Logging
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
[jira] Resolved: (SOLR-562) Namedlistcodec throws NPE for null names
[ https://issues.apache.org/jira/browse/SOLR-562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley resolved SOLR-562. --- Resolution: Fixed Fix Version/s: 1.3 committed. > Namedlistcodec throws NPE for null names > > > Key: SOLR-562 > URL: https://issues.apache.org/jira/browse/SOLR-562 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Noble Paul >Priority: Trivial > Fix For: 1.3 > > Attachments: SOLR-562.patch > > > NPE thrown if a name in namedlist is null > SEVERE: java.lang.NullPointerException > at > org.apache.solr.common.util.NamedListCodec.writeStr(NamedListCodec.java:333) > at > org.apache.solr.common.util.NamedListCodec.writeNamedList(NamedListCodec.java:116) > at > org.apache.solr.common.util.NamedListCodec.marshal(NamedListCodec.java:77) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-562) Namedlistcodec throws NPE for null names
[ https://issues.apache.org/jira/browse/SOLR-562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-562: Attachment: SOLR-562.patch Fixed the NPE and made all methods public > Namedlistcodec throws NPE for null names > > > Key: SOLR-562 > URL: https://issues.apache.org/jira/browse/SOLR-562 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Noble Paul >Priority: Trivial > Attachments: SOLR-562.patch > > > NPE thrown if a name in namedlist is null > SEVERE: java.lang.NullPointerException > at > org.apache.solr.common.util.NamedListCodec.writeStr(NamedListCodec.java:333) > at > org.apache.solr.common.util.NamedListCodec.writeNamedList(NamedListCodec.java:116) > at > org.apache.solr.common.util.NamedListCodec.marshal(NamedListCodec.java:77) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-562) Namedlistcodec throws NPE for null names
Namedlistcodec throws NPE for null names Key: SOLR-562 URL: https://issues.apache.org/jira/browse/SOLR-562 Project: Solr Issue Type: Bug Affects Versions: 1.3 Reporter: Noble Paul Priority: Trivial NPE thrown if a name in namedlist is null SEVERE: java.lang.NullPointerException at org.apache.solr.common.util.NamedListCodec.writeStr(NamedListCodec.java:333) at org.apache.solr.common.util.NamedListCodec.writeNamedList(NamedListCodec.java:116) at org.apache.solr.common.util.NamedListCodec.marshal(NamedListCodec.java:77) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-537) Use hl.maxAlternateFieldLength parameter from solr-ruby
[ https://issues.apache.org/jira/browse/SOLR-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koji Sekiguchi updated SOLR-537: Attachment: SOLR-537.patch a new patch includes test cases. > Use hl.maxAlternateFieldLength parameter from solr-ruby > --- > > Key: SOLR-537 > URL: https://issues.apache.org/jira/browse/SOLR-537 > Project: Solr > Issue Type: Improvement > Components: clients - ruby - flare >Affects Versions: 1.3 >Reporter: Koji Sekiguchi >Priority: Trivial > Attachments: SOLR-537.patch, SOLR-537.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-560) Convert JDK logging to SLF4J
[ https://issues.apache.org/jira/browse/SOLR-560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12594211#action_12594211 ] patrick o'leary commented on SOLR-560: -- I'd suggest replacing logging.jsp 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 Type: Wish >Reporter: Ryan McKinley > Fix For: 1.3 > > Attachments: slf4j-api-1.5.0.jar, slf4j-jdk14-1.5.0.jar, > SOLR-560-slf4j.patch, SOLR-560-slf4j.patch > > > After lots of discussion, we should consider using SLF4j to enable more > flexibility in logging configuration. > See: > http://www.nabble.com/Solr-Logging-td16836646.html > http://www.nabble.com/logging-through-log4j-td13747253.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-561) Solr replication by Solr (for windows also)
Solr replication by Solr (for windows also) --- Key: SOLR-561 URL: https://issues.apache.org/jira/browse/SOLR-561 Project: Solr Issue Type: New Feature Components: replication Affects Versions: 1.3 Environment: All Reporter: Noble Paul Fix For: 1.3 The current replication strategy in solr involves shell scripts . The following are the drawbacks with the approach * It does not work with windows * Replication works as a separate piece not integrated with solr. * Cannot control replication from solr admin/JMX * Each operation requires manual telnet to the host Doing the replication in java has the following advantages * Platform independence * Manual steps can be completely eliminated. Everything can be driven from solrconfig.xml . ** Adding the url of the master in the slaves should be good enough to enable replication. Other things like frequency of snapshoot/snappull can also be configured . All other information can be automatically obtained. * Start/stop can be triggered from solr/admin or JMX * Can get the status/progress while replication is going on. It can also abort an ongoing replication * No need to have a login into the machine This issue can track the implementation of solr replication in java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
