: >From the user perspective: a public constructor would be the most : obvious, and would be consistent with RAMDirectory.
A lot of the cases where system properties are currently used can't really be solved this way because the client isn't the one constructing the object. SegmentReader's IMPL for example needs to be set "globally" so that the correct concrete class is used when a MultiSegmentReader goes to open each segment. In the case of FSDirectory.getDirectory a static cache f Directory objects is maintained to ensure only one Directory object exists at any given time per File. : > I think we really should open up a non-static way to choose a different : > FSDirectory impl? EG maybe add optional Class to FSDirectory.getDirectory? : > Or maybe give NIOFSDirectory a public ctor? Or something? A factory/provider pattern could work, but that makes the above mentioned caching complicated (what if one call to getDirectory for /tmp/index wants an NIOFSDirectory and another wants a MyFSDirectory?) since the choice of FSDirectory varient is largly going to be based on OS, I can't think of any reason why a static setter method wouldn't be good enough in this particular case. past discussion about alternate options for clients to control things these things beyond using system properties... http://issues.apache.org/jira/browse/LUCENE-636 http://www.nabble.com/Back-Compatibility-to14918202.html#a15027970 ...and some replies. -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
