[ 
http://jira.codehaus.org/browse/MINDEXER-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=262660#action_262660
 ] 

Tamás Cservenák commented on MINDEXER-26:
-----------------------------------------

As I see from NetBeans issue, this NPE happened _within_ DefaultIndexingContext 
constructor, so I would rule out that same context's -- that is just being 
constructed -- close() method was called. This code is called from constructor, 
and having indexDirectory {{null}} means something really bad.

{{close()}} method contains null check to make possible calling it multiple 
times without any problem (closing already closed context does nothing, is 
harmless).

According stack trace and Affects version, the DefaultIndexingContext with File 
parameter is called (this rules out calling another constructor with {{null}} 
Directory as parameter). But here, that would mean {{FSDirectory.open()}} 
returns {{null}}, which again seems unlikely after inspecting the code.


...unless {{warmUp( NexusIndexSearcher searcher )}} failed with IOException. It 
seems we "eat" some information here...

> NPE from IndexWriter.isLocked in DefaultIndexingContext.prepareCleanIndex
> -------------------------------------------------------------------------
>
>                 Key: MINDEXER-26
>                 URL: http://jira.codehaus.org/browse/MINDEXER-26
>             Project: Maven Indexer
>          Issue Type: Bug
>    Affects Versions: 4.0.0
>         Environment: VM: Java HotSpot(TM) 64-Bit Server VM, 19.0-b09, 
> Java(TM) SE Runtime
> Environment, 1.6.0_23-b05
> OS: Windows 7
>            Reporter: Jesse Glick
>
> http://netbeans.org/bugzilla/show_bug.cgi?id=197346 reported by a NetBeans 
> user in a build embedding Maven Indexer 4.0.0.
> {noformat}
>             if ( IndexWriter.isLocked( indexDirectory ) )
>             {
>                 IndexWriter.unlock( indexDirectory );
>             }
> {noformat}
> Looks like {[indexDirectory}} is null, perhaps due to {{close}} having been 
> called, and this code does not check for that (other code in the same class 
> does). Can probably be guarded with a simple null check?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira


Reply via email to