lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <>
Subject Re: Configuration features, Solr2/Spring & Solr1.x future
Date Fri, 12 Sep 2008 09:39:16 GMT
On Sep 11, 2008, at 4:51 PM, Henrib wrote:
>> actually, configuration _should_ be code :)
>> there is currently too much code to parse and manage various schemes
>> of loading a configuration, making things less easily dynamic and  
>> fun.
>> 	Erik
> Are you saying Guice versus Spring ?

No - though that would be an interesting consideration.  Though most  
usages of annotations are hideous, IMO.

And I don't really think a Spring XML configuration file is the good  
way to configure Solr - way too complex to put in front of someone  
that just wants to add a new text field.  Spring integration itself,  
as far as Solr is concerned, will really be an exercise in redesigning  
the Solr API to be more pluggable - and the Spring configuration  
really should only be one optional way to control things.  So I'm pro- 
API refactoring, and the mechanisms to configure it aren't as  
important to me personally since that'll be pluggable.

> Like no XML config, only Java config ?
> Not sure I understand; can you elaborate just a little ?

I'm being a bit idealistic here, and speaking from a Rubyist  
perspective, but something like this....

   data_directory = '/opt/solr/data'  # make this as dynamic as you  

   categories = [:electronics, :books, :music, :videos]
   categories.each do |category|
     request_handlers << {"/#{category}" => {:fq =>  

The above shows a way to programmatically create multiple request  
handlers each constraining to a specific category - just a simple  
example that came to mind as something I'd want to do that isn't  
cleanly possible now without a lotta copy/paste.

And thus data_directory could be set programmatically, and any  
contortions on environment variables, system properties, or other  
custom data to affect settings could be done without resorting to XML  

The above is just off the top of my head kinda stuff, not working  
code.  But the below is from a real working prototype I built and  
threw away that brings up an EmbeddedSolrServer with a dynamic  
configuration.  Under the covers is some ugly XML generation, creating  
an XML string to feed into the IndexSchema constructor (in JRuby,  
using a likely outdated Solr API):

     # schema_model builds an XML string in its to_s method
     schema =,
     core = "data_dir", config, schema
     server =

     # test out the new schema with some test data
     request ="test.csv")  # a custom Ruby class  
subclassing SolrJ's RequestBase
     response = server.request(request)

So even code generation of an XML file with the current API is enough  
to provide some really dynamic techniques, it's that XML middleman  
that annoys me.


View raw message