[
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
