[PATCH] Differently configured Lucene 'instances' in same JVM

• Key: LUCENE-636
• Type: Improvement
• Status: Reopened
• Priority: Major
• Assignee: Unassigned
• Reporter: Johan Stuyts
• Affects Version/s: 2.0.0

Description

Currently Lucene can be configured using system properties. When running multiple 'instances' of Lucene for different purposes in the same JVM, it is not possible to use different settings for each 'instance'.

I made changes to some Lucene classes so you can pass a configuration to that class. The Lucene 'instance' will use the settings from that configuration. The changes do not effect the API and/or the current behavior so are backwards compatible.

In addition to the changes above I also made the SegmentReader and SegmentTermDocs extensible outside of their package. I would appreciate the inclusion of these changes but don't mind creating a separate issue for them.

Comments

[Johan Stuyts]

Patch which includes a class for the Lucene configuration and changes to existing classes so they use the configuration.

[Johan Stuyts]

I just found out that the patch is incomplete. You can only specify the subclass of the SegmentReader class, but not the subclass of the MultiReader class. If your index contains multiple segments a MultiReader instead of the specified subclass of SegmentReader is created, and it is not possible to cast the returned IndexReader to the subclass of SegmentReader you specified in the LuceneConfig object.

[Ken Geis]

I was able to work around this problem by using AspectJ to intercept calls to System.setProperty(..) and System.getProperty(). This is not a great solution.

A side note... Tomcat on Ubuntu ships with the security manager turned on by default, a strangely uncommon setting for servlet engine distributions. The default security settings prevent a webapp from calling System.setProperty(..).

It would be nice if this got resolved sometime soon because once it is resolved, I need to wait for Compass to pick up the change downstream. It looks like it may be a year until I don't need to worry about this issue any more.

[Otis Gospodnetic]

We've moved away from using system properties. I think there are only a couple of places in the code that still refer to system properties, and those are, I believe, depreated:

$ ffjg System.getProp
./org/apache/lucene/analysis/standard/ParseException.java: protected String eol = System.getProperty("line.separator", "\n");
./org/apache/lucene/index/SegmentReader.java: System.getProperty("org.apache.lucene.SegmentReader.class",
./org/apache/lucene/queryParser/ParseException.java: protected String eol = System.getProperty("line.separator", "\n");
./org/apache/lucene/store/FSDirectory.java: public static final String LOCK_DIR = System.getProperty("org.apache.lucene.lockDir",
./org/apache/lucene/store/FSDirectory.java: System.getProperty("java.io.tmpdir"));
./org/apache/lucene/store/FSDirectory.java: System.getProperty("org.apache.lucene.FSDirectory.class",
./org/apache/lucene/store/FSDirectory.java: String lockClassName = System.getProperty("org.apache.lucene.store.FSDirectoryLockFactoryClass");
./org/apache/lucene/util/Constants.java: /** The value of <tt>System.getProperty("java.version")<tt>. **/
./org/apache/lucene/util/Constants.java: public static final String JAVA_VERSION = System.getProperty("java.version");
./org/apache/lucene/util/Constants.java: /** The value of <tt>System.getProperty("os.name")<tt>. **/
./org/apache/lucene/util/Constants.java: public static final String OS_NAME = System.getProperty("os.name");

I'll close this as Won't Fix.

[Ken Geis]

This is not going to be sufficient. There are active code paths that still use System.getProperty(..). For instance, the static initializers of FSDirectory and SegmentReader.

If I load up a Compass-based web app, and it uses an old version of Lucene that works off system properties, it will set the org.apache.lucene.SegmentReader.class property to use a Compass-specific segment reader. Then in another web app that uses a current version of Lucene that has "moved away from using system properties," the application will crash when it tries to load the SegmentReader class.

[Hoss Man]

I think Ken is right, while most of the uses are for debugging or in legacy methods that have newer ways callers can specify the exact behavior they want programmaticly, these two do not, and warrant leaving the issue open (at the very least)...

/org/apache/lucene/index/SegmentReader.java: System.getProperty("org.apache.lucene.SegmentReader.class",
./org/apache/lucene/store/FSDirectory.java: System.getProperty("org.apache.lucene.FSDirectory.class",

[Mark Miller]

Both of the properties Hoss mentioned are now deprecated - I think we can close this issue unless some new one has managed to pop up (I'm not aware of one myself)

[Ken Geis]

I would not close this until the code is removed, not just its use deprecated. Even if it is deprecated, I can write a new application with the code from svn trunk (as of right now,) and the SegmentReader or FSDirectory implementation can be overridden by an old application (in the same servlet container) that sets the system property.