date:20090902


[ 
https://issues.apache.org/jira/browse/LUCENE-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12750284#action_12750284
 ] 

Uwe Schindler commented on LUCENE-1881:
---

There is no practical solution for this, indexing is a one-way action and not 
reversible. Because of this we offer stored fields as a store for the orginal 
or additional information to the indexed documents (e.g. for storing the 
original strings indexed).

Lucene works with an inverted index 
([http://en.wikipedia.org/wiki/Inverted_index]). During inversion of these 
non-stored fields (indexed ones), the fields are tokenized (which is a 
non-reversible action, because stop-words are removed, terms are normalized and 
so on) and these terms are stored in a global unique list off all terms. The 
index then only contains the references to the document ids (one-way from term 
- document id). For your problem you need to get the list of terms for one 
document which is not easily possible (there is some possibility to iterate 
over all terms/docs and try to rebuild the terms for a document, but you never 
get back the old indexed contents and its very slow. Look into the tool Luke 
for this, which is a GUI for Lucene that has some code to do this).

You can only add your already indexed contents to another index using 
IndexWriter.addIndexes(). In this case they stay searchable but cannot be 
modified.

 Non-stored fields are not copied in writer.addDocument()?
 -

 Key: LUCENE-1881
 URL: https://issues.apache.org/jira/browse/LUCENE-1881
 Project: Lucene - Java
  Issue Type: Bug
  Components: Store
Affects Versions: 2.4.1
 Environment: Linux
Reporter: Wai Wong
Assignee: Hoss Man
Priority: Critical

 We would like to modified stored documents properties.  The method is to use 
 IndexReader to open all files, modified some fields, and copy the document 
 via addDocument() of IndexWriter to another index.  But all fields that are 
 created using Field.Store.NO are no longer available for searching.
 Sample code in jsp is attached:
 %@ page language=java 
 import=org.apache.lucene.analysis.standard.StandardAnalyzer;%
 %@ page language=java import=org.apache.lucene.document.*;%
 %@ page language=java import=org.apache.lucene.index.*;%
 %@ page language=java import=org.apache.lucene.search.*;%
 %@ page contentType=text/html; charset=utf8 %
 %
 // create for testing
 IndexWriter writer = new IndexWriter(/opt/wwwroot/351/Index/test, new 
 StandardAnalyzer(), true, IndexWriter.MaxFieldLength.LIMITED);
 Document doc = new Document();
 doc.add(new Field(A, 1234, Field.Store.NO , 
 Field.Index.NOT_ANALYZED));
 doc.add(new Field(B, abcd, Field.Store.NO , 
 Field.Index.NOT_ANALYZED));
 writer.addDocument(doc);
 writer.close();
 // check ok
 Query q = new TermQuery(new Term(A, 1234));
 Searcher s = new IndexSearcher(/opt/wwwroot/351/Index/test);
 Hits h = s.search(q);
 out.println(# of document found is  + h.length());// it is ok
 // update the document to change or remove a field
 IndexReader r = IndexReader.open(/opt/wwwroot/351/Index/test);
 doc = r.document(0);
 r.deleteDocument(0);
 r.close();
 doc.removeField(B);
 writer = new IndexWriter(/opt/wwwroot/351/Index/test1, new 
 StandardAnalyzer(), true, IndexWriter.MaxFieldLength.LIMITED);
 writer.addDocument(doc);
 writer.optimize();
 writer.close();
 // test again
 s = new IndexSearcher(/opt/wwwroot/351/Index/test1);
 h = s.search(q);
 out.println(P# of document found is now  + h.length());
 r = IndexReader.open(/opt/wwwroot/351/Index/test1);
 out.println(P max Doc is  + r.maxDoc());
 %

-- 
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Commented: (LUCENE-1881) Non-stored fields are not copied in writer.addDocument()?

2009-09-02 Thread Wai Wong (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12750296#action_12750296
 ] 

Wai Wong commented on LUCENE-1881:
--

I searched a few other discussions and confirmed this behavior, and the Lazy 
Load feature was introduced to compensate the penalty of storing all these 
fields.  The problem now is that the Lazy Load feature is only applicable to 
IndexReader, not IndexSearcher.  That means I have to load all contents in 
searching even if I am not going to use them, just because I must keep the 
possibility of modifying the index db.  I am indexing large number of files and 
this is a concern for me.

I suppose a similar method like IndexReader.document(int n, FieldSelector 
fieldSelector) should also be provided for IndexSearcher as IndexSearcher is 
much more frequently than IndexReader in most cases.

Please correct me if I am wrong.

 Non-stored fields are not copied in writer.addDocument()?
 -

 Key: LUCENE-1881
 URL: https://issues.apache.org/jira/browse/LUCENE-1881
 Project: Lucene - Java
  Issue Type: Bug
  Components: Store
Affects Versions: 2.4.1
 Environment: Linux
Reporter: Wai Wong
Assignee: Hoss Man
Priority: Critical

 We would like to modified stored documents properties.  The method is to use 
 IndexReader to open all files, modified some fields, and copy the document 
 via addDocument() of IndexWriter to another index.  But all fields that are 
 created using Field.Store.NO are no longer available for searching.
 Sample code in jsp is attached:
 %@ page language=java 
 import=org.apache.lucene.analysis.standard.StandardAnalyzer;%
 %@ page language=java import=org.apache.lucene.document.*;%
 %@ page language=java import=org.apache.lucene.index.*;%
 %@ page language=java import=org.apache.lucene.search.*;%
 %@ page contentType=text/html; charset=utf8 %
 %
 // create for testing
 IndexWriter writer = new IndexWriter(/opt/wwwroot/351/Index/test, new 
 StandardAnalyzer(), true, IndexWriter.MaxFieldLength.LIMITED);
 Document doc = new Document();
 doc.add(new Field(A, 1234, Field.Store.NO , 
 Field.Index.NOT_ANALYZED));
 doc.add(new Field(B, abcd, Field.Store.NO , 
 Field.Index.NOT_ANALYZED));
 writer.addDocument(doc);
 writer.close();
 // check ok
 Query q = new TermQuery(new Term(A, 1234));
 Searcher s = new IndexSearcher(/opt/wwwroot/351/Index/test);
 Hits h = s.search(q);
 out.println(# of document found is  + h.length());// it is ok
 // update the document to change or remove a field
 IndexReader r = IndexReader.open(/opt/wwwroot/351/Index/test);
 doc = r.document(0);
 r.deleteDocument(0);
 r.close();
 doc.removeField(B);
 writer = new IndexWriter(/opt/wwwroot/351/Index/test1, new 
 StandardAnalyzer(), true, IndexWriter.MaxFieldLength.LIMITED);
 writer.addDocument(doc);
 writer.optimize();
 writer.close();
 // test again
 s = new IndexSearcher(/opt/wwwroot/351/Index/test1);
 h = s.search(q);
 out.println(P# of document found is now  + h.length());
 r = IndexReader.open(/opt/wwwroot/351/Index/test1);
 out.println(P max Doc is  + r.maxDoc());
 %

-- 
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Commented: (LUCENE-1881) Non-stored fields are not copied in writer.addDocument()?


[ 
https://issues.apache.org/jira/browse/LUCENE-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12750307#action_12750307
 ] 

Uwe Schindler commented on LUCENE-1881:
---

IndexSearcher has this method: 
[http://lucene.apache.org/java/2_4_1/api/org/apache/lucene/search/IndexSearcher.html#doc(int,
 org.apache.lucene.document.FieldSelector)]

Uwe

 Non-stored fields are not copied in writer.addDocument()?
 -

 Key: LUCENE-1881
 URL: https://issues.apache.org/jira/browse/LUCENE-1881
 Project: Lucene - Java
  Issue Type: Bug
  Components: Store
Affects Versions: 2.4.1
 Environment: Linux
Reporter: Wai Wong
Assignee: Hoss Man
Priority: Critical

 We would like to modified stored documents properties.  The method is to use 
 IndexReader to open all files, modified some fields, and copy the document 
 via addDocument() of IndexWriter to another index.  But all fields that are 
 created using Field.Store.NO are no longer available for searching.
 Sample code in jsp is attached:
 %@ page language=java 
 import=org.apache.lucene.analysis.standard.StandardAnalyzer;%
 %@ page language=java import=org.apache.lucene.document.*;%
 %@ page language=java import=org.apache.lucene.index.*;%
 %@ page language=java import=org.apache.lucene.search.*;%
 %@ page contentType=text/html; charset=utf8 %
 %
 // create for testing
 IndexWriter writer = new IndexWriter(/opt/wwwroot/351/Index/test, new 
 StandardAnalyzer(), true, IndexWriter.MaxFieldLength.LIMITED);
 Document doc = new Document();
 doc.add(new Field(A, 1234, Field.Store.NO , 
 Field.Index.NOT_ANALYZED));
 doc.add(new Field(B, abcd, Field.Store.NO , 
 Field.Index.NOT_ANALYZED));
 writer.addDocument(doc);
 writer.close();
 // check ok
 Query q = new TermQuery(new Term(A, 1234));
 Searcher s = new IndexSearcher(/opt/wwwroot/351/Index/test);
 Hits h = s.search(q);
 out.println(# of document found is  + h.length());// it is ok
 // update the document to change or remove a field
 IndexReader r = IndexReader.open(/opt/wwwroot/351/Index/test);
 doc = r.document(0);
 r.deleteDocument(0);
 r.close();
 doc.removeField(B);
 writer = new IndexWriter(/opt/wwwroot/351/Index/test1, new 
 StandardAnalyzer(), true, IndexWriter.MaxFieldLength.LIMITED);
 writer.addDocument(doc);
 writer.optimize();
 writer.close();
 // test again
 s = new IndexSearcher(/opt/wwwroot/351/Index/test1);
 h = s.search(q);
 out.println(P# of document found is now  + h.length());
 r = IndexReader.open(/opt/wwwroot/351/Index/test1);
 out.println(P max Doc is  + r.maxDoc());
 %

-- 
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Updated: (LUCENE-1884) javadocs cleanup


 [ 
https://issues.apache.org/jira/browse/LUCENE-1884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Muir updated LUCENE-1884:


Attachment: LUCENE-1884.patch

 javadocs cleanup
 

 Key: LUCENE-1884
 URL: https://issues.apache.org/jira/browse/LUCENE-1884
 Project: Lucene - Java
  Issue Type: Task
  Components: Javadocs
Reporter: Robert Muir
Priority: Minor
 Fix For: 2.9

 Attachments: LUCENE-1884.patch


 basic cleanup in core/contrib: typos, apache license header as javadoc, 
 missing periods that screw up package summary, etc.

-- 
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Updated: (LUCENE-1877) Use NativeFSLockFactory as default for new API (direct ctors FSDir.open)


 [ 
https://issues.apache.org/jira/browse/LUCENE-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler updated LUCENE-1877:
--

Summary: Use NativeFSLockFactory as default for new API (direct ctors  
FSDir.open)  (was: Improve IndexWriter javadoc on locking)

 Use NativeFSLockFactory as default for new API (direct ctors  FSDir.open)
 --

 Key: LUCENE-1877
 URL: https://issues.apache.org/jira/browse/LUCENE-1877
 Project: Lucene - Java
  Issue Type: Improvement
  Components: Javadocs
Reporter: Mark Miller
Priority: Trivial
 Fix For: 2.9

 Attachments: LUCENE-1877.patch


 A user requested we add a note in IndexWriter alerting the availability of 
 NativeFSLockFactory (allowing you to avoid retaining locks on abnormal jvm 
 exit). Seems reasonable to me - we want users to be able to easily stumble 
 upon this class. The below code looks like a good spot to add a note - could 
 also improve whats there a bit - opening an IndexWriter does not necessarily 
 create a lock file - that would depend on the LockFactory used.
 {code}  pOpening an codeIndexWriter/code creates a lock file for the 
 directory in use. Trying to open
   another codeIndexWriter/code on the same directory will lead to a
   {...@link LockObtainFailedException}. The {...@link 
 LockObtainFailedException}
   is also thrown if an IndexReader on the same directory is used to delete 
 documents
   from the index./p{code}
 Anyone remember why NativeFSLockFactory is not the default over 
 SimpleFSLockFactory?

-- 
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Commented: (LUCENE-1877) Use NativeFSLockFactory as default for new API (direct ctors FSDir.open)

[
https://issues.apache.org/jira/browse/LUCENE-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12750425#action_12750425
]

Uwe Schindler commented on LUCENE-1877:
---

bq. I think we should also fix NativeLockFactory so that if the write lock is
in the index dir it doesn't generate the large digest in the file name. That
digest is problematic when two different machines access the same physical dir
via different mount names, since that results in different lock file names.

The digest problem is not easy to solve: It happens for all LockFactories if
they are not automatically created (when LockFactory==null). As soon as you
cann FSDir.open(..., new SimpleLockFactory(...)) you also get these prefix. It
does not appear, when the FSDir is created by FSDir.getDirectory(), as the
init() method cleans the lockPrefix directly after setting the lockfactory (the
lock factory setter sets the prefix).

The prefix is only important, if the lock is not placed inside the index
directory. The best would be that FSDir would simply return null in getLockId,
when the LockFactory uses the same path as the Directory. For that to work, the
LockFactory should have a getter for the fs path.

I will try some possibilities and post a patch.

Use NativeFSLockFactory as default for new API (direct ctors FSDir.open)
--

Key: LUCENE-1877
URL: https://issues.apache.org/jira/browse/LUCENE-1877
Project: Lucene - Java
Issue Type: Improvement
Components: Javadocs
Reporter: Mark Miller
Priority: Trivial
Fix For: 2.9

Attachments: LUCENE-1877.patch

A user requested we add a note in IndexWriter alerting the availability of
NativeFSLockFactory (allowing you to avoid retaining locks on abnormal jvm
exit). Seems reasonable to me - we want users to be able to easily stumble
upon this class. The below code looks like a good spot to add a note - could
also improve whats there a bit - opening an IndexWriter does not necessarily
create a lock file - that would depend on the LockFactory used.
{code} pOpening an codeIndexWriter/code creates a lock file for the
directory in use. Trying to open
another codeIndexWriter/code on the same directory will lead to a
{...@link LockObtainFailedException}. The {...@link
LockObtainFailedException}
is also thrown if an IndexReader on the same directory is used to delete
documents
from the index./p{code}
Anyone remember why NativeFSLockFactory is not the default over
SimpleFSLockFactory?

--
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Issue Comment Edited: (LUCENE-1877) Use NativeFSLockFactory as default for new API (direct ctors FSDir.open)

[
https://issues.apache.org/jira/browse/LUCENE-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12750425#action_12750425
]

Uwe Schindler edited comment on LUCENE-1877 at 9/2/09 6:12 AM:
---

The digest problem is not easy to solve: It happens for all LockFactories if
they are not automatically created (when LockFactory==null). As soon as you
call FSDir.open(..., new SimpleLockFactory(...)) you also get this prefix. It
does not appear, when the FSDir is created by FSDir.getDirectory(), as the
init() method cleans the lockPrefix directly after setting the lockfactory (the
lock factory setter sets the prefix).

The prefix is only important, if the lock is not placed inside the index
directory. The best would be that FSDir would simply return null in
getLockId(), when the LockFactory uses the same path as the Directory. For that
to work, the LockFactory should have a getter for the fs path.

I will try some possibilities and post a patch.

was (Author: thetaphi):
bq. I think we should also fix NativeLockFactory so that if the write lock
is in the index dir it doesn't generate the large digest in the file name. That
digest is problematic when two different machines access the same physical dir
via different mount names, since that results in different lock file names.

I will try some possibilities and post a patch.

Use NativeFSLockFactory as default for new API (direct ctors FSDir.open)
--

Key: LUCENE-1877
URL: https://issues.apache.org/jira/browse/LUCENE-1877
Project: Lucene - Java
Issue Type: Improvement
Components: Javadocs
Reporter: Mark Miller
Priority: Trivial
Fix For: 2.9

Attachments: LUCENE-1877.patch

--
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

Lucene 2.9 RM

2009-09-02 Thread Mark Miller

Anyone want to take over as RM? Pretty much all the unfun stuff is done
:) Otherwise I think we might have to wait to release till next week -
or the weekend or something. I'm mostly out of commission today/tomorrow
and I fly all day fri - with my luck I'll prob be flying all day sat too
- or sitting in a terminal or something.

-- 
- Mark

http://www.lucidimagination.com




-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Commented: (LUCENE-1883) Fix typos in CHANGES.txt and contrib/CHANGES.txt prior to 2.9 release


[ 
https://issues.apache.org/jira/browse/LUCENE-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12750469#action_12750469
 ] 

Mark Miller commented on LUCENE-1883:
-

bq. Once they make it past a release, they're set in stone..

Why?

 Fix typos in CHANGES.txt and contrib/CHANGES.txt prior to 2.9 release
 -

 Key: LUCENE-1883
 URL: https://issues.apache.org/jira/browse/LUCENE-1883
 Project: Lucene - Java
  Issue Type: Improvement
  Components: Other
Reporter: Steven Rowe
Priority: Trivial
 Fix For: 2.9

 Attachments: LUCENE-1883.patch


 I noticed a few typos in CHANGES.txt and contrib/CHANGES.txt.  (Once they 
 make it past a release, they're set in stone...)
 Will attach a patch shortly.

-- 
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

RE: Lucene 2.9 RM

2009-09-02 Thread Uwe Schindler

What to do with LUCENE-1877 ? If it goes into 2.9, we must have another RC.
So you have some more days.

I would do the RM, but I have no key to do signatures.

-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de

 -Original Message-
 From: Mark Miller [mailto:markrmil...@gmail.com]
 Sent: Wednesday, September 02, 2009 5:04 PM
 To: java-dev@lucene.apache.org
 Subject: Lucene 2.9 RM
 
 Anyone want to take over as RM? Pretty much all the unfun stuff is done
 :) Otherwise I think we might have to wait to release till next week -
 or the weekend or something. I'm mostly out of commission today/tomorrow
 and I fly all day fri - with my luck I'll prob be flying all day sat too
 - or sitting in a terminal or something.
 
 --
 - Mark
 
 http://www.lucidimagination.com
 
 
 
 
 -
 To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: java-dev-h...@lucene.apache.org



-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Commented: (LUCENE-1883) Fix typos in CHANGES.txt and contrib/CHANGES.txt prior to 2.9 release

2009-09-02 Thread Steven Rowe (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12750477#action_12750477
 ] 

Steven Rowe commented on LUCENE-1883:
-

I searched just now, but couldn't find, an email thread I recall on java-dev 
between Doug Cutting and the RM at that point (several years ago) about 
modifying past releases' CHANGES.txt entries.  Doug's position, articulated 
both in that thread (and elsewhere, IIRC), was that people depend on being able 
to do a diff between CHANGES.txt versions, so once a release was cut, the 
release notes should never change thereafter.


 Fix typos in CHANGES.txt and contrib/CHANGES.txt prior to 2.9 release
 -

 Key: LUCENE-1883
 URL: https://issues.apache.org/jira/browse/LUCENE-1883
 Project: Lucene - Java
  Issue Type: Improvement
  Components: Other
Reporter: Steven Rowe
Priority: Trivial
 Fix For: 2.9

 Attachments: LUCENE-1883.patch


 I noticed a few typos in CHANGES.txt and contrib/CHANGES.txt.  (Once they 
 make it past a release, they're set in stone...)
 Will attach a patch shortly.

-- 
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Resolved: (LUCENE-1883) Fix typos in CHANGES.txt and contrib/CHANGES.txt prior to 2.9 release


 [ 
https://issues.apache.org/jira/browse/LUCENE-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Miller resolved LUCENE-1883.
-

Resolution: Fixed

 Fix typos in CHANGES.txt and contrib/CHANGES.txt prior to 2.9 release
 -

 Key: LUCENE-1883
 URL: https://issues.apache.org/jira/browse/LUCENE-1883
 Project: Lucene - Java
  Issue Type: Improvement
  Components: Other
Reporter: Steven Rowe
Priority: Trivial
 Fix For: 2.9

 Attachments: LUCENE-1883.patch


 I noticed a few typos in CHANGES.txt and contrib/CHANGES.txt.  (Once they 
 make it past a release, they're set in stone...)
 Will attach a patch shortly.

-- 
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Reopened: (LUCENE-1883) Fix typos in CHANGES.txt and contrib/CHANGES.txt prior to 2.9 release


 [ 
https://issues.apache.org/jira/browse/LUCENE-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Miller reopened LUCENE-1883:
-


hmm - got marked invalid - weird - reopen to resolve right

 Fix typos in CHANGES.txt and contrib/CHANGES.txt prior to 2.9 release
 -

 Key: LUCENE-1883
 URL: https://issues.apache.org/jira/browse/LUCENE-1883
 Project: Lucene - Java
  Issue Type: Improvement
  Components: Other
Reporter: Steven Rowe
Priority: Trivial
 Fix For: 2.9

 Attachments: LUCENE-1883.patch


 I noticed a few typos in CHANGES.txt and contrib/CHANGES.txt.  (Once they 
 make it past a release, they're set in stone...)
 Will attach a patch shortly.

-- 
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Updated: (LUCENE-1876) Some contrib packages are missing a package.html


 [ 
https://issues.apache.org/jira/browse/LUCENE-1876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Muir updated LUCENE-1876:


Attachment: LUCENE-1876.patch

Steven Rowe's supplied docs for collation, plus some package.htmls for a couple 
more contribs.


 Some contrib packages are missing a package.html
 

 Key: LUCENE-1876
 URL: https://issues.apache.org/jira/browse/LUCENE-1876
 Project: Lucene - Java
  Issue Type: Improvement
  Components: contrib/*
Reporter: Mark Miller
Priority: Trivial
 Fix For: 2.9

 Attachments: collation-package.html, LUCENE-1876.patch


 Dunno if we will get to this one this release, but a few contribs don't have 
 a package.html (or a good overview that would work as a replacement) - I 
 don't think this is hugely important, but I think it is important - you 
 should be able to easily and quickly read a quick overview for each contrib I 
 think.
 So far I have identified collation and spatial.

-- 
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Resolved: (LUCENE-1878) remove deprecated classes from spatial


 [ 
https://issues.apache.org/jira/browse/LUCENE-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Miller resolved LUCENE-1878.
-

Resolution: Fixed

done and done

 remove deprecated classes from spatial
 --

 Key: LUCENE-1878
 URL: https://issues.apache.org/jira/browse/LUCENE-1878
 Project: Lucene - Java
  Issue Type: Task
  Components: contrib/spatial
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Minor
 Fix For: 2.9

 Attachments: LUCENE-1878.patch


 spatial has not been released, so we can remove the deprecated classes

-- 
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Reopened: (LUCENE-1878) remove deprecated classes from spatial


 [ 
https://issues.apache.org/jira/browse/LUCENE-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Miller reopened LUCENE-1878:
-


whoops - I've committed the issue, but ill reopen till Mike's comments are 
addressed

 remove deprecated classes from spatial
 --

 Key: LUCENE-1878
 URL: https://issues.apache.org/jira/browse/LUCENE-1878
 Project: Lucene - Java
  Issue Type: Task
  Components: contrib/spatial
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Minor
 Fix For: 2.9

 Attachments: LUCENE-1878.patch


 spatial has not been released, so we can remove the deprecated classes

-- 
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Commented: (LUCENE-1876) Some contrib packages are missing a package.html


[ 
https://issues.apache.org/jira/browse/LUCENE-1876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12750487#action_12750487
 ] 

Mark Miller commented on LUCENE-1876:
-

You want to take this issue Robert?

 Some contrib packages are missing a package.html
 

 Key: LUCENE-1876
 URL: https://issues.apache.org/jira/browse/LUCENE-1876
 Project: Lucene - Java
  Issue Type: Improvement
  Components: contrib/*
Reporter: Mark Miller
Priority: Trivial
 Fix For: 2.9

 Attachments: collation-package.html, LUCENE-1876.patch


 Dunno if we will get to this one this release, but a few contribs don't have 
 a package.html (or a good overview that would work as a replacement) - I 
 don't think this is hugely important, but I think it is important - you 
 should be able to easily and quickly read a quick overview for each contrib I 
 think.
 So far I have identified collation and spatial.

-- 
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Commented: (LUCENE-1876) Some contrib packages are missing a package.html


[ 
https://issues.apache.org/jira/browse/LUCENE-1876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12750489#action_12750489
 ] 

Robert Muir commented on LUCENE-1876:
-

Mark, sure. I would absolutely love it if someone who has a good understanding 
of spatial could comment on what the packages do, I will create the html files 
and update the patch!

 Some contrib packages are missing a package.html
 

 Key: LUCENE-1876
 URL: https://issues.apache.org/jira/browse/LUCENE-1876
 Project: Lucene - Java
  Issue Type: Improvement
  Components: contrib/*
Reporter: Mark Miller
Priority: Trivial
 Fix For: 2.9

 Attachments: collation-package.html, LUCENE-1876.patch


 Dunno if we will get to this one this release, but a few contribs don't have 
 a package.html (or a good overview that would work as a replacement) - I 
 don't think this is hugely important, but I think it is important - you 
 should be able to easily and quickly read a quick overview for each contrib I 
 think.
 So far I have identified collation and spatial.

-- 
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Assigned: (LUCENE-1876) Some contrib packages are missing a package.html


 [ 
https://issues.apache.org/jira/browse/LUCENE-1876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Muir reassigned LUCENE-1876:
---

Assignee: Robert Muir

 Some contrib packages are missing a package.html
 

 Key: LUCENE-1876
 URL: https://issues.apache.org/jira/browse/LUCENE-1876
 Project: Lucene - Java
  Issue Type: Improvement
  Components: contrib/*
Reporter: Mark Miller
Assignee: Robert Muir
Priority: Trivial
 Fix For: 2.9

 Attachments: collation-package.html, LUCENE-1876.patch


 Dunno if we will get to this one this release, but a few contribs don't have 
 a package.html (or a good overview that would work as a replacement) - I 
 don't think this is hugely important, but I think it is important - you 
 should be able to easily and quickly read a quick overview for each contrib I 
 think.
 So far I have identified collation and spatial.

-- 
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Commented: (LUCENE-1884) javadocs cleanup


[ 
https://issues.apache.org/jira/browse/LUCENE-1884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12750490#action_12750490
 ] 

Robert Muir commented on LUCENE-1884:
-

note: i tried to leave UK versus US english spelling differences alone, there 
were a few cases though where you might notice i changed this.

This was only in the case where it was inconsistent in the same file, i.e. a 
method that spells it 'synchronization' in one sentence but 'synchronisation' 
in the next.


 javadocs cleanup
 

 Key: LUCENE-1884
 URL: https://issues.apache.org/jira/browse/LUCENE-1884
 Project: Lucene - Java
  Issue Type: Task
  Components: Javadocs
Reporter: Robert Muir
Priority: Minor
 Fix For: 2.9

 Attachments: LUCENE-1884.patch


 basic cleanup in core/contrib: typos, apache license header as javadoc, 
 missing periods that screw up package summary, etc.

-- 
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Resolved: (LUCENE-1865) Add a ton of missing license headers throughout test/demo/contrib


 [ 
https://issues.apache.org/jira/browse/LUCENE-1865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Miller resolved LUCENE-1865.
-

Resolution: Fixed

Thanks a lot

 Add a ton of missing license headers throughout test/demo/contrib
 -

 Key: LUCENE-1865
 URL: https://issues.apache.org/jira/browse/LUCENE-1865
 Project: Lucene - Java
  Issue Type: Task
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Minor
 Fix For: 2.9

 Attachments: LUCENE-1865-part2.patch, LUCENE-1865.patch




-- 
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

Re: Lucene 2.9 RM

2009-09-02 Thread Michael Busch

I think waiting a few more days can't hurt? So releasing during the weekend
or early next weeks seems fine to me...

Sorry can't help with the RM, I'm going on vacation tomorrow - and won't
have internet access most of the time...

 Michael

On Wed, Sep 2, 2009 at 8:04 AM, Mark Miller markrmil...@gmail.com wrote:

 Anyone want to take over as RM? Pretty much all the unfun stuff is done
 :) Otherwise I think we might have to wait to release till next week -
 or the weekend or something. I'm mostly out of commission today/tomorrow
 and I fly all day fri - with my luck I'll prob be flying all day sat too
 - or sitting in a terminal or something.

 --
 - Mark

 http://www.lucidimagination.com




 -
 To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Created: (LUCENE-1885) NativeFSLockFactory.makeLock(...).isLocked() does not work

NativeFSLockFactory.makeLock(...).isLocked() does not work
--

 Key: LUCENE-1885
 URL: https://issues.apache.org/jira/browse/LUCENE-1885
 Project: Lucene - Java
  Issue Type: Bug
Reporter: Uwe Schindler
Priority: Blocker
 Fix For: 2.9


IndexWriter.isLocked() or IndexReader.isLocked() do not work with 
NativeFSLockFactory.

The problem is, that the method NativeFSLock.isLocked() just checks if the same 
lock instance was locked before (lock != null). If the LockFactory created a 
new lock instance, this always returns false, even if its locked.

-- 
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

Re: Lucene 2.9 RM

2009-09-02 Thread Mark Miller

Okay - there are enough little hanging chads out there (6 or 7 minor doc
issues?) that waiting is prob not a bad idea anyway - if Uwe ends up
changing the lock thing, I should have time to make a new RC this week -
I'm just mostly in meetings - and team building and stuff :)

- Mark

Michael Busch wrote:
 I think waiting a few more days can't hurt? So releasing during the
 weekend or early next weeks seems fine to me...

 Sorry can't help with the RM, I'm going on vacation tomorrow - and
 won't have internet access most of the time...

  Michael

 On Wed, Sep 2, 2009 at 8:04 AM, Mark Miller markrmil...@gmail.com
 mailto:markrmil...@gmail.com wrote:

 Anyone want to take over as RM? Pretty much all the unfun stuff is
 done
 :) Otherwise I think we might have to wait to release till next week -
 or the weekend or something. I'm mostly out of commission
 today/tomorrow
 and I fly all day fri - with my luck I'll prob be flying all day
 sat too
 - or sitting in a terminal or something.

 --
 - Mark

 http://www.lucidimagination.com




 -
 To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
 mailto:java-dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: java-dev-h...@lucene.apache.org
 mailto:java-dev-h...@lucene.apache.org




-- 
- Mark

http://www.lucidimagination.com




-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Created: (LUCENE-1886) Improve Javadoc

2009-09-02 Thread Bernd Fondermann (JIRA)

Improve Javadoc
---

 Key: LUCENE-1886
 URL: https://issues.apache.org/jira/browse/LUCENE-1886
 Project: Lucene - Java
  Issue Type: Improvement
  Components: Analysis
Reporter: Bernd Fondermann




-- 
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Updated: (LUCENE-1886) Improve Javadoc

2009-09-02 Thread Bernd Fondermann (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-1886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bernd Fondermann updated LUCENE-1886:
-

Attachment: javadoc.patch

 Improve Javadoc
 ---

 Key: LUCENE-1886
 URL: https://issues.apache.org/jira/browse/LUCENE-1886
 Project: Lucene - Java
  Issue Type: Improvement
  Components: Analysis
Reporter: Bernd Fondermann
 Attachments: javadoc.patch




-- 
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Updated: (LUCENE-1886) Improve Javadoc


 [ 
https://issues.apache.org/jira/browse/LUCENE-1886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Miller updated LUCENE-1886:


 Priority: Trivial  (was: Major)
Fix Version/s: 2.9

looks nice, thanks Bernd.

 Improve Javadoc
 ---

 Key: LUCENE-1886
 URL: https://issues.apache.org/jira/browse/LUCENE-1886
 Project: Lucene - Java
  Issue Type: Improvement
  Components: Analysis
Reporter: Bernd Fondermann
Priority: Trivial
 Fix For: 2.9

 Attachments: javadoc.patch




-- 
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Assigned: (LUCENE-1885) NativeFSLockFactory.makeLock(...).isLocked() does not work


 [ 
https://issues.apache.org/jira/browse/LUCENE-1885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler reassigned LUCENE-1885:
-

Assignee: Uwe Schindler

I will solve this together with LUCENE-1877.

To test, if lock is obtained, you have to try locking and release the lock 
after that (if the lock was obtained):

{code}
  public synchronized boolean isLocked() {
// the test for is isLocked is not directly possible with native file locks:

// if we have a lock instance in this class, it is for sure locked:
if (lockExists()) return true;

// else try to obtain and release (if was locked) the lock to test
try {
  boolean obtained = obtain();
  if (obtained) release();
  return !obtained;
} catch (IOException ioe) {
  return false;
}
  }
{code}

The method lockExists contains the same like isLocked contained before and is 
used instead to check if a local lock instance is available (as quick 
break-out).

There is no patch as it is included in my work for 1877 and hard to unwire.

 NativeFSLockFactory.makeLock(...).isLocked() does not work
 --

 Key: LUCENE-1885
 URL: https://issues.apache.org/jira/browse/LUCENE-1885
 Project: Lucene - Java
  Issue Type: Bug
Reporter: Uwe Schindler
Assignee: Uwe Schindler
Priority: Blocker
 Fix For: 2.9


 IndexWriter.isLocked() or IndexReader.isLocked() do not work with 
 NativeFSLockFactory.
 The problem is, that the method NativeFSLock.isLocked() just checks if the 
 same lock instance was locked before (lock != null). If the LockFactory 
 created a new lock instance, this always returns false, even if its locked.

-- 
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

RE: Lucene 2.9 RM

2009-09-02 Thread Uwe Schindler

I am finished soon. The big Native Lock isLocked() problem is solved.

I will post a patch soon. All tests pass now and the name of the lock is
without prefix for all file system lock factories, if the lockDir is the
same like the directory/index to supply locking for. Did some class
refactoriny for it (abstract FSLockFactory as superclass for Simple and
Native)

Uwe

-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de

 -Original Message-
 From: Mark Miller [mailto:markrmil...@gmail.com]
 Sent: Wednesday, September 02, 2009 5:55 PM
 To: java-dev@lucene.apache.org
 Subject: Re: Lucene 2.9 RM
 
 Okay - there are enough little hanging chads out there (6 or 7 minor doc
 issues?) that waiting is prob not a bad idea anyway - if Uwe ends up
 changing the lock thing, I should have time to make a new RC this week -
 I'm just mostly in meetings - and team building and stuff :)
 
 - Mark
 
 Michael Busch wrote:
  I think waiting a few more days can't hurt? So releasing during the
  weekend or early next weeks seems fine to me...
 
  Sorry can't help with the RM, I'm going on vacation tomorrow - and
  won't have internet access most of the time...
 
   Michael
 
  On Wed, Sep 2, 2009 at 8:04 AM, Mark Miller markrmil...@gmail.com
  mailto:markrmil...@gmail.com wrote:
 
  Anyone want to take over as RM? Pretty much all the unfun stuff is
  done
  :) Otherwise I think we might have to wait to release till next week
 -
  or the weekend or something. I'm mostly out of commission
  today/tomorrow
  and I fly all day fri - with my luck I'll prob be flying all day
  sat too
  - or sitting in a terminal or something.
 
  --
  - Mark
 
  http://www.lucidimagination.com
 
 
 
 
  
 -
  To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
  mailto:java-dev-unsubscr...@lucene.apache.org
  For additional commands, e-mail: java-dev-h...@lucene.apache.org
  mailto:java-dev-h...@lucene.apache.org
 
 
 
 
 --
 - Mark
 
 http://www.lucidimagination.com
 
 
 
 
 -
 To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: java-dev-h...@lucene.apache.org



-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Assigned: (LUCENE-1877) Use NativeFSLockFactory as default for new API (direct ctors FSDir.open)


 [ 
https://issues.apache.org/jira/browse/LUCENE-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler reassigned LUCENE-1877:
-

Assignee: Uwe Schindler

 Use NativeFSLockFactory as default for new API (direct ctors  FSDir.open)
 --

 Key: LUCENE-1877
 URL: https://issues.apache.org/jira/browse/LUCENE-1877
 Project: Lucene - Java
  Issue Type: Improvement
  Components: Javadocs
Reporter: Mark Miller
Assignee: Uwe Schindler
Priority: Trivial
 Fix For: 2.9

 Attachments: LUCENE-1877.patch


 A user requested we add a note in IndexWriter alerting the availability of 
 NativeFSLockFactory (allowing you to avoid retaining locks on abnormal jvm 
 exit). Seems reasonable to me - we want users to be able to easily stumble 
 upon this class. The below code looks like a good spot to add a note - could 
 also improve whats there a bit - opening an IndexWriter does not necessarily 
 create a lock file - that would depend on the LockFactory used.
 {code}  pOpening an codeIndexWriter/code creates a lock file for the 
 directory in use. Trying to open
   another codeIndexWriter/code on the same directory will lead to a
   {...@link LockObtainFailedException}. The {...@link 
 LockObtainFailedException}
   is also thrown if an IndexReader on the same directory is used to delete 
 documents
   from the index./p{code}
 Anyone remember why NativeFSLockFactory is not the default over 
 SimpleFSLockFactory?

-- 
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Updated: (LUCENE-1877) Use NativeFSLockFactory as default for new API (direct ctors FSDir.open)


 [ 
https://issues.apache.org/jira/browse/LUCENE-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler updated LUCENE-1877:
--

Priority: Major  (was: Trivial)

 Use NativeFSLockFactory as default for new API (direct ctors  FSDir.open)
 --

 Key: LUCENE-1877
 URL: https://issues.apache.org/jira/browse/LUCENE-1877
 Project: Lucene - Java
  Issue Type: Improvement
  Components: Javadocs
Reporter: Mark Miller
Assignee: Uwe Schindler
 Fix For: 2.9

 Attachments: LUCENE-1877.patch


 A user requested we add a note in IndexWriter alerting the availability of 
 NativeFSLockFactory (allowing you to avoid retaining locks on abnormal jvm 
 exit). Seems reasonable to me - we want users to be able to easily stumble 
 upon this class. The below code looks like a good spot to add a note - could 
 also improve whats there a bit - opening an IndexWriter does not necessarily 
 create a lock file - that would depend on the LockFactory used.
 {code}  pOpening an codeIndexWriter/code creates a lock file for the 
 directory in use. Trying to open
   another codeIndexWriter/code on the same directory will lead to a
   {...@link LockObtainFailedException}. The {...@link 
 LockObtainFailedException}
   is also thrown if an IndexReader on the same directory is used to delete 
 documents
   from the index./p{code}
 Anyone remember why NativeFSLockFactory is not the default over 
 SimpleFSLockFactory?

-- 
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Updated: (LUCENE-1877) Use NativeFSLockFactory as default for new API (direct ctors FSDir.open)

[
https://issues.apache.org/jira/browse/LUCENE-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Uwe Schindler updated LUCENE-1877:
--

Attachment: LUCENE-1877.patch

I have one idea (which is a new feature): How about providing a ctor to
NativeFSLockFactory and SimpleFSLockFactory without param. When this LF is
added to a FSDir, it would default to set the LockDir to itsself (if
lf.getLockDir()==null) lf.setLockDir(this.directory)). This would prevent users
from always giving the directory twice? Any thoughts, I would like to have that.

Because of the missing lockPrefix for locks inside the directory itsself one
backwards test (TestLockFactory) must be changed in backwards-branch, too.

Use NativeFSLockFactory as default for new API (direct ctors FSDir.open)
--

Key: LUCENE-1877
URL: https://issues.apache.org/jira/browse/LUCENE-1877
Project: Lucene - Java
Issue Type: Improvement
Components: Javadocs
Reporter: Mark Miller
Assignee: Uwe Schindler
Fix For: 2.9

Attachments: LUCENE-1877.patch, LUCENE-1877.patch

--
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Issue Comment Edited: (LUCENE-1877) Use NativeFSLockFactory as default for new API (direct ctors FSDir.open)

[
https://issues.apache.org/jira/browse/LUCENE-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12750549#action_12750549
]

Uwe Schindler edited comment on LUCENE-1877 at 9/2/09 10:35 AM:

Here is the patch:
- SimpleFSLockFactory and NativeFSLockFactory now have the same abstract
superclass providing setLockDir and getLockDir. Using this method, it is
possible for directory instances to detect, if the locks reside in the
directory itsself and so a lock prefix is switched off.
- The isLocked() bug in NativeFSLockFactory (LUCENE-1885) is solved by
implementing what was described in this issue.
- aquireTestLock in NativeFSLockFactory was removed from ctor and only called
for the first makeLock() call. This prevents the LockFactory from creating the
directory when not needed (e.g. opening non-existent index).

Because of the missing lockPrefix for locks inside the directory itsself one
backwards test (TestLockFactory) must be changed in backwards-branch, too.

was (Author: thetaphi):
Here is the patch:
- SimpleFSLockFactory and NativeFSLockFactory now have the same abstract
superclass providing setLockDir and getLockDir. Using this method, it is
possible for directory instances to detect, if the locks reside in the
directory itsself and so a lock prefix is switched off.
- The isLocked() bug in NativeFSLockFactory (LUCENE-1885) is solved by
implementing what was described in this issue.

Because of the missing lockPrefix for locks inside the directory itsself one
backwards test (TestLockFactory) must be changed in backwards-branch, too.

Use NativeFSLockFactory as default for new API (direct ctors FSDir.open)
--

Key: LUCENE-1877
URL: https://issues.apache.org/jira/browse/LUCENE-1877
Project: Lucene - Java
Issue Type: Improvement
Components: Javadocs
Reporter: Mark Miller
Assignee: Uwe Schindler
Fix For: 2.9

Attachments: LUCENE-1877.patch, LUCENE-1877.patch

--
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Commented: (LUCENE-1877) Use NativeFSLockFactory as default for new API (direct ctors FSDir.open)


[ 
https://issues.apache.org/jira/browse/LUCENE-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12750560#action_12750560
 ] 

Uwe Schindler commented on LUCENE-1877:
---

bq. I'd kind of like to deprecate the sys property to set the lock dir as well 
- we have done a good job of moving away from that stuff elsewhere.

It is already deprecated and even not used anymore:
{code}
  /**
   * Directory specified by codeorg.apache.lucene.lockDir/code
   * or codejava.io.tmpdir/code system property.

   * @deprecated As of 2.1, codeLOCK_DIR/code is unused
   * because the write.lock is now stored by default in the
   * index directory.  If you really want to store locks
   * elsewhere you can create your own {...@link
   * SimpleFSLockFactory} (or {...@link NativeFSLockFactory},
   * etc.) passing in your preferred lock directory.  Then,
   * pass this codeLockFactory/code instance to one of
   * the codegetDirectory/code methods that take a
   * codelockFactory/code (for example, {...@link #getDirectory(String, 
LockFactory)}).
   */
  public static final String LOCK_DIR = 
System.getProperty(org.apache.lucene.lockDir,
   
System.getProperty(java.io.tmpdir));
{code}

 Use NativeFSLockFactory as default for new API (direct ctors  FSDir.open)
 --

 Key: LUCENE-1877
 URL: https://issues.apache.org/jira/browse/LUCENE-1877
 Project: Lucene - Java
  Issue Type: Improvement
  Components: Javadocs
Reporter: Mark Miller
Assignee: Uwe Schindler
 Fix For: 2.9

 Attachments: LUCENE-1877.patch, LUCENE-1877.patch


 A user requested we add a note in IndexWriter alerting the availability of 
 NativeFSLockFactory (allowing you to avoid retaining locks on abnormal jvm 
 exit). Seems reasonable to me - we want users to be able to easily stumble 
 upon this class. The below code looks like a good spot to add a note - could 
 also improve whats there a bit - opening an IndexWriter does not necessarily 
 create a lock file - that would depend on the LockFactory used.
 {code}  pOpening an codeIndexWriter/code creates a lock file for the 
 directory in use. Trying to open
   another codeIndexWriter/code on the same directory will lead to a
   {...@link LockObtainFailedException}. The {...@link 
 LockObtainFailedException}
   is also thrown if an IndexReader on the same directory is used to delete 
 documents
   from the index./p{code}
 Anyone remember why NativeFSLockFactory is not the default over 
 SimpleFSLockFactory?

-- 
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Commented: (LUCENE-1877) Use NativeFSLockFactory as default for new API (direct ctors FSDir.open)


[ 
https://issues.apache.org/jira/browse/LUCENE-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12750563#action_12750563
 ] 

Mark Miller commented on LUCENE-1877:
-

heh - my jetlag is full effect - I wasn't looking at the lockdir, I was looking 
at:

{code}String lockClassName = 
System.getProperty(org.apache.lucene.store.FSDirectoryLockFactoryClass);
{code}

 Use NativeFSLockFactory as default for new API (direct ctors  FSDir.open)
 --

 Key: LUCENE-1877
 URL: https://issues.apache.org/jira/browse/LUCENE-1877
 Project: Lucene - Java
  Issue Type: Improvement
  Components: Javadocs
Reporter: Mark Miller
Assignee: Uwe Schindler
 Fix For: 2.9

 Attachments: LUCENE-1877.patch, LUCENE-1877.patch


 A user requested we add a note in IndexWriter alerting the availability of 
 NativeFSLockFactory (allowing you to avoid retaining locks on abnormal jvm 
 exit). Seems reasonable to me - we want users to be able to easily stumble 
 upon this class. The below code looks like a good spot to add a note - could 
 also improve whats there a bit - opening an IndexWriter does not necessarily 
 create a lock file - that would depend on the LockFactory used.
 {code}  pOpening an codeIndexWriter/code creates a lock file for the 
 directory in use. Trying to open
   another codeIndexWriter/code on the same directory will lead to a
   {...@link LockObtainFailedException}. The {...@link 
 LockObtainFailedException}
   is also thrown if an IndexReader on the same directory is used to delete 
 documents
   from the index./p{code}
 Anyone remember why NativeFSLockFactory is not the default over 
 SimpleFSLockFactory?

-- 
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Commented: (LUCENE-1877) Use NativeFSLockFactory as default for new API (direct ctors FSDir.open)

[
https://issues.apache.org/jira/browse/LUCENE-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12750565#action_12750565
]

Mark Miller commented on LUCENE-1877:
-

Is that a bug? I can't even find that class ...

Use NativeFSLockFactory as default for new API (direct ctors FSDir.open)
--

Key: LUCENE-1877
URL: https://issues.apache.org/jira/browse/LUCENE-1877
Project: Lucene - Java
Issue Type: Improvement
Components: Javadocs
Reporter: Mark Miller
Assignee: Uwe Schindler
Fix For: 2.9

Attachments: LUCENE-1877.patch, LUCENE-1877.patch

--
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Updated: (LUCENE-1877) Use NativeFSLockFactory as default for new API (direct ctors FSDir.open)


 [ 
https://issues.apache.org/jira/browse/LUCENE-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Miller updated LUCENE-1877:


Comment: was deleted

(was: Is that a bug? I can't even find that class ...)

 Use NativeFSLockFactory as default for new API (direct ctors  FSDir.open)
 --

 Key: LUCENE-1877
 URL: https://issues.apache.org/jira/browse/LUCENE-1877
 Project: Lucene - Java
  Issue Type: Improvement
  Components: Javadocs
Reporter: Mark Miller
Assignee: Uwe Schindler
 Fix For: 2.9

 Attachments: LUCENE-1877.patch, LUCENE-1877.patch


 A user requested we add a note in IndexWriter alerting the availability of 
 NativeFSLockFactory (allowing you to avoid retaining locks on abnormal jvm 
 exit). Seems reasonable to me - we want users to be able to easily stumble 
 upon this class. The below code looks like a good spot to add a note - could 
 also improve whats there a bit - opening an IndexWriter does not necessarily 
 create a lock file - that would depend on the LockFactory used.
 {code}  pOpening an codeIndexWriter/code creates a lock file for the 
 directory in use. Trying to open
   another codeIndexWriter/code on the same directory will lead to a
   {...@link LockObtainFailedException}. The {...@link 
 LockObtainFailedException}
   is also thrown if an IndexReader on the same directory is used to delete 
 documents
   from the index./p{code}
 Anyone remember why NativeFSLockFactory is not the default over 
 SimpleFSLockFactory?

-- 
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Issue Comment Edited: (LUCENE-1877) Use NativeFSLockFactory as default for new API (direct ctors FSDir.open)


[ 
https://issues.apache.org/jira/browse/LUCENE-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12750563#action_12750563
 ] 

Mark Miller edited comment on LUCENE-1877 at 9/2/09 10:58 AM:
--

heh - my jetlag is full effect - I wasn't looking at the lockdir, I was looking 
at:

{code}String lockClassName = 
System.getProperty(org.apache.lucene.store.FSDirectoryLockFactoryClass);
{code}

*edit

I'm too tired to be emailing - how about deprecating this one though?

  was (Author: markrmil...@gmail.com):
heh - my jetlag is full effect - I wasn't looking at the lockdir, I was 
looking at:

{code}String lockClassName = 
System.getProperty(org.apache.lucene.store.FSDirectoryLockFactoryClass);
{code}
  
 Use NativeFSLockFactory as default for new API (direct ctors  FSDir.open)
 --

 Key: LUCENE-1877
 URL: https://issues.apache.org/jira/browse/LUCENE-1877
 Project: Lucene - Java
  Issue Type: Improvement
  Components: Javadocs
Reporter: Mark Miller
Assignee: Uwe Schindler
 Fix For: 2.9

 Attachments: LUCENE-1877.patch, LUCENE-1877.patch


 A user requested we add a note in IndexWriter alerting the availability of 
 NativeFSLockFactory (allowing you to avoid retaining locks on abnormal jvm 
 exit). Seems reasonable to me - we want users to be able to easily stumble 
 upon this class. The below code looks like a good spot to add a note - could 
 also improve whats there a bit - opening an IndexWriter does not necessarily 
 create a lock file - that would depend on the LockFactory used.
 {code}  pOpening an codeIndexWriter/code creates a lock file for the 
 directory in use. Trying to open
   another codeIndexWriter/code on the same directory will lead to a
   {...@link LockObtainFailedException}. The {...@link 
 LockObtainFailedException}
   is also thrown if an IndexReader on the same directory is used to delete 
 documents
   from the index./p{code}
 Anyone remember why NativeFSLockFactory is not the default over 
 SimpleFSLockFactory?

-- 
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Commented: (LUCENE-1877) Use NativeFSLockFactory as default for new API (direct ctors FSDir.open)

[
https://issues.apache.org/jira/browse/LUCENE-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12750573#action_12750573
]

Uwe Schindler commented on LUCENE-1877:
---

It is indirectly deprecated, as it is only used, when FSDir.getDirectory() is
used. In all other cases NativeFSLockFactory is used or the given one. Maybe we
should add a note somewhere in javadocs. The same with the default FSDir class
property (its also indirectly deprecated.

I know the code is very ugly, but this is how it works :-(

Use NativeFSLockFactory as default for new API (direct ctors FSDir.open)
--

Key: LUCENE-1877
URL: https://issues.apache.org/jira/browse/LUCENE-1877
Project: Lucene - Java
Issue Type: Improvement
Components: Javadocs
Reporter: Mark Miller
Assignee: Uwe Schindler
Fix For: 2.9

Attachments: LUCENE-1877.patch, LUCENE-1877.patch

--
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Commented: (LUCENE-1877) Use NativeFSLockFactory as default for new API (direct ctors FSDir.open)


[ 
https://issues.apache.org/jira/browse/LUCENE-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12750581#action_12750581
 ] 

Mark Miller commented on LUCENE-1877:
-

Interesting - yeah, its hard to follow it all :) I havn't had a chance to apply 
and look at your patch either.

My main issue with it is that there a bunch of places where it says you can set 
the lock factory that way (not in deprecated javadoc sections). We should prob 
remove all those.

 Use NativeFSLockFactory as default for new API (direct ctors  FSDir.open)
 --

 Key: LUCENE-1877
 URL: https://issues.apache.org/jira/browse/LUCENE-1877
 Project: Lucene - Java
  Issue Type: Improvement
  Components: Javadocs
Reporter: Mark Miller
Assignee: Uwe Schindler
 Fix For: 2.9

 Attachments: LUCENE-1877.patch, LUCENE-1877.patch


 A user requested we add a note in IndexWriter alerting the availability of 
 NativeFSLockFactory (allowing you to avoid retaining locks on abnormal jvm 
 exit). Seems reasonable to me - we want users to be able to easily stumble 
 upon this class. The below code looks like a good spot to add a note - could 
 also improve whats there a bit - opening an IndexWriter does not necessarily 
 create a lock file - that would depend on the LockFactory used.
 {code}  pOpening an codeIndexWriter/code creates a lock file for the 
 directory in use. Trying to open
   another codeIndexWriter/code on the same directory will lead to a
   {...@link LockObtainFailedException}. The {...@link 
 LockObtainFailedException}
   is also thrown if an IndexReader on the same directory is used to delete 
 documents
   from the index./p{code}
 Anyone remember why NativeFSLockFactory is not the default over 
 SimpleFSLockFactory?

-- 
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

Re: svn commit: r810648 - /lucene/java/trunk/contrib/spatial/src/test/org/apache/lucene/spatial/tier/TestCartesian.java

2009-09-02 Thread Mark Miller

Thanks - sorry about that - was manually selecting files with subclipse
again and missed the test.

mikemcc...@apache.org wrote:
 Author: mikemccand
 Date: Wed Sep  2 18:20:13 2009
 New Revision: 810648

 URL: http://svn.apache.org/viewvc?rev=810648view=rev
 Log:
 LUCENE-1878: cutover TestCartesian to DistanceFieldComparatorSource

 Modified:
 
 lucene/java/trunk/contrib/spatial/src/test/org/apache/lucene/spatial/tier/TestCartesian.java

 Modified: 
 lucene/java/trunk/contrib/spatial/src/test/org/apache/lucene/spatial/tier/TestCartesian.java
 URL: 
 http://svn.apache.org/viewvc/lucene/java/trunk/contrib/spatial/src/test/org/apache/lucene/spatial/tier/TestCartesian.java?rev=810648r1=810647r2=810648view=diff
 ==
 --- 
 lucene/java/trunk/contrib/spatial/src/test/org/apache/lucene/spatial/tier/TestCartesian.java
  (original)
 +++ 
 lucene/java/trunk/contrib/spatial/src/test/org/apache/lucene/spatial/tier/TestCartesian.java
  Wed Sep  2 18:20:13 2009
 @@ -274,7 +274,7 @@
// As the radius filter has performed the distance calculations
// already, pass in the filter to reuse the results.
// 
 -  DistanceSortSource dsort = new DistanceSortSource(dq.distanceFilter);
 +  DistanceFieldComparatorSource dsort = new 
 DistanceFieldComparatorSource(dq.distanceFilter);
Sort sort = new Sort(new SortField(foo, dsort));
   
// Perform the search, using the term query, the serial chain filter, 
 and the


   


-- 
- Mark

http://www.lucidimagination.com




-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Commented: (LUCENE-1877) Use NativeFSLockFactory as default for new API (direct ctors FSDir.open)

[
https://issues.apache.org/jira/browse/LUCENE-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12750588#action_12750588
]

Michael McCandless commented on LUCENE-1877:

Patch looks good! I like the deprecation of FSDir.set/getDisableLocks and the
new FSLockFactory approach.

bq. Maybe we should add a note somewhere in javadocs. The same with the default
FSDir class property (its also indirectly deprecated

+1, I think we should deprecate these global system properties.

Use NativeFSLockFactory as default for new API (direct ctors FSDir.open)
--

Key: LUCENE-1877
URL: https://issues.apache.org/jira/browse/LUCENE-1877
Project: Lucene - Java
Issue Type: Improvement
Components: Javadocs
Reporter: Mark Miller
Assignee: Uwe Schindler
Fix For: 2.9

Attachments: LUCENE-1877.patch, LUCENE-1877.patch

--
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

Re: svn commit: r810648 - /lucene/java/trunk/contrib/spatial/src/test/org/apache/lucene/spatial/tier/TestCartesian.java

2009-09-02 Thread Michael McCandless

No problem!

Mike

On Wed, Sep 2, 2009 at 2:24 PM, Mark Millermarkrmil...@gmail.com wrote:
 Thanks - sorry about that - was manually selecting files with subclipse
 again and missed the test.

 mikemcc...@apache.org wrote:
 Author: mikemccand
 Date: Wed Sep  2 18:20:13 2009
 New Revision: 810648

 URL: http://svn.apache.org/viewvc?rev=810648view=rev
 Log:
 LUCENE-1878: cutover TestCartesian to DistanceFieldComparatorSource

 Modified:
     
 lucene/java/trunk/contrib/spatial/src/test/org/apache/lucene/spatial/tier/TestCartesian.java

 Modified: 
 lucene/java/trunk/contrib/spatial/src/test/org/apache/lucene/spatial/tier/TestCartesian.java
 URL: 
 http://svn.apache.org/viewvc/lucene/java/trunk/contrib/spatial/src/test/org/apache/lucene/spatial/tier/TestCartesian.java?rev=810648r1=810647r2=810648view=diff
 ==
 --- 
 lucene/java/trunk/contrib/spatial/src/test/org/apache/lucene/spatial/tier/TestCartesian.java
  (original)
 +++ 
 lucene/java/trunk/contrib/spatial/src/test/org/apache/lucene/spatial/tier/TestCartesian.java
  Wed Sep  2 18:20:13 2009
 @@ -274,7 +274,7 @@
        // As the radius filter has performed the distance calculations
        // already, pass in the filter to reuse the results.
        //
 -      DistanceSortSource dsort = new DistanceSortSource(dq.distanceFilter);
 +      DistanceFieldComparatorSource dsort = new 
 DistanceFieldComparatorSource(dq.distanceFilter);
        Sort sort = new Sort(new SortField(foo, dsort));

        // Perform the search, using the term query, the serial chain filter, 
 and the





 --
 - Mark

 http://www.lucidimagination.com




 -
 To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: java-dev-h...@lucene.apache.org



-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Commented: (LUCENE-1885) NativeFSLockFactory.makeLock(...).isLocked() does not work


[ 
https://issues.apache.org/jira/browse/LUCENE-1885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12750590#action_12750590
 ] 

Michael McCandless commented on LUCENE-1885:


Nice catch Uwe!

 NativeFSLockFactory.makeLock(...).isLocked() does not work
 --

 Key: LUCENE-1885
 URL: https://issues.apache.org/jira/browse/LUCENE-1885
 Project: Lucene - Java
  Issue Type: Bug
Reporter: Uwe Schindler
Assignee: Uwe Schindler
Priority: Blocker
 Fix For: 2.9


 IndexWriter.isLocked() or IndexReader.isLocked() do not work with 
 NativeFSLockFactory.
 The problem is, that the method NativeFSLock.isLocked() just checks if the 
 same lock instance was locked before (lock != null). If the LockFactory 
 created a new lock instance, this always returns false, even if its locked.

-- 
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Commented: (LUCENE-1878) remove deprecated classes from spatial


[ 
https://issues.apache.org/jira/browse/LUCENE-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12750594#action_12750594
 ] 

Michael McCandless commented on LUCENE-1878:


I'll take a crack at the javadocs...

 remove deprecated classes from spatial
 --

 Key: LUCENE-1878
 URL: https://issues.apache.org/jira/browse/LUCENE-1878
 Project: Lucene - Java
  Issue Type: Task
  Components: contrib/spatial
Reporter: Mark Miller
Assignee: Michael McCandless
Priority: Minor
 Fix For: 2.9

 Attachments: LUCENE-1878.patch


 spatial has not been released, so we can remove the deprecated classes

-- 
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Assigned: (LUCENE-1878) remove deprecated classes from spatial


 [ 
https://issues.apache.org/jira/browse/LUCENE-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael McCandless reassigned LUCENE-1878:
--

Assignee: Michael McCandless  (was: Mark Miller)

 remove deprecated classes from spatial
 --

 Key: LUCENE-1878
 URL: https://issues.apache.org/jira/browse/LUCENE-1878
 Project: Lucene - Java
  Issue Type: Task
  Components: contrib/spatial
Reporter: Mark Miller
Assignee: Michael McCandless
Priority: Minor
 Fix For: 2.9

 Attachments: LUCENE-1878.patch


 spatial has not been released, so we can remove the deprecated classes

-- 
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Commented: (LUCENE-1885) NativeFSLockFactory.makeLock(...).isLocked() does not work


[ 
https://issues.apache.org/jira/browse/LUCENE-1885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12750610#action_12750610
 ] 

Uwe Schindler commented on LUCENE-1885:
---

Thanks!

It was not so hard. After changing the default lock factory, a lot of tests 
were failing because of this.

 NativeFSLockFactory.makeLock(...).isLocked() does not work
 --

 Key: LUCENE-1885
 URL: https://issues.apache.org/jira/browse/LUCENE-1885
 Project: Lucene - Java
  Issue Type: Bug
Reporter: Uwe Schindler
Assignee: Uwe Schindler
Priority: Blocker
 Fix For: 2.9


 IndexWriter.isLocked() or IndexReader.isLocked() do not work with 
 NativeFSLockFactory.
 The problem is, that the method NativeFSLock.isLocked() just checks if the 
 same lock instance was locked before (lock != null). If the LockFactory 
 created a new lock instance, this always returns false, even if its locked.

-- 
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Created: (LUCENE-1887) o.a.l.messages should be moved/renamed

2009-09-02 Thread Hoss Man (JIRA)

o.a.l.messages should be moved/renamed
--

 Key: LUCENE-1887
 URL: https://issues.apache.org/jira/browse/LUCENE-1887
 Project: Lucene - Java
  Issue Type: Improvement
Reporter: Hoss Man
Priority: Minor
 Fix For: 2.9


contrib/queryParser contains an org.apache.lucene.messages package containing 
some generallized code that (claims in it's javadocs) is not specific to the 
queryParser.

If this is truely general purpose code, it should probably be moved out of hte 
queryParser contrib -- either into it's own contrib, or into the core (it's 
very small)

Alternately: if the code isn't super reusable, the package name should probably 
be changed to be a subpackage of  org.apache.lucene.queryParser ... it tends to 
be very confusing when all of the code in a contrib doesn't fall into a clear 
organizational namespace.

I've marked this issue for 2.9 so we at least think about it prior to release 
... it is a brand new public API, so this is out best chance to change it if we 
want ... but it is by no means a blocker for 2.9

-- 
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Updated: (LUCENE-1878) remove deprecated classes from spatial


 [ 
https://issues.apache.org/jira/browse/LUCENE-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael McCandless updated LUCENE-1878:
---

Attachment: LUCENE-1878.patch

Patch to add warnings about newness of this package to the javadocs.

 remove deprecated classes from spatial
 --

 Key: LUCENE-1878
 URL: https://issues.apache.org/jira/browse/LUCENE-1878
 Project: Lucene - Java
  Issue Type: Task
  Components: contrib/spatial
Reporter: Mark Miller
Assignee: Michael McCandless
Priority: Minor
 Fix For: 2.9

 Attachments: LUCENE-1878.patch, LUCENE-1878.patch


 spatial has not been released, so we can remove the deprecated classes

-- 
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Commented: (LUCENE-1887) o.a.l.messages should be moved/renamed

2009-09-02 Thread Adriano Crestani (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-1887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12750621#action_12750621
 ] 

Adriano Crestani commented on LUCENE-1887:
--

These classes have not relation with the queryparser code, the queryparser only 
uses it. Maybe in future other parts of lucene may start using it. So I vote to 
leave it outside queryParser package for now, and when other parts of lucene 
start using it, we can think about moving it to core.

 o.a.l.messages should be moved/renamed
 --

 Key: LUCENE-1887
 URL: https://issues.apache.org/jira/browse/LUCENE-1887
 Project: Lucene - Java
  Issue Type: Improvement
Reporter: Hoss Man
Priority: Minor
 Fix For: 2.9


 contrib/queryParser contains an org.apache.lucene.messages package containing 
 some generallized code that (claims in it's javadocs) is not specific to the 
 queryParser.
 If this is truely general purpose code, it should probably be moved out of 
 hte queryParser contrib -- either into it's own contrib, or into the core 
 (it's very small)
 Alternately: if the code isn't super reusable, the package name should 
 probably be changed to be a subpackage of  org.apache.lucene.queryParser ... 
 it tends to be very confusing when all of the code in a contrib doesn't fall 
 into a clear organizational namespace.
 I've marked this issue for 2.9 so we at least think about it prior to release 
 ... it is a brand new public API, so this is out best chance to change it if 
 we want ... but it is by no means a blocker for 2.9

-- 
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Updated: (LUCENE-1877) Use NativeFSLockFactory as default for new API (direct ctors FSDir.open)

[
https://issues.apache.org/jira/browse/LUCENE-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Uwe Schindler updated LUCENE-1877:
--

Attachment: LUCENE-1877.patch

Final patch.

I implemented additional:
- all FS-based lock factories use the same prefix encoding. They are now
(mostly) compatible. E.g. a lock obtained with NativeFSLockFactory would also
be seen as locked with SimpleFSLockFactory.
- Added LockFactory ctors with no param. The FSDir will set the lockdir to
itsself in this case.
- Added test for LUCENE-1885

Please test this extensively! I hope, I found all problems.

Use NativeFSLockFactory as default for new API (direct ctors FSDir.open)
--

Key: LUCENE-1877
URL: https://issues.apache.org/jira/browse/LUCENE-1877
Project: Lucene - Java
Issue Type: Improvement
Components: Javadocs
Reporter: Mark Miller
Assignee: Uwe Schindler
Fix For: 2.9

Attachments: LUCENE-1877.patch, LUCENE-1877.patch, LUCENE-1877.patch

--
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Issue Comment Edited: (LUCENE-1877) Use NativeFSLockFactory as default for new API (direct ctors FSDir.open)

[
https://issues.apache.org/jira/browse/LUCENE-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12750632#action_12750632
]

Uwe Schindler edited comment on LUCENE-1877 at 9/2/09 12:53 PM:

Final patch.

Please test this extensively! I hope, I found all problems.

was (Author: thetaphi):
Final patch.

Please test this extensively! I hope, I found all problems.

Use NativeFSLockFactory as default for new API (direct ctors FSDir.open)
--

Key: LUCENE-1877
URL: https://issues.apache.org/jira/browse/LUCENE-1877
Project: Lucene - Java
Issue Type: Improvement
Components: Javadocs
Reporter: Mark Miller
Assignee: Uwe Schindler
Fix For: 2.9

Attachments: LUCENE-1877.patch, LUCENE-1877.patch, LUCENE-1877.patch

--
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Commented: (LUCENE-1877) Use NativeFSLockFactory as default for new API (direct ctors FSDir.open)

[
https://issues.apache.org/jira/browse/LUCENE-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12750646#action_12750646
]

Michael McCandless commented on LUCENE-1877:

bq. E.g. a lock obtained with NativeFSLockFactory would also be seen as locked
with SimpleFSLockFactory.

This is neat, but I don't think we should advertise it?

Ie, it's unsupported to mix different LockFactory impls. EG, in this case, the
reverse is not true, right?

Use NativeFSLockFactory as default for new API (direct ctors FSDir.open)
--

Key: LUCENE-1877
URL: https://issues.apache.org/jira/browse/LUCENE-1877
Project: Lucene - Java
Issue Type: Improvement
Components: Javadocs
Reporter: Mark Miller
Assignee: Uwe Schindler
Fix For: 2.9

Attachments: LUCENE-1877.patch, LUCENE-1877.patch, LUCENE-1877.patch

--
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Commented: (LUCENE-1887) o.a.l.messages should be moved/renamed

2009-09-02 Thread Luis Alves (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-1887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12750706#action_12750706
 ] 

Luis Alves commented on LUCENE-1887:


+1 to keep outside parser.

These small utility classes are designed to handle Message translation, for the 
queryparser but can be used by any other component in lucene that wants to 
display translated resources.

 o.a.l.messages should be moved/renamed
 --

 Key: LUCENE-1887
 URL: https://issues.apache.org/jira/browse/LUCENE-1887
 Project: Lucene - Java
  Issue Type: Improvement
Reporter: Hoss Man
Priority: Minor
 Fix For: 2.9


 contrib/queryParser contains an org.apache.lucene.messages package containing 
 some generallized code that (claims in it's javadocs) is not specific to the 
 queryParser.
 If this is truely general purpose code, it should probably be moved out of 
 hte queryParser contrib -- either into it's own contrib, or into the core 
 (it's very small)
 Alternately: if the code isn't super reusable, the package name should 
 probably be changed to be a subpackage of  org.apache.lucene.queryParser ... 
 it tends to be very confusing when all of the code in a contrib doesn't fall 
 into a clear organizational namespace.
 I've marked this issue for 2.9 so we at least think about it prior to release 
 ... it is a brand new public API, so this is out best chance to change it if 
 we want ... but it is by no means a blocker for 2.9

-- 
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Commented: (LUCENE-1887) o.a.l.messages should be moved/renamed


[ 
https://issues.apache.org/jira/browse/LUCENE-1887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12750712#action_12750712
 ] 

Robert Muir commented on LUCENE-1887:
-

I agree it would be nice to have a package for localized messages in general.
In the future this leaves open the door for localization of other parts of 
lucene.

since it uses MessageFormat etc, I think it would be very reusable.


 o.a.l.messages should be moved/renamed
 --

 Key: LUCENE-1887
 URL: https://issues.apache.org/jira/browse/LUCENE-1887
 Project: Lucene - Java
  Issue Type: Improvement
Reporter: Hoss Man
Priority: Minor
 Fix For: 2.9


 contrib/queryParser contains an org.apache.lucene.messages package containing 
 some generallized code that (claims in it's javadocs) is not specific to the 
 queryParser.
 If this is truely general purpose code, it should probably be moved out of 
 hte queryParser contrib -- either into it's own contrib, or into the core 
 (it's very small)
 Alternately: if the code isn't super reusable, the package name should 
 probably be changed to be a subpackage of  org.apache.lucene.queryParser ... 
 it tends to be very confusing when all of the code in a contrib doesn't fall 
 into a clear organizational namespace.
 I've marked this issue for 2.9 so we at least think about it prior to release 
 ... it is a brand new public API, so this is out best chance to change it if 
 we want ... but it is by no means a blocker for 2.9

-- 
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

[jira] Updated: (LUCENE-1876) Some contrib packages are missing a package.html