: 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
