Simon: > Sanne, I would recommend you building a Factory pattern around you > Analyzers / TokenStreams similar to what solr does. That way you can > load you own "default ctor" interface via reflection and obtain you > analyzers from those factories. That makes more sense anyway as you > only load the factory via reflection an not the analyzers.
As far as I see, Hibernate uses Solr Factories. On the other hand, you can instead of creating your own SolrAnalyzer also use a "standard" one from Lucene (you can do this in Solr, too): http://docs.jboss.org/hibernate/stable/search/reference/en/html_single/#analyzer In my opinion, the Factory pattern is ok for own analyzer definitions. For reusing "standard" analyzers like "StandardAnalyzer" or "TurkishAnalyzer", the ideal case is to use the reflection code I proposed before. This code works for all language-based analyzers having a standard ctor or Version ctor. Solr will also handle this reflection-based instantiation with optional Version parameter in future, too (Eric Hatcher pointed that out to me, when working on SOLR-1677: "Another comment on this... Solr supports using an Analyzer also, but only ones with zero-arg constructors. It would be nice if this Version support also allowed for Analyzers (say SmartChineseAnalyzer) to be used also directly. I don't think this patch accounts for this case, does it?"). As Hibernate also uses the factory pattern for custom analyzers, as soon as https://issues.apache.org/jira/browse/SOLR-1677 is in, the version problem for those should be solved, too (as you can specify the parameter to each component). But Hibernate should also think about a global default Version (like Solr via CoreAware or like that), that is used as a default param to all Tokenizers/TokenFilters and when reflection-based Anaylzer subclass instantiation is used. By the way, hibernate's reuse of Solr's schema is one argument of Hoss, not to make it CoreAware. Uwe --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
