As I'm sure you are all aware, nearly all Solr plugins that are configurable will receive that configuration in the form of a NamedList, likely via also implementing NamedListInitializedPlugin. Analysis components don't because that's Lucene stuff (no NamedList there) -- they take a Map constructor argument. I stumbled on a new breed of plugins doing something different (was worthy of a dev list discussion; alas). The so-called "Container Plugins"[1], (ex: for replica Placement Plugins) have a unique scheme -- ConfigurablePlugin added via SOLR-14977[2]. I don't see that it was necessary to have yet another scheme. Nevertheless, I like it; it allows typed configuration and automatic XML/JSON conversion to a typed object. It feels modern. I'm raising this here to discuss harmonizing plugin configuration. I don't like a fractured disharmonious system of partially pursued ideas. Embrace this new idea or extinguish it. Or a hybrid. It warranted a dev list discussion in the first place.
Proposal "A": Let a plugin author choose between old and new approaches merely by implementing either interface. **Don't force the decision by plugin type; unlike today**. Imagine a general plugin configuration initializing mechanism that looks at what the plugin implements (NamedListInitializedPlugin or ConfigurablePlugin) and configures it appropriately, whether the input be a NamedList (from XML parsing, most likely) or some JSON Map -- either way, cross directions? Proposal "B": Back out ConfigurablePlugin in lieu of NamedList/NamedListInitializedPlugin for ideal harmony. *But*, I could imagine a general utility that a specific plugin author could use to convert the NamedList to a custom object of their choosing without requiring the ConfigurablePluginType interface. Thus at a glance there is familiarity (NamedList) yet we can still have new toys of object mapping. Maybe others have ideas / comments. I think I prefer proposal "B". [1] We may want to rename "Container Plugin" to "Node Plugin" to use vernacular understood by Solr users; they don't know what a "container" is. Not to mention we regret that "container" name so let's stop using it? After all, NodeConfig is called that, not ContainerConfig. [2] https://issues.apache.org/jira/browse/SOLR-14977?focusedCommentId=17799932&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17799932 ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley