: A simple solution might be a 'classname' setup for the Document : creation - like the default Directory implementation uses. As long as : the subclass has a no-arg ctor it is trivial.
a differnet tack on the topic: there is really no good reason why the "Document" class used for indexing data should be the same as the "Document" classs ued for returning results ... using the same class in this way results in all sort of confusio abotu which methods can be called in which context, and frequently leads people to assume they can do safe "round trips" of their Documents ... doing a search, modifying a field value, and then re-inexing it -- not considering what happens to non-STOREd fields or field/document boosts. any work done to change the Document API to make it easier to subclass should probably start with a seperation of these too completley different concepts. One approach off the top of my head: make an IndexableDocument interface for clients to pass to IndexWriter and a "ReturnableDocument" class for IndexReader/IndexSearcher to return ... the existing Document class can subclass ReturnableDocument and impliment IndexableDocument, the existing methods with Document in their sig would be deprecated and replaced with methods using one of these new class names -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
