> Shalin Shekhar Mangar commented on
> Why should the dataDir be a special thing? Why not support JNDI values for all properties implicitly? We currently support two kinds of properties, the ones defined in solr.xml and the environment variables. As a logical extension, we can add JNDI variables too so that we don't need to duplicate JNDI properties again in solr.xml.
Er, in fact I don't think dataDir is a special thing... I think any JNDI
configuration is special thing, if it has the same meaning with a system
The dataDir is just a example — I added it just because it's the only
specificated one in the wiki document.
But I opposite to the concept of refering properties and JNDI values in
for example, if <dataDir>$
/data</dataDir> are both supported
which is the one I should put into the solrconfig.xml?
There might be two solr servers using this configuration... one of them has
a JNDI home, and the other one is started from command line.
I think the problem is what we needed in configuration files is not a
parameter from somewhere, but a server's status in fact.
The server can be installed with a console parameter, with a JNDI context
file, or with hardcode in web.xml, it's doesn't matter.
I just want to know where the server's home is.
So, we either map both the JNDI value and system property into a same system
status variable, or just use properties to do this, and map JNDI values to
That's why I only enabled JNDI lookup in property values.
If you think hardcode mapping into Config.java is to ugly, maybe a mapping
properties file in solr home dir will be a better choise?
Anyway, thanks for replying
> I guess the property syntax will need to be changed a bit because ':' is used for default values. We can either escape the ':' in JNDI name or we can make the DOMUtil.substituteProperty method aware of this change.
Yes, I totally agree with this.