Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Message-ID: <23236625.1172175305784.JavaMail.jira@brutus>
Date: Thu, 22 Feb 2007 12:15:05 -0800 (PST)
From: "Hoss Man (JIRA)" <jira@apache.org>
To: java-dev@lucene.apache.org
Subject: [jira] Commented: (LUCENE-812) Unable to set LockFactory
 implementation via ${org.apache.lucene.store.FSDirectoryLockFactoryClass}
In-Reply-To: <8957339.1172153165537.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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