[
https://issues.apache.org/jira/browse/LUCENE-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475937
]
Michael McCandless commented on LUCENE-812:
-------------------------------------------
One of the original motivations of this property was the ability to
also choose LockFactory implementations external to Lucene (the
original issue had a lock factory that used MySQL for locking). So
the property is still useful for that use-case.
Unfortunately we can't deprecate this (there is no compiler/runtime
support for deprecating a random property?). I guess we could remove
support for it (in 2.2 or 2.1.1?) and throw an exception if we see
that the property is set (to catch users who had started using it) but
that seems rather harsh.
So ... I think we should in fact support it (but in the future we
should not add any more new System properties to Lucene, I think).
I plan to modify Simple/NativeFSLockFactory to have no arg constructor
that sets their lockDir to null, and then add logic to
FSDirectory.getDirectory to set its own dir as the lockDirName if it
sees that the incoming LockFactory is one of these two instances with
a null lockDir.
The other 2 builtin LockFactory implementations already have no-arg
constructors so they work fine through this property.
> 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]
