https://issues.apache.org/jira/browse/SOLR-2119 is a good example
where we are failing to catch mis-configuration on startup.

Is there some way we can baby step here?  EG use one of these XML
validation packages, incrementally, on only sub-strings from the XML?
(Or simpler is to just do the checking ourselves w/ custom code).

Mike

http://blog.mikemccandless.com

On Wed, May 4, 2011 at 10:50 PM, Michael Sokolov <soko...@ifactory.com> wrote:
> I'm not sure you will find anyone wanting to put in this effort now, but
> another suggestion for a general approach might be:
>
> 1 very basic static analysis to catch what you can - this should be a pretty
> minimal effort only given what can reasonably be achieved
>
> 2 throw runtime errors as Hoss says (probably already doing this well
> enough, but maybe some incremental improvements are needed?)
>
> 3 an option to run a "configtest" like httpd provides that preloads all
> declared handlers/plugins/modules etc, instantiates them and gives them an
> opportunity to read their config and throw whatever errors they find.  This
> way you can set a standard (error on unrecognized parameter, say) in some
> core areas, and distribute the effort.  This is a hugely useful sanity check
> to be able to run when you want to make config changes and not have your
> server fall over when it starts (or worse - later).
>
> -Mike "kibitzer" Sokolov
>
> On 5/4/2011 6:55 PM, Chris Hostetter wrote:
>>
>> As i said: any improvements to help catch the mistakes we can identify
>> would be great, but we should maintain perspective of the effort/gain
>> tradeoff given that there is likely nothing we can do about the basic
>> problem of "a string that won't be evaluated until runtime"
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to