lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <>
Subject [jira] Commented: (LUCENE-812) Unable to set LockFactory implementation via ${}
Date Thu, 22 Feb 2007 17:31:05 GMT


Michael McCandless commented on LUCENE-812:

The no-argument constructors for Native/SimpleFSLockFactory were
removed as part of LUCENE-771 (store write.lock in index directory by
default).  These APIs were never released (ie only available in the
trunk builds).

Since there is no longer a notion of the "global default lock
directory", I'm not really sure how to (or whether to) fix this: these
lock factories really need to know the directory to store their lock
files in.

The fallback is to instantiate the LockFactory ahead of time and pass
it into FSDirectory.getDirectory().  Is that fallback workable here?

I'd lean towards "won't fix" on this unless someone can suggest a good
solution.  That property can still be used for other lock factory
instances that require no arguments on construction.

> Unable to set LockFactory implementation via ${}
> ---------------------------------------------------------------------------------------------------
>                 Key: LUCENE-812
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: Store
>    Affects Versions: 2.1
>            Reporter: Matthias Kerkhoff
> 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
> ${} to "".
> 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(...)

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:
For additional commands, e-mail:

View raw message