lucene-dev mailing list archives

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

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

Hoss Man commented on LUCENE-812:
---------------------------------

> Actually it was your response to the original proposal for the LockFactory changes that
caused me to 
> leave the system property path in there :)

really ?... oh man, i feel silly -- I *think* I was refering to the making sure that long
standing "org.apache.lucene.FSDirectory.class" system property still worked for backwards
compatibility ... but June 2006 was a long time ago, who knows what i was thinking :)

having a system property for the LockFactory is al fine and dandy, just as long as people
realize it doesn't work with most of the out-of-the-box LockFactories since they have constructor
args.

if we *wanted* to be really aggresive about supporting system props for things like this,
there are probably things we could do to make it work better -- but i don't think we should
aggresivly support using system props to set things like this.  as long as we have setters
for things, client code can use system properties all it wants to set these things.

> 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