Hey James Thanks for the quick reply!
I already read the comments on SOLR-2115, was just not sure if the case was not describe and therefore not really existing or maybe just forgotten - so to confirm, what doesn't work is, having a configfile defined in solrconfig and still overwrite that with a provided configuration by request, right? On Friday, January 11, 2013 at 11:06 PM, Dyer, James wrote: > I don't mean to discourage you but I was kinda hoping if SOLR-4151 was left > for dead long enough and people got used to it not being there we could just > kill DebugLogger... I'm completely fine with that James, no worries :) I never used it my self, i just took it into work while working on other dataimport things at the UI .. if you like to drop that, we could easily revert that port of the work and avoid people start using it (again) because "it's there" Stefan On Friday, January 11, 2013 at 11:06 PM, Dyer, James wrote: > The behavior was changed in 4.0-ALPHA with SOLR-2115. See especially my > comment from July 20, 2012. There are 3 important changes here: > - you can specify a new data-config.xml filename or location on the request > using the "config" parameter. You do not need to put one in solrconfig.xml, > but still may to have a default. > - As an alternate to using a data-config.xml file, you can always pass a full > configuration on the request using the "dataConfig" parameter. You used to be > able to do that only if in "debug" mode. > - the data-config.xml is always parsed and re-loaded with each import. This > makes it unnecessary to issue "reload-config" every time you want to use a > new configuration. I think "debug" mode used to do this also, but now it > always does this. > > Although I'm probably the one person doing the most work on DIH code > currently, I've never used the interactive debug mode. Its sort of documented > a little at > http://wiki.apache.org/solr/DataImportHandler#Interactive_Development_Mode . > The most important aspect of it is it activates all of that "DebugLogger" > code that is everywhere cluttering up DIH. I think the interactive screens > are supposed to take in all of those log messages and do something with them > graphically for the user. > > I don't mean to discourage you but I was kinda hoping if SOLR-4151 was left > for dead long enough and people got used to it not being there we could just > kill DebugLogger... > > James Dyer > E-Commerce Systems > Ingram Content Group > (615) 213-4311 > > > -----Original Message----- > From: Stefan Matheis [mailto:[email protected]] > Sent: Friday, January 11, 2013 3:36 PM > To: [email protected] (mailto:[email protected]) > Subject: DIH - Using temporary Config from Request-Parameter, partial broken? > > Hey Guys > > While working on SOLR-4151 (DIH 'debug' mode missing from 4.x UI) i skimmed > through the code and found this one: > > 129 | if (DataImporter.SHOW_CONF_CMD.equals(command)) { > 130 | String dataConfigFile = params.get("config"); > 131 | String dataConfig = params.get("dataConfig"); > 132 | if(dataConfigFile != null) { > 133 | dataConfig = > SolrWriter.getResourceAsString(req.getCore().getResourceLoader().openResource(dataConfigFile)); > 134 | } > 135 | if(dataConfig==null) { > 136 | rsp.add("status", DataImporter.MSG.NO_CONFIG_FOUND); > 137 | } else { > 138 | // Modify incoming request params to add wt=raw > > > > > > > from > http://svn.apache.org/viewvc/lucene/dev/trunk/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/DataImportHandler.java?view=markup > > What it *should* do, related to the Description of the Issue (SOLR-2115), is: > accept a temporary Config (provided by a Request-Parameter) and use it > instead of the defined one .. but, as fair as i understand the code: any > provided Config will get overwritten if there is a ConfigFile defined in your > solrconfig. > > There is no check in place, that this fallback should only happen if there > was no (temporary) configuration given .. or am i missing something really > important but maybe not completely obvious here? > > Stefan > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > (mailto:[email protected]) > For additional commands, e-mail: [email protected] > (mailto:[email protected]) > > > B‹KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB•È[œÝXœØÜšX™KK[XZ[ˆ]‹][œÝXœØÜšX™PXÙ[™K˜\XÚK›Ü™ÃB‘›ÜˆY][Û˜[ÛÛ[X[™ËK[XZ[ˆ]‹Z[XÙ[™K˜\XÚK›Ü™ÃBƒB > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
