lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <e...@ehatchersolutions.com>
Subject Re: Configuration features, Solr2/Spring & Solr1.x future
Date Fri, 12 Sep 2008 13:01:25 GMT

On Sep 12, 2008, at 7:43 AM, Henrib wrote:
> Now, that's clearer! :-)
>
>
> Erik Hatcher wrote:
>>
>>>> actually, configuration _should_ be code :)
>> The above shows a way to programmatically create ...
>> ...affect settings could be done without resorting to XML gymnastics.
>> ... dynamic  configuration...
>> it's that XML middleman  that annoys me.
>>

I like how you summarized my post :)

> So, if we were to have Java classes equivalents of what is contained  
> in
> solr.xml, schema.xml or solrconfig.xml, would that be enough (or at  
> least a
> good enough first step)? Say a SchemaDescriptor and  
> SolrConfigDescriptor
> where all the XML attributes & nodes would be transformed into their  
> Java
> equivalents, would this fit your dynamic needs ?

I haven't given any consideration to exactly what kind of API changes  
are needed, but certainly being able to build an IndexSchema without  
XML being involved would be the result of such a refactoring.

> This alone would allow to completely configure a Solr installation  
> without
> any file, only code. And serializing in from XML to instances of  
> these would
> still be possible; this could almost imply that XML configuration  
> would
> become a "contrib". For that matter, even Spring configuration whether
> programmatic or XML could be a contrib.

Sure enough - that would be the ideal in my opinion.

Though not entirely sure about all configuration being a "contrib".   
Practically speaking we still want Solr to have some kind of defacto  
"out of the box" experience that doesn't require someone writing  
MyConfigurationPlugin.java, in a supportable built-in way.  Tthere is  
value in having some static configuration to bootstrap a Solr server.

> And this would pave the way to "externalize" integration/deployment
> features.
> Am I getting this more or less correctly ?

You got it.

And this is why it has been hard for me to really embrace <include>  
mechanisms and other such XML trickery.  It's all clever stuff, no  
question.  But Solr is a search server, and (re)inventing  
configurators really belongs elsewhere.

	Erik


Mime
View raw message