For the record, in case anybody else hits this, I think the ClassCastException
problem had to do with which class loader first loads the class, which is a
side affect of which directory(ies!) you put the jar file in.
I can't reproduce the problem any more, but I believe it went away when I
remo
Wow! That's been a while back, and it appears that my journal didn't
carry a good trace of what I did. Here's a reconstruction:
>From my earlier attempt, which is reflected in this solrconfig.xml entry
notice that I am calling solrDirectUpdateHandler2 directly in defining
a requestHandler
I do
Jack,
Did you ever find a fix for this?
I'm having similar issues (different parts of solrconfig) and my guess is it's
a config issue somewhere, vs. a proper casting problem, some nested init issue.
Was curious what you found?
On Mar 13, 2013, at 11:52 AM, Jack Park wrote:
> I can safely sa
I can safely say that it is not DirectUpdateHandler2 failing; By
commenting out my own handlers, the system boots without error.
This means that my handlers are problematic in some way. The moment I
put back just one of my handlers:
hello
Indeed! Perhaps the germane part is this, before the failure to
instantiate notice:
Caused by: java.lang.ClassCastException: class org.apache.solr.update.DirectUpda
teHandler2
at java.lang.Class.asSubclass(Unknown Source)
at org.apache.solr.core.SolrResourceLoader.findClass(SolrRes
There should be a stack trace - also, you shouldn't have to do anything special
to use this class. It's the default and only truly supported implementation…
- Mark
On Mar 12, 2013, at 2:53 PM, Jack Park wrote:
> That messages gives great, but terrible google. Zillions of hits,
> mostly filled
That messages gives great, but terrible google. Zillions of hits,
mostly filled with very long log traces, and zero messages (that I
could find) about what to do about it.
I switched over to using that handler since it has an update log
specified, and that's the only place I've found how to use up
