lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-812) Unable to set LockFactory implementation via ${org.apache.lucene.store.FSDirectoryLockFactoryClass}
Date Mon, 26 Feb 2007 18:30:05 GMT

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


Mime
View raw message