[ 
https://issues.apache.org/jira/browse/LUCENE-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475151
 ] 

Matthias Kerkhoff commented on LUCENE-812:
------------------------------------------

>From the perspective of Lucene user I would like to add ...
- if you leave the code in there, it should work (which should be doable, the 
missing argument is the lock directory, which defaults to the index directory 
or, if present, from $org.apache.lucene.lockdir). Currently there is not a 
single LockFactory that will NOT cause an InstantiationException.
- if the code is a leftover from some intermediate nightly snapshot, remove it 
and remove any reference to the system property too.

I can live with both scenarios. I just entered this issue as I thought that the 
behaviour of the code ... is a bit unexpected. In the end, if the system 
property is set to whatever value lucene is unable to create an FSDirectory and 
FSDirectory based IndexSearchers.


> 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
>
> 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]

Reply via email to