We are using DIH in production . It is a planned feature for 1.3 realease. Let us see when it happens --Noble
On Thu, Jun 19, 2008 at 7:35 PM, William Silva <[EMAIL PROTECTED]> wrote: > Hi, > Are you using DataImportHandler in a production environment ? > When it will be available in the nightly builds ? > Thanks, > William. > > > On Thu, Jun 19, 2008 at 3:12 AM, Noble Paul നോബിള് नोब्ळ् < > [EMAIL PROTECTED]> wrote: > >> We plan to use SolrResourceLoader (in the next patch) . That is the >> best way to go. >> >> But we still prefer the usage of DIH package classes without any prefix. >> type="HttpDataSource" >> instead of >> type="solr.HttpDataSource" >> >> But users must be able to load their classes using the "solr.<classname>" >> format >> --Noble >> >> >> On Thu, Jun 19, 2008 at 10:57 AM, Chris Hostetter >> <[EMAIL PROTECTED]> wrote: >> > >> > : aah!. We always assumed that people put the custom jars in the >> > : WEB-INF/lib folder of solr webapp and hence they are automatically in >> > : the classpath we shall make the necessary changes . >> > >> > It would be better to use the classloader from the SolrResourceLoader ... >> > that should be safe for anyone with any setup. >> > >> >>> DIH does not load class using the SolrResourceLoader. It tries a >> >>> Class.forName() with the name you provide if it fails it prepends >> >>> "org.apache.solr.handler.dataimport." and retries. >> > ... >> >>> The reason for doing so is that we do not use any of the 'solr.' >> >>> packages in DIH. All our implementations fall into the default package >> >>> and we can directly use them w/o the package name. >> > >> > FWIW: there isn't relaly a "solr." package ... "solr." can be used as >> > an short form alias for the "likely package" when Solr resolves classes, >> > where the "likely package" varies by context and there can be multiple >> > options that it tries in order >> > >> > DIH could do the same thing, letting short form "solr." signify that >> > Transformers, Evaluators, etc are in the o.a.s.handler.dataimport >> package. >> > >> > the advantage of this over what it sounds like DIH currently does is that >> > if there is an o.a.s.handler.dataimport.WizWatTransformer but someone >> > wants to write their own (package less) WizWatTransformer they can and >> > refer to it simply as "WizWatTransformer" (whereas to use the one that >> > ships with DIH they would specify "solr.WizWatTransformer"). There's no >> > ambiguity as to which one someone means unless they create a package >> > called "solr" ... but then they'ed just be looking for trouble :) >> > >> > >> > >> > -Hoss >> > >> > >> >> >> >> -- >> --Noble Paul >> > -- --Noble Paul
