[jira] Commented: (LUCENE-814) javacc on Win32 (cygwin) creates wrong line endings - fix them with 'ant replace'
[ https://issues.apache.org/jira/browse/LUCENE-814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476091 ] Hoss Man commented on LUCENE-814: - i *think* the right solution is to leave the .jj and .java files with svn:eol-style=native, then modify any target which regenerates a .java file from a.jj file to use without specifying either the "eol" or "cr" attributes ... the default of is to convert the file to the native format ... so it should synx up. ...but i haven't tested this (no access to windows/cygwin) so i'm not positive it works. if that doesn't work, the safest thing to do might be to set svn:eol-style=CRLF (or any other non variable value) for all of hte generated but commited .java files, and then modify the ant task that generates them to call on those files. (incidently: are you sure that if you do *everything* in cygwin -- both the checkout and running "ant javacc" -- you don't wind up with unix style line endings on all files?) > javacc on Win32 (cygwin) creates wrong line endings - fix them with 'ant > replace' > - > > Key: LUCENE-814 > URL: https://issues.apache.org/jira/browse/LUCENE-814 > Project: Lucene - Java > Issue Type: Task > Components: Build > Environment: Windows, Cygwin >Reporter: Doron Cohen > Assigned To: Doron Cohen >Priority: Minor > Fix For: 2.1 > > Attachments: 814.javacc.line.ends.patch > > > "ant javacc" in Windows/Cygwin generates files with wrong line endings (\r > or \r\n instead of *Nix's \n). > I managed to get rid of those usingperl -p -e 's/(\r\n|\n|\r)/\n/g' > Some useful info on line ending issues is in > http://en.wikipedia.org/wiki/Newline > After wasting some time to get rid of those, I modified javacc-QueryParser > build.xml task to take care of that. > So now QueryParser files created with "ant javacc" are fixed (if required) to > have \n as line ends. > Should probably do that also for the other javacc targets: javacc-HTMLParser > and javacc-StandardAnalyzer(?) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-551) Make Lucene - Java 1.9.1 Available in Maven2 repository in iBibilio.org
[ https://issues.apache.org/jira/browse/LUCENE-551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alastair Maw updated LUCENE-551: Only the 1.9.1 release is still broken: http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/lucene/lucene-core/1.9.1/ Note that the JAR is only 2.3Kb. > Make Lucene - Java 1.9.1 Available in Maven2 repository in iBibilio.org > --- > > Key: LUCENE-551 > URL: https://issues.apache.org/jira/browse/LUCENE-551 > Project: Lucene - Java > Issue Type: Task >Affects Versions: 1.9 >Reporter: Stephen Duncan Jr > > Please upload 1.9.1 release to iBiblio so that Maven users can easily use the > latest release. Currently 1.4.3 is the most recently available version: > http://www.ibiblio.org/maven2/lucene/lucene/ > Please read the following FAQ for more information: > http://maven.apache.org/project-faq.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (LUCENE-811) Public API inconsistency
[ https://issues.apache.org/jira/browse/LUCENE-811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-811. --- Resolution: Fixed Fix Version/s: 2.2 This is resolved. If we do a 2.1.1 then I will backport to the 2.1 branch at that time. > Public API inconsistency > > > Key: LUCENE-811 > URL: https://issues.apache.org/jira/browse/LUCENE-811 > Project: Lucene - Java > Issue Type: Bug > Components: Index >Affects Versions: 2.1 > Environment: 2.1.0 release >Reporter: Andrzej Bialecki > Assigned To: Michael McCandless >Priority: Minor > Fix For: 2.2 > > Attachments: LUCENE-811-take2.patch, LUCENE-811.patch > > > org.apache.lucene.index.SegmentInfos is public, and contains public methods > (which is good for expert-level index manipulation tools such as Luke). > However, SegmentInfo class has package visibility. This leads to a strange > result that it's possible to read SegmentInfos, but it's not possible to > access its details (SegmentInfos.info(int)) from a user application. > The solution is to make SegmentInfo class public. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
making 2.1 a "Released Version" in JIRA?
I noticed in JIRA that "2.1" is still listed under "Unreleased Versions". I think it's simple to fix; we just have to "Release" it on the Administration page for project Lucene: http://issues.apache.org/jira/secure/project/ManageVersions.jspa?pid=12310110 So I started down this path, but, it then prompts that there are these 4 issues that were marked with fix version 2.1 but in fact did not get fixed: http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&pid=12310110&fixfor=12310854&resolution=-1 The issues are LUCENE-814, LUCENE-796, LUCENE-510 and LUCENE-372. Are there any objections to bumping the fix versions of these to 2.2? (I can also choose to "ignore" the 4 issues but I think we should move to 2.2 instead). Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (LUCENE-819) NullPointerException in Term.compareTo()
NullPointerException in Term.compareTo() Key: LUCENE-819 URL: https://issues.apache.org/jira/browse/LUCENE-819 Project: Lucene - Java Issue Type: Bug Components: Index Environment: JDK 1.4 on MacOS Reporter: Dan Zivkovic java.lang.NullPointerException at org.apache.lucene.index.Term.compareTo(Term.java:84) at org.apache.lucene.index.TermInfosReader.getIndexOffset(TermInfosReader.java:115) at org.apache.lucene.index.TermInfosReader.get(TermInfosReader.java:150) at org.apache.lucene.index.SegmentReader.docFreq(SegmentReader.java:300) at org.apache.lucene.search.IndexSearcher.docFreq(IndexSearcher.java:78) at org.apache.lucene.search.Similarity.idf(Similarity.java:255) at org.apache.lucene.search.TermQuery$TermWeight.(TermQuery.java:43) at org.apache.lucene.search.TermQuery.createWeight(TermQuery.java:142) at org.apache.lucene.search.BooleanQuery$BooleanWeight.(BooleanQuery.java:203) at org.apache.lucene.search.BooleanQuery$BooleanWeight2.(BooleanQuery.java:330) at org.apache.lucene.search.BooleanQuery.createWeight(BooleanQuery.java:372) at org.apache.lucene.search.Query.weight(Query.java:93) at org.apache.lucene.search.Hits.(Hits.java:48) at org.apache.lucene.search.Searcher.search(Searcher.java:53) ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-819) NullPointerException in Term.compareTo()
[ https://issues.apache.org/jira/browse/LUCENE-819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Zivkovic updated LUCENE-819: Attachment: lucene-819.patch This is an "svn diff" describing the fix for bug #819. > NullPointerException in Term.compareTo() > > > Key: LUCENE-819 > URL: https://issues.apache.org/jira/browse/LUCENE-819 > Project: Lucene - Java > Issue Type: Bug > Components: Index > Environment: JDK 1.4 on MacOS >Reporter: Dan Zivkovic > Attachments: lucene-819.patch > > > java.lang.NullPointerException > at org.apache.lucene.index.Term.compareTo(Term.java:84) > at > org.apache.lucene.index.TermInfosReader.getIndexOffset(TermInfosReader.java:115) > at org.apache.lucene.index.TermInfosReader.get(TermInfosReader.java:150) > at org.apache.lucene.index.SegmentReader.docFreq(SegmentReader.java:300) > at org.apache.lucene.search.IndexSearcher.docFreq(IndexSearcher.java:78) > at org.apache.lucene.search.Similarity.idf(Similarity.java:255) > at > org.apache.lucene.search.TermQuery$TermWeight.(TermQuery.java:43) > at org.apache.lucene.search.TermQuery.createWeight(TermQuery.java:142) > at > org.apache.lucene.search.BooleanQuery$BooleanWeight.(BooleanQuery.java:203) > at > org.apache.lucene.search.BooleanQuery$BooleanWeight2.(BooleanQuery.java:330) > at > org.apache.lucene.search.BooleanQuery.createWeight(BooleanQuery.java:372) > at org.apache.lucene.search.Query.weight(Query.java:93) > at org.apache.lucene.search.Hits.(Hits.java:48) > at org.apache.lucene.search.Searcher.search(Searcher.java:53) > ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: making 2.1 a "Released Version" in JIRA?
On 2/27/07, Michael McCandless <[EMAIL PROTECTED]> wrote: The issues are LUCENE-814, LUCENE-796, LUCENE-510 and LUCENE-372. Are there any objections to bumping the fix versions of these to 2.2? (I can also choose to "ignore" the 4 issues but I think we should move to 2.2 instead). Sounds fine. Thanks for looking into this... I forgot about bumping the JIRA version. -Yonik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-796) Change Visibility of fields[] in MultiFieldQueryParser
[ https://issues.apache.org/jira/browse/LUCENE-796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-796: -- Fix Version/s: (was: 2.1) 2.2 > Change Visibility of fields[] in MultiFieldQueryParser > -- > > Key: LUCENE-796 > URL: https://issues.apache.org/jira/browse/LUCENE-796 > Project: Lucene - Java > Issue Type: Improvement > Components: QueryParser >Affects Versions: 2.1 > Environment: not important >Reporter: Oliver Hummel > Fix For: 2.2 > > > In MultiFieldQueryParser the two methods > protected Query getFuzzyQuery(String field, String termStr, float > minSimilarity) throws ParseException > protected Query getWildcardQuery(String field, String termStr) throws > ParseException > are intended to be overwritten if one would like to avoid fuzzy and wildcard > queries. However, the String[] fields attribute of this class is private and > hence it is not accessible in subclasses of MFQParser. If you just change it > to protected this issue should be solved. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-814) javacc on Win32 (cygwin) creates wrong line endings - fix them with 'ant replace'
[ https://issues.apache.org/jira/browse/LUCENE-814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-814: -- Fix Version/s: (was: 2.1) 2.2 > javacc on Win32 (cygwin) creates wrong line endings - fix them with 'ant > replace' > - > > Key: LUCENE-814 > URL: https://issues.apache.org/jira/browse/LUCENE-814 > Project: Lucene - Java > Issue Type: Task > Components: Build > Environment: Windows, Cygwin >Reporter: Doron Cohen > Assigned To: Doron Cohen >Priority: Minor > Fix For: 2.2 > > Attachments: 814.javacc.line.ends.patch > > > "ant javacc" in Windows/Cygwin generates files with wrong line endings (\r > or \r\n instead of *Nix's \n). > I managed to get rid of those usingperl -p -e 's/(\r\n|\n|\r)/\n/g' > Some useful info on line ending issues is in > http://en.wikipedia.org/wiki/Newline > After wasting some time to get rid of those, I modified javacc-QueryParser > build.xml task to take care of that. > So now QueryParser files created with "ant javacc" are fixed (if required) to > have \n as line ends. > Should probably do that also for the other javacc targets: javacc-HTMLParser > and javacc-StandardAnalyzer(?) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-510) IndexOutput.writeString() should write length in bytes
[ https://issues.apache.org/jira/browse/LUCENE-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-510: -- Fix Version/s: (was: 2.1) 2.2 > IndexOutput.writeString() should write length in bytes > -- > > Key: LUCENE-510 > URL: https://issues.apache.org/jira/browse/LUCENE-510 > Project: Lucene - Java > Issue Type: Improvement > Components: Store >Affects Versions: 2.1 >Reporter: Doug Cutting > Assigned To: Grant Ingersoll > Fix For: 2.2 > > Attachments: SortExternal.java, strings.diff, TestSortExternal.java > > > We should change the format of strings written to indexes so that the length > of the string is in bytes, not Java characters. This issue has been > discussed at: > http://www.mail-archive.com/java-dev@lucene.apache.org/msg01970.html > We must increment the file format number to indicate this change. At least > the format number in the segments file should change. > I'm targetting this for 2.1, i.e., we shouldn't commit it to trunk until > after 2.0 is released, to minimize incompatible changes between 1.9 and 2.0 > (other than removal of deprecated features). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-372) Unmatched right parentheses truncates query
[ https://issues.apache.org/jira/browse/LUCENE-372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-372: -- Fix Version/s: (was: 2.1) 2.2 > Unmatched right parentheses truncates query > --- > > Key: LUCENE-372 > URL: https://issues.apache.org/jira/browse/LUCENE-372 > Project: Lucene - Java > Issue Type: Bug > Components: QueryParser >Affects Versions: 1.4, 1.9, 2.0.0, 2.0.1, 2.1 > Environment: Operating System: Linux > Platform: PC >Reporter: Patrick Hochstenbach > Assigned To: Michael Busch >Priority: Minor > Fix For: 2.2 > > Attachments: Lucene-372.patch, LUCENE-372.patch.txt > > > The query processor truncates a query when right parentheses are unmatched. > E.g.: > secret AND illegal) AND access:confidential > will not result in a ParseException instead will run as: > secret AND illegal -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: making 2.1 a "Released Version" in JIRA?
"Yonik Seeley" <[EMAIL PROTECTED]> wrote: > On 2/27/07, Michael McCandless <[EMAIL PROTECTED]> wrote: > > The issues are LUCENE-814, LUCENE-796, LUCENE-510 and LUCENE-372. > > > > Are there any objections to bumping the fix versions of these to 2.2? > > (I can also choose to "ignore" the 4 issues but I think we should move > > to 2.2 instead). > > Sounds fine. > Thanks for looking into this... I forgot about bumping the JIRA version. No problem! OK, all done. I will also edit the ReleaseTodo wiki page to add this step in. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: making 2.1 a "Released Version" in JIRA?
Is the idea that resolved issues are also closed at release? -Original Message- From: Michael McCandless [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 27, 2007 9:01 AM To: java-dev@lucene.apache.org Subject: Re: making 2.1 a "Released Version" in JIRA? "Yonik Seeley" <[EMAIL PROTECTED]> wrote: > On 2/27/07, Michael McCandless <[EMAIL PROTECTED]> wrote: > > The issues are LUCENE-814, LUCENE-796, LUCENE-510 and LUCENE-372. > > > > Are there any objections to bumping the fix versions of these to 2.2? > > (I can also choose to "ignore" the 4 issues but I think we should move > > to 2.2 instead). > > Sounds fine. > Thanks for looking into this... I forgot about bumping the JIRA version. No problem! OK, all done. I will also edit the ReleaseTodo wiki page to add this step in. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-818) IndexWriter should detect when it's used after being closed
[ https://issues.apache.org/jira/browse/LUCENE-818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476240 ] Grant Ingersoll commented on LUCENE-818: FWIW: Some of the other Readers (actually, IndexInput) are undefined when invoking after close. I ran into this w/ the FieldsReader when working on lazy loading. See http://www.gossamer-threads.com/lists/lucene/java-dev/34109?search_string=lazy%20field%20loading;#34109 for reference. > IndexWriter should detect when it's used after being closed > --- > > Key: LUCENE-818 > URL: https://issues.apache.org/jira/browse/LUCENE-818 > Project: Lucene - Java > Issue Type: Bug > Components: Index >Affects Versions: 2.1 >Reporter: Michael McCandless > Assigned To: Michael McCandless >Priority: Minor > > Spinoff from this thread on java-user: > http://www.gossamer-threads.com/lists/lucene/java-user/45986 > If you call addDocument on IndexWriter after it's closed you'll hit a > hard-to-explain NullPointerException (because the RAMDirectory was > closed). Before 2.1, apparently you won't hit any exception and the > IndexWrite will keep running but will have released it's write lock (I > think). > I plan to fix IndexWriter methods to throw an IllegalStateException if > it has been closed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: making 2.1 a "Released Version" in JIRA?
"Steven Parkes" <[EMAIL PROTECTED]> wrote: > Is the idea that resolved issues are also closed at release? Good point, I think that is right? I think this means getting all issues with Status=Resolved and "Fix For"=2.1 (I see 41 such issues) and then doing a bulk-change to close them? Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: making 2.1 a "Released Version" in JIRA?
Michael McCandless wrote: "Steven Parkes" <[EMAIL PROTECTED]> wrote: Is the idea that resolved issues are also closed at release? Good point, I think that is right? Yes, that is the convention I use. Doug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: making 2.1 a "Released Version" in JIRA?
Michael McCandless wrote: "Steven Parkes" <[EMAIL PROTECTED]> wrote: Is the idea that resolved issues are also closed at release? Good point, I think that is right? Also, this is, to my mind, the motivating case for Jira's bulk edit feature, and in particular, its option to inhibit the sending of emails. No one is interested in 40 messages, each about a resolved issue that's been closed. Doug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: making 2.1 a "Released Version" in JIRA?
"Doug Cutting" <[EMAIL PROTECTED]> wrote: > Michael McCandless wrote: > > "Steven Parkes" <[EMAIL PROTECTED]> wrote: > >> Is the idea that resolved issues are also closed at release? > > > > Good point, I think that is right? > > Yes, that is the convention I use. OK I will go make that bulk change. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-819) NullPointerException in Term.compareTo()
[ https://issues.apache.org/jira/browse/LUCENE-819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476312 ] Steven Parkes commented on LUCENE-819: -- H ... this patch makes Term#compareTo support Terms with null text. I don't think Lucene is supposed to support null terms. This is mentioned in LIA. Is it anywhere in the docs? Should we document that neither fld nor txt of a Term constructor may be null? Would we actually want to check and throw an exception? If this is right, this should be resolved as a won't fix. > NullPointerException in Term.compareTo() > > > Key: LUCENE-819 > URL: https://issues.apache.org/jira/browse/LUCENE-819 > Project: Lucene - Java > Issue Type: Bug > Components: Index > Environment: JDK 1.4 on MacOS >Reporter: Dan Zivkovic > Attachments: lucene-819.patch > > > java.lang.NullPointerException > at org.apache.lucene.index.Term.compareTo(Term.java:84) > at > org.apache.lucene.index.TermInfosReader.getIndexOffset(TermInfosReader.java:115) > at org.apache.lucene.index.TermInfosReader.get(TermInfosReader.java:150) > at org.apache.lucene.index.SegmentReader.docFreq(SegmentReader.java:300) > at org.apache.lucene.search.IndexSearcher.docFreq(IndexSearcher.java:78) > at org.apache.lucene.search.Similarity.idf(Similarity.java:255) > at > org.apache.lucene.search.TermQuery$TermWeight.(TermQuery.java:43) > at org.apache.lucene.search.TermQuery.createWeight(TermQuery.java:142) > at > org.apache.lucene.search.BooleanQuery$BooleanWeight.(BooleanQuery.java:203) > at > org.apache.lucene.search.BooleanQuery$BooleanWeight2.(BooleanQuery.java:330) > at > org.apache.lucene.search.BooleanQuery.createWeight(BooleanQuery.java:372) > at org.apache.lucene.search.Query.weight(Query.java:93) > at org.apache.lucene.search.Hits.(Hits.java:48) > at org.apache.lucene.search.Searcher.search(Searcher.java:53) > ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-819) NullPointerException in Term.compareTo()
[ https://issues.apache.org/jira/browse/LUCENE-819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476315 ] Hoss Man commented on LUCENE-819: - Dan: can you elaborate on how you encountered this NPE? ... Terms shouldn't typically have null "text" (I'm trying to understand if you were doing something "Expertish" when this error happened, and modifying compareTo is all that needs to be considered, or if some other code in the core library produced a Term with a null value for text and we need to identify and fix that as well) > NullPointerException in Term.compareTo() > > > Key: LUCENE-819 > URL: https://issues.apache.org/jira/browse/LUCENE-819 > Project: Lucene - Java > Issue Type: Bug > Components: Index > Environment: JDK 1.4 on MacOS >Reporter: Dan Zivkovic > Attachments: lucene-819.patch > > > java.lang.NullPointerException > at org.apache.lucene.index.Term.compareTo(Term.java:84) > at > org.apache.lucene.index.TermInfosReader.getIndexOffset(TermInfosReader.java:115) > at org.apache.lucene.index.TermInfosReader.get(TermInfosReader.java:150) > at org.apache.lucene.index.SegmentReader.docFreq(SegmentReader.java:300) > at org.apache.lucene.search.IndexSearcher.docFreq(IndexSearcher.java:78) > at org.apache.lucene.search.Similarity.idf(Similarity.java:255) > at > org.apache.lucene.search.TermQuery$TermWeight.(TermQuery.java:43) > at org.apache.lucene.search.TermQuery.createWeight(TermQuery.java:142) > at > org.apache.lucene.search.BooleanQuery$BooleanWeight.(BooleanQuery.java:203) > at > org.apache.lucene.search.BooleanQuery$BooleanWeight2.(BooleanQuery.java:330) > at > org.apache.lucene.search.BooleanQuery.createWeight(BooleanQuery.java:372) > at org.apache.lucene.search.Query.weight(Query.java:93) > at org.apache.lucene.search.Hits.(Hits.java:48) > at org.apache.lucene.search.Searcher.search(Searcher.java:53) > ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (LUCENE-813) leading wildcard's don't work with trailing wildcard
[ https://issues.apache.org/jira/browse/LUCENE-813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Doron Cohen resolved LUCENE-813. Resolution: Fixed Fix Version/s: 2.2 Lucene Fields: [Patch Available] (was: [Patch Available, New]) Thanks for reviewing this Michael! Commited, with few additional wildcard queries in TestWildcard..testParsingAndSearching(). > leading wildcard's don't work with trailing wildcard > > > Key: LUCENE-813 > URL: https://issues.apache.org/jira/browse/LUCENE-813 > Project: Lucene - Java > Issue Type: Bug >Reporter: Hoss Man > Assigned To: Doron Cohen > Fix For: 2.2 > > Attachments: 813.fix.lead.wildcard.patch, qp-leading-wildcard.patch > > > As reported by Antony Bowesman, leading wildcards don't work when there is a > trailing wildcard character -- instead a PrefixQuery is constructed. > http://www.nabble.com/QueryParser-bug--tf3270956.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-818) IndexWriter should detect when it's used after being closed
[ https://issues.apache.org/jira/browse/LUCENE-818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476360 ] Michael McCandless commented on LUCENE-818: --- I see, so IndexInput indeed does not track isClosed. It's not easy to fix that since IndexInput is public and non-final? Though I'm actually less concerned about this one because it's very "internal" to Lucene. I'm more concerned about the public paths (IndexWriter, IndexReader). Users seem to accidentally close these classes fairly often. I think IndexSearcher is OK because on close it at worst closes the underlying IndexReader, and then any call to that IndexReader will catch that it's closed. Oh, I see: this public path will indeed access IndexInput after it's been closed: Open reader Get a doc w/ lazy field(s) Close reader Try to get the lazy field's value That last step will clone the cloneableFieldsStream after it had been closed. Hmmm. Though I think we could just fix this path in FieldsReader by having it record when it's closed & throw an AlreadyClosedException if the LazyField class is used after that? That seems like the simplest fix. > IndexWriter should detect when it's used after being closed > --- > > Key: LUCENE-818 > URL: https://issues.apache.org/jira/browse/LUCENE-818 > Project: Lucene - Java > Issue Type: Bug > Components: Index >Affects Versions: 2.1 >Reporter: Michael McCandless > Assigned To: Michael McCandless >Priority: Minor > > Spinoff from this thread on java-user: > http://www.gossamer-threads.com/lists/lucene/java-user/45986 > If you call addDocument on IndexWriter after it's closed you'll hit a > hard-to-explain NullPointerException (because the RAMDirectory was > closed). Before 2.1, apparently you won't hit any exception and the > IndexWrite will keep running but will have released it's write lock (I > think). > I plan to fix IndexWriter methods to throw an IllegalStateException if > it has been closed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-818) IndexWriter should detect when it's used after being closed
[ https://issues.apache.org/jira/browse/LUCENE-818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476373 ] Steven Parkes commented on LUCENE-818: -- Shades of LUCENE-686. It'd be nice to agree on that one, too (though it's internal, not external). > IndexWriter should detect when it's used after being closed > --- > > Key: LUCENE-818 > URL: https://issues.apache.org/jira/browse/LUCENE-818 > Project: Lucene - Java > Issue Type: Bug > Components: Index >Affects Versions: 2.1 >Reporter: Michael McCandless > Assigned To: Michael McCandless >Priority: Minor > > Spinoff from this thread on java-user: > http://www.gossamer-threads.com/lists/lucene/java-user/45986 > If you call addDocument on IndexWriter after it's closed you'll hit a > hard-to-explain NullPointerException (because the RAMDirectory was > closed). Before 2.1, apparently you won't hit any exception and the > IndexWrite will keep running but will have released it's write lock (I > think). > I plan to fix IndexWriter methods to throw an IllegalStateException if > it has been closed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-818) IndexWriter should detect when it's used after being closed
[ https://issues.apache.org/jira/browse/LUCENE-818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476386 ] Michael McCandless commented on LUCENE-818: --- I'm planning on adding o.a.l.store.AlreadyClosedException. But, I'm back to subclassing this from IllegalStateException (not IOException). There are a fair number of methods where we should throw this exception but IOException was not already in the throws clause. Also, since it's rather rare, I think subclassing an unchecked Exception is appropriate. The only counter argument is IndexReader which currently throws IOException if it has been closed but then acquireWriteLock is called (for one of the "writer" methods). So this would technically be an API change for this particular case in IndexReader. But I think it's a tiny API change especially because it does not affect user's code since they already must catch the existing IOException (vs the other methods where adding checked "throws IOException" would be a major API change). > IndexWriter should detect when it's used after being closed > --- > > Key: LUCENE-818 > URL: https://issues.apache.org/jira/browse/LUCENE-818 > Project: Lucene - Java > Issue Type: Bug > Components: Index >Affects Versions: 2.1 >Reporter: Michael McCandless > Assigned To: Michael McCandless >Priority: Minor > > Spinoff from this thread on java-user: > http://www.gossamer-threads.com/lists/lucene/java-user/45986 > If you call addDocument on IndexWriter after it's closed you'll hit a > hard-to-explain NullPointerException (because the RAMDirectory was > closed). Before 2.1, apparently you won't hit any exception and the > IndexWrite will keep running but will have released it's write lock (I > think). > I plan to fix IndexWriter methods to throw an IllegalStateException if > it has been closed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (LUCENE-812) Unable to set LockFactory implementation via ${org.apache.lucene.store.FSDirectoryLockFactoryClass}
[
https://issues.apache.org/jira/browse/LUCENE-812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless resolved LUCENE-812.
---
Resolution: Fixed
Fix Version/s: 2.2
> Unable to set LockFactory implementation via
> ${org.apache.lucene.store.FSDirectoryLockFactoryClass}
> ---
>
> Key: LUCENE-812
> URL: https://issues.apache.org/jira/browse/LUCENE-812
> Project: Lucene - Java
> Issue Type: Bug
> Components: Store
>Affects Versions: 2.1
>Reporter: Matthias Kerkhoff
> Assigned To: Michael McCandless
> Fix For: 2.2
>
> Attachments: LUCENE-812.patch
>
>
> While trying to move from Lucene 2.0 to Lucene 2.1 I noticed a problem with
> the LockFactory instantiation code.
> During previous tests we successfully specified the LockFactory
> implementation by setting the property
> ${org.apache.lucene.store.FSDirectoryLockFactoryClass} to
> "org.apache.lucene.store.NativeFSLockFactory".
> This does no longer work due to a bug in the FSDirectory class. The problem
> is caused from the fact that this
> class tries to invoke the default constructor of the specified LockFactory
> class. However neither NativeFSLockFactory
> nor SimpleFSLockFactory do have a default constructor.
> FSDirectory, Line 285:
> try {
> lockFactory = (LockFactory) c.newInstance();
> } catch (IllegalAccessException e) {
> throw new IOException("IllegalAccessException when instantiating
> LockClass " + lockClassName);
> } catch (InstantiationException e) {
> throw new IOException("InstantiationException when instantiating
> LockClass " + lockClassName);
> } catch (ClassCastException e) {
> throw new IOException("unable to cast LockClass " + lockClassName
> + " instance to a LockFactory");
> }
> A possible workaround is to not set the property at all and call
> FSDirectory.setLockFactory(...) instead.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
FieldCache documentation/exposure
Hi, I am wondering about the exposure (or not) of FieldCache in the documentation. FieldCache is used by Lucene, internally, for sort purposes. Being an interface, it is also exposed as public API, but there seems to be no pointers/documentation suggesting to use it. Well, except for a brief mentioning in the FAQ entry "The search is slow when there are many hits". An application, could however, too, use that caching capability for, say, accessing a stored (external) ID field. See for instance this recent discussion in the user list - http://www.nabble.com/Best-way-to-returning-hits-after-search--tf3304485.html The application could access the cache e.g. like this - FieldCache fieldCache = FieldCache.DEFAULT; String f[] = fieldCache.getStrings(ir,fieldname); After posting a reply for that in the user list I thought about clarifying about this possible use - so application developers don't have to go and write their own cache for this, because Lucene already has that. Guess I wasn't sure if this is just a place where documentation can be improved (and junit tests added), or the FieldCache is for some reason considered an internal implementation detail that applications should not rely on. Thoughts? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-794) Beginnings of a span based highlighter
[ https://issues.apache.org/jira/browse/LUCENE-794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated LUCENE-794: --- Attachment: spanhighlighter2.patch Patch version 2 Changed to correct build.xml, removed some unneeded code Has been working well for me personally, could still use some additional span highlighting tests > Beginnings of a span based highlighter > -- > > Key: LUCENE-794 > URL: https://issues.apache.org/jira/browse/LUCENE-794 > Project: Lucene - Java > Issue Type: Improvement > Components: Other >Reporter: Mark Miller >Priority: Minor > Attachments: CachedTokenStream.java, CachedTokenStream.java, > CachedTokenStream.java, DefaultEncoder.java, Encoder.java, Formatter.java, > Highlighter.java, Highlighter.java, Highlighter.java, Highlighter.java, > Highlighter.java, HighlighterTest.java, HighlighterTest.java, > HighlighterTest.java, HighlighterTest.java, MemoryIndex.java, > QuerySpansExtractor.java, QuerySpansExtractor.java, QuerySpansExtractor.java, > QuerySpansExtractor.java, SimpleFormatter.java, spanhighlighter.patch, > spanhighlighter2.patch, SpanHighlighterTest.java, SpanHighlighterTest.java, > SpanScorer.java, SpanScorer.java, WeightedSpanTerm.java > > > This is some test code to start the work of adding a span based highlighting > approach to the existing highlighter in contrib. See > http://issues.apache.org/jira/browse/LUCENE-403 for some background. > There is a dependency on MemoryIndex. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-819) NullPointerException in Term.compareTo()
[ https://issues.apache.org/jira/browse/LUCENE-819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Zivkovic updated LUCENE-819: Attachment: lucene-819.patch Added unit test. > NullPointerException in Term.compareTo() > > > Key: LUCENE-819 > URL: https://issues.apache.org/jira/browse/LUCENE-819 > Project: Lucene - Java > Issue Type: Bug > Components: Index > Environment: JDK 1.4 on MacOS >Reporter: Dan Zivkovic > Attachments: lucene-819.patch, lucene-819.patch > > > java.lang.NullPointerException > at org.apache.lucene.index.Term.compareTo(Term.java:84) > at > org.apache.lucene.index.TermInfosReader.getIndexOffset(TermInfosReader.java:115) > at org.apache.lucene.index.TermInfosReader.get(TermInfosReader.java:150) > at org.apache.lucene.index.SegmentReader.docFreq(SegmentReader.java:300) > at org.apache.lucene.search.IndexSearcher.docFreq(IndexSearcher.java:78) > at org.apache.lucene.search.Similarity.idf(Similarity.java:255) > at > org.apache.lucene.search.TermQuery$TermWeight.(TermQuery.java:43) > at org.apache.lucene.search.TermQuery.createWeight(TermQuery.java:142) > at > org.apache.lucene.search.BooleanQuery$BooleanWeight.(BooleanQuery.java:203) > at > org.apache.lucene.search.BooleanQuery$BooleanWeight2.(BooleanQuery.java:330) > at > org.apache.lucene.search.BooleanQuery.createWeight(BooleanQuery.java:372) > at org.apache.lucene.search.Query.weight(Query.java:93) > at org.apache.lucene.search.Hits.(Hits.java:48) > at org.apache.lucene.search.Searcher.search(Searcher.java:53) > ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-819) NullPointerException in Term.compareTo()
[ https://issues.apache.org/jira/browse/LUCENE-819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Zivkovic updated LUCENE-819: Attachment: TestTerm.java Unit test class. > NullPointerException in Term.compareTo() > > > Key: LUCENE-819 > URL: https://issues.apache.org/jira/browse/LUCENE-819 > Project: Lucene - Java > Issue Type: Bug > Components: Index > Environment: JDK 1.4 on MacOS >Reporter: Dan Zivkovic > Attachments: lucene-819.patch, lucene-819.patch, TestTerm.java > > > java.lang.NullPointerException > at org.apache.lucene.index.Term.compareTo(Term.java:84) > at > org.apache.lucene.index.TermInfosReader.getIndexOffset(TermInfosReader.java:115) > at org.apache.lucene.index.TermInfosReader.get(TermInfosReader.java:150) > at org.apache.lucene.index.SegmentReader.docFreq(SegmentReader.java:300) > at org.apache.lucene.search.IndexSearcher.docFreq(IndexSearcher.java:78) > at org.apache.lucene.search.Similarity.idf(Similarity.java:255) > at > org.apache.lucene.search.TermQuery$TermWeight.(TermQuery.java:43) > at org.apache.lucene.search.TermQuery.createWeight(TermQuery.java:142) > at > org.apache.lucene.search.BooleanQuery$BooleanWeight.(BooleanQuery.java:203) > at > org.apache.lucene.search.BooleanQuery$BooleanWeight2.(BooleanQuery.java:330) > at > org.apache.lucene.search.BooleanQuery.createWeight(BooleanQuery.java:372) > at org.apache.lucene.search.Query.weight(Query.java:93) > at org.apache.lucene.search.Hits.(Hits.java:48) > at org.apache.lucene.search.Searcher.search(Searcher.java:53) > ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-819) NullPointerException in Term.compareTo()
[ https://issues.apache.org/jira/browse/LUCENE-819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476483 ] Dan Zivkovic commented on LUCENE-819: - We use Lucene on content that is often strange and exciting, and we get all sorts of text fields, including nulls. This ends up throwing NPE's with no way to resolve them except inside Lucene. I considered the possibility of a workaround before even filing the bug, but when that proved impossible, I filed the bug, got an Apache login, and submitted the fix. > NullPointerException in Term.compareTo() > > > Key: LUCENE-819 > URL: https://issues.apache.org/jira/browse/LUCENE-819 > Project: Lucene - Java > Issue Type: Bug > Components: Index > Environment: JDK 1.4 on MacOS >Reporter: Dan Zivkovic > Attachments: lucene-819.patch, lucene-819.patch, TestTerm.java > > > java.lang.NullPointerException > at org.apache.lucene.index.Term.compareTo(Term.java:84) > at > org.apache.lucene.index.TermInfosReader.getIndexOffset(TermInfosReader.java:115) > at org.apache.lucene.index.TermInfosReader.get(TermInfosReader.java:150) > at org.apache.lucene.index.SegmentReader.docFreq(SegmentReader.java:300) > at org.apache.lucene.search.IndexSearcher.docFreq(IndexSearcher.java:78) > at org.apache.lucene.search.Similarity.idf(Similarity.java:255) > at > org.apache.lucene.search.TermQuery$TermWeight.(TermQuery.java:43) > at org.apache.lucene.search.TermQuery.createWeight(TermQuery.java:142) > at > org.apache.lucene.search.BooleanQuery$BooleanWeight.(BooleanQuery.java:203) > at > org.apache.lucene.search.BooleanQuery$BooleanWeight2.(BooleanQuery.java:330) > at > org.apache.lucene.search.BooleanQuery.createWeight(BooleanQuery.java:372) > at org.apache.lucene.search.Query.weight(Query.java:93) > at org.apache.lucene.search.Hits.(Hits.java:48) > at org.apache.lucene.search.Searcher.search(Searcher.java:53) > ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-819) NullPointerException in Term.compareTo()
[ https://issues.apache.org/jira/browse/LUCENE-819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476484 ] Dan Zivkovic commented on LUCENE-819: - p.s. How do I delete attachment #2? > NullPointerException in Term.compareTo() > > > Key: LUCENE-819 > URL: https://issues.apache.org/jira/browse/LUCENE-819 > Project: Lucene - Java > Issue Type: Bug > Components: Index > Environment: JDK 1.4 on MacOS >Reporter: Dan Zivkovic > Attachments: lucene-819.patch, lucene-819.patch, TestTerm.java > > > java.lang.NullPointerException > at org.apache.lucene.index.Term.compareTo(Term.java:84) > at > org.apache.lucene.index.TermInfosReader.getIndexOffset(TermInfosReader.java:115) > at org.apache.lucene.index.TermInfosReader.get(TermInfosReader.java:150) > at org.apache.lucene.index.SegmentReader.docFreq(SegmentReader.java:300) > at org.apache.lucene.search.IndexSearcher.docFreq(IndexSearcher.java:78) > at org.apache.lucene.search.Similarity.idf(Similarity.java:255) > at > org.apache.lucene.search.TermQuery$TermWeight.(TermQuery.java:43) > at org.apache.lucene.search.TermQuery.createWeight(TermQuery.java:142) > at > org.apache.lucene.search.BooleanQuery$BooleanWeight.(BooleanQuery.java:203) > at > org.apache.lucene.search.BooleanQuery$BooleanWeight2.(BooleanQuery.java:330) > at > org.apache.lucene.search.BooleanQuery.createWeight(BooleanQuery.java:372) > at org.apache.lucene.search.Query.weight(Query.java:93) > at org.apache.lucene.search.Hits.(Hits.java:48) > at org.apache.lucene.search.Searcher.search(Searcher.java:53) > ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-819) NullPointerException in Term.compareTo()
[ https://issues.apache.org/jira/browse/LUCENE-819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476496 ] Steven Parkes commented on LUCENE-819: -- Can you say anymore about why it was impossible? What if Term checked for null field or text and threw an exception that you could catch (though this might not be a good idea the check would always be there but it's an uncommon case ...). Note that Lucene specifically checks to see if you try to add a null field or a null field value to a doc and won't let you. As to deleting attachments, it's unnecessary/discouraged (and possibly these days, impossible). If you name two patches the same, the older one is grayed out, making it pretty clear that one replaces the other. It's considered valuable to be able to go back and look at old attachments. > NullPointerException in Term.compareTo() > > > Key: LUCENE-819 > URL: https://issues.apache.org/jira/browse/LUCENE-819 > Project: Lucene - Java > Issue Type: Bug > Components: Index > Environment: JDK 1.4 on MacOS >Reporter: Dan Zivkovic > Attachments: lucene-819.patch, lucene-819.patch, TestTerm.java > > > java.lang.NullPointerException > at org.apache.lucene.index.Term.compareTo(Term.java:84) > at > org.apache.lucene.index.TermInfosReader.getIndexOffset(TermInfosReader.java:115) > at org.apache.lucene.index.TermInfosReader.get(TermInfosReader.java:150) > at org.apache.lucene.index.SegmentReader.docFreq(SegmentReader.java:300) > at org.apache.lucene.search.IndexSearcher.docFreq(IndexSearcher.java:78) > at org.apache.lucene.search.Similarity.idf(Similarity.java:255) > at > org.apache.lucene.search.TermQuery$TermWeight.(TermQuery.java:43) > at org.apache.lucene.search.TermQuery.createWeight(TermQuery.java:142) > at > org.apache.lucene.search.BooleanQuery$BooleanWeight.(BooleanQuery.java:203) > at > org.apache.lucene.search.BooleanQuery$BooleanWeight2.(BooleanQuery.java:330) > at > org.apache.lucene.search.BooleanQuery.createWeight(BooleanQuery.java:372) > at org.apache.lucene.search.Query.weight(Query.java:93) > at org.apache.lucene.search.Hits.(Hits.java:48) > at org.apache.lucene.search.Searcher.search(Searcher.java:53) > ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-819) NullPointerException in Term.compareTo()
[ https://issues.apache.org/jira/browse/LUCENE-819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476506 ] Yonik Seeley commented on LUCENE-819: - I'm not sure it's a good idea adding extra checks for things that may be used in inner loops (like Term.compareTo()). > NullPointerException in Term.compareTo() > > > Key: LUCENE-819 > URL: https://issues.apache.org/jira/browse/LUCENE-819 > Project: Lucene - Java > Issue Type: Bug > Components: Index > Environment: JDK 1.4 on MacOS >Reporter: Dan Zivkovic > Attachments: lucene-819.patch, lucene-819.patch, TestTerm.java > > > java.lang.NullPointerException > at org.apache.lucene.index.Term.compareTo(Term.java:84) > at > org.apache.lucene.index.TermInfosReader.getIndexOffset(TermInfosReader.java:115) > at org.apache.lucene.index.TermInfosReader.get(TermInfosReader.java:150) > at org.apache.lucene.index.SegmentReader.docFreq(SegmentReader.java:300) > at org.apache.lucene.search.IndexSearcher.docFreq(IndexSearcher.java:78) > at org.apache.lucene.search.Similarity.idf(Similarity.java:255) > at > org.apache.lucene.search.TermQuery$TermWeight.(TermQuery.java:43) > at org.apache.lucene.search.TermQuery.createWeight(TermQuery.java:142) > at > org.apache.lucene.search.BooleanQuery$BooleanWeight.(BooleanQuery.java:203) > at > org.apache.lucene.search.BooleanQuery$BooleanWeight2.(BooleanQuery.java:330) > at > org.apache.lucene.search.BooleanQuery.createWeight(BooleanQuery.java:372) > at org.apache.lucene.search.Query.weight(Query.java:93) > at org.apache.lucene.search.Hits.(Hits.java:48) > at org.apache.lucene.search.Searcher.search(Searcher.java:53) > ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-819) NullPointerException in Term.compareTo()
[ https://issues.apache.org/jira/browse/LUCENE-819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476522 ] Hoss Man commented on LUCENE-819: - i agree with Yonik ... the javadocs for Term don't make it clear that text can't be null -- but we can fix that, i suspect lots of things assume Term.text isn't null. Dan: I'm assuming based on your description that you are building the TermQuery in your own code? I'm really not clear on why your app can't test for null before constructing the Term > NullPointerException in Term.compareTo() > > > Key: LUCENE-819 > URL: https://issues.apache.org/jira/browse/LUCENE-819 > Project: Lucene - Java > Issue Type: Bug > Components: Index > Environment: JDK 1.4 on MacOS >Reporter: Dan Zivkovic > Attachments: lucene-819.patch, lucene-819.patch, TestTerm.java > > > java.lang.NullPointerException > at org.apache.lucene.index.Term.compareTo(Term.java:84) > at > org.apache.lucene.index.TermInfosReader.getIndexOffset(TermInfosReader.java:115) > at org.apache.lucene.index.TermInfosReader.get(TermInfosReader.java:150) > at org.apache.lucene.index.SegmentReader.docFreq(SegmentReader.java:300) > at org.apache.lucene.search.IndexSearcher.docFreq(IndexSearcher.java:78) > at org.apache.lucene.search.Similarity.idf(Similarity.java:255) > at > org.apache.lucene.search.TermQuery$TermWeight.(TermQuery.java:43) > at org.apache.lucene.search.TermQuery.createWeight(TermQuery.java:142) > at > org.apache.lucene.search.BooleanQuery$BooleanWeight.(BooleanQuery.java:203) > at > org.apache.lucene.search.BooleanQuery$BooleanWeight2.(BooleanQuery.java:330) > at > org.apache.lucene.search.BooleanQuery.createWeight(BooleanQuery.java:372) > at org.apache.lucene.search.Query.weight(Query.java:93) > at org.apache.lucene.search.Hits.(Hits.java:48) > at org.apache.lucene.search.Searcher.search(Searcher.java:53) > ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-819) NullPointerException in Term.compareTo()
[ https://issues.apache.org/jira/browse/LUCENE-819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476527 ] Dan Zivkovic commented on LUCENE-819: - The workaround is not practical. It would force me to handle the null case as an error, when I already have a non-trivial application in production which considers the null case to be valid. That means going back and revisiting all sorts of assumptions. On the other hand, the Term class never made any assumptions about null text fields, explicitly or implicitly. The cat's out of the bag, so to speak. Therefore, let's just handle the null case gracefully. In terms of performance, checking for null will not cause performance issues in any application. > NullPointerException in Term.compareTo() > > > Key: LUCENE-819 > URL: https://issues.apache.org/jira/browse/LUCENE-819 > Project: Lucene - Java > Issue Type: Bug > Components: Index > Environment: JDK 1.4 on MacOS >Reporter: Dan Zivkovic > Attachments: lucene-819.patch, lucene-819.patch, TestTerm.java > > > java.lang.NullPointerException > at org.apache.lucene.index.Term.compareTo(Term.java:84) > at > org.apache.lucene.index.TermInfosReader.getIndexOffset(TermInfosReader.java:115) > at org.apache.lucene.index.TermInfosReader.get(TermInfosReader.java:150) > at org.apache.lucene.index.SegmentReader.docFreq(SegmentReader.java:300) > at org.apache.lucene.search.IndexSearcher.docFreq(IndexSearcher.java:78) > at org.apache.lucene.search.Similarity.idf(Similarity.java:255) > at > org.apache.lucene.search.TermQuery$TermWeight.(TermQuery.java:43) > at org.apache.lucene.search.TermQuery.createWeight(TermQuery.java:142) > at > org.apache.lucene.search.BooleanQuery$BooleanWeight.(BooleanQuery.java:203) > at > org.apache.lucene.search.BooleanQuery$BooleanWeight2.(BooleanQuery.java:330) > at > org.apache.lucene.search.BooleanQuery.createWeight(BooleanQuery.java:372) > at org.apache.lucene.search.Query.weight(Query.java:93) > at org.apache.lucene.search.Hits.(Hits.java:48) > at org.apache.lucene.search.Searcher.search(Searcher.java:53) > ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Hudson build is back to normal: Lucene-Nightly #8
See http://lucene.zones.apache.org:8080/hudson/job/Lucene-Nightly/8/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
