Hi Noble,
Just to be clear. It was not so that I could refer to my plugin class
with solr.<classname> that I suggested using SolrResourceLoader, it's
that the SolrResourceLoader loads the jars you put in solr-home/lib.
If you don't do this you get a ClassNotFoundException. It's pretty
well explained here:
http://www.nabble.com/New-Feature:-$%7Bsolr.home%7D-lib--dir-for-%22plugins%22-tt7350634r5.html
For the moment, I've altered you code to use the SolrResourceLoader
for resolving classes and it's working well for me.
Thanks again!
Brendan
On Jun 21, 2008, at 7:49 AM, Noble Paul നോബിള്
नोब्ळ् wrote:
We plan to use SolrResourceLoader (next patch).. So anyone wishing to
plugin their classes can refer the classname with solr.<classname>.
--Noble
On Sat, Jun 21, 2008 at 3:06 AM, Chris Hostetter
<[EMAIL PROTECTED]> whi rote:
: 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
I'm not 100% certain what you mean by that last comment, but it
seems like
the the most straight forward appraoch that will confuse the least
amount
of people is for DIH to be consistent with the rest of Solr in how
"plugins" are loaded. The helper methods already exist to make this
easy in SolrResourceLoader...
public Class findClass(String cname, String... subpackages)
public Object newInstance(String cname, String ... subpackages)
...all DIH needs to do is pass the appropriate subpackage(s?) ...
"handler.dataimport." (and maybe in some cases lists like
{"handler.dataimport.", "handler.dataimport.transformer."} if
that's the
way the code winds up being organized)
-Hoss
--
--Noble Paul
