[
https://issues.apache.org/jira/browse/SOLR-1668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12792454#action_12792454
]
Uri Boness commented on SOLR-1668:
----------------------------------
@Erik
{quote}
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).
{quote}
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 above).
@Noble
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: https://issues.apache.org/jira/browse/SOLR-1668
> 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.
