lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uri Boness (JIRA)" <>
Subject [jira] Commented: (SOLR-1668) Declarative configuration meta-data for Solr plugins
Date Fri, 18 Dec 2009 12:34:18 GMT


Uri Boness commented on SOLR-1668:


Also note that Ant's configuration mechanism isn't just with setters. A <java> task
for example can take any number of <sysproperty> sub-elements, and they get "injected"
via addSysproperty(Environment.Variable sysp). 

System properties can be supported in 2 ways:
1. On the configuration level using an expression language (a la Spring... yes.. Spring supports
it :-)). This means that in the schema you'll be able to configure properties like: stopWordFile="${conf.dir}/stopwords.txt".
the "conf.dir" parameter can be replaced either from system properties, properties file, or
other source. Eventually these properties  
2. Using another annotation (say, @SystemProperty) which indicates the value should first
be taken from the system properties and then converted to the required data type

bq.It's the specifying of the converter class in the annotation that I don't like. It can
be more implicit than that, like "magic"

The @Converter annotation is mainly aimed for user extensions. Indeed all the out-of-the-box
plugins don't need to have it as default converters can be pre-registered to handle all the
data types we need at the moment. For users who want to provide their own plugins, we need
to provide them a simple mechanism to register converters and I found the @Converter annotation
to be the simplest one.

bq. We'd have setStopWordList(SolrFile f), and we'd only that setter after the system properties
were in the mix. 
As you said, I believe once we have system properties supported this will be a no brainer
and indeed I believe this belongs to an earlier "properties substitution" phase (as mentioned


bq. is there anyone building it?
Oh yes :-), but beyond that, this will open up opportunities to develop plugins to IDE's/TextEditors
for Solr... even just for better support in writing the schema files with auto-completion,
validation, etc...

bq. Why do we need this magic in String-> Object conversion at all? 
Well, my obvious response is because of the nature of Solr configuration which is text based
while at runtime you're dealing with other data types. Of course you can just create String
setters and do the conversion yourself, but why do that if you can have done automatically
and keep your classes clean. Just to be clear, the magic is not really "magic" we can be very
clear about what converters are supported out of the box and (as I mentioned above) with the
@Converter annotation users can be more explicit in how they want the conversion to take place.
Bottom line, in the end of the day you want to be able to focus and write the plugins as POJO's
 using properties of the correct data types and focus on the plugin's logic rather than also
focusing on configuration logic. 

> Declarative configuration meta-data for Solr plugins
> ----------------------------------------------------
>                 Key: SOLR-1668
>                 URL:
>             Project: Solr
>          Issue Type: Improvement
>          Components: Schema and Analysis
>    Affects Versions: 1.4
>            Reporter: Uri Boness
>            Priority: Minor
>             Fix For: 1.5
>         Attachments: commons-beanutils-1.8.2.jar, SOLR-1668.patch
> The idea here is for plugins in Solr to carry more meta data over their configuration.
This can be very useful for building tools around Solr where this meta data can be used to
assist users in configuring solr. One common mechanism to provide this meta data is by using
standard Java Beans for the different configuration constructs where the properties define
the configurable attributes and annotations are used to provide extra information about them.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message