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
<requestHandler name="/update/harvest"
class="solr.DirectUpdateHandler2">
notice that I am calling solrDirectUpdateHandler2 directly in defining
a requestHandler
I don't do that anymore. Now, it's this:
<updateRequestProcessorChain name="harvest" default="true">
which took a lot of fishing to sort out, because, being somewhat
dyslexic, it took a long time to figure out that I can use "harvest"
as a setting in SolrJ, thus:
harvestServer = new HttpSolrServer(solrURL);
harvestServer.getHttpClient().getParams().setParameter("update.chain",
"harvest");
In short, the original exception was based on a gross
misinterpretation of how one goes about equating solrconfig.xml with
configurations of SolrJ.
Hope that helps more than it confuses!
Cheers
Jack
On Thu, Jun 27, 2013 at 9:45 AM, Mark Bennett
<mark.benn...@lucidworks.com> wrote:
> 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 <jackp...@topicquests.org> wrote:
>
>> 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:
>>
>> <updateRequestProcessorChain name="harvest" default="true">
>> <processor class="solr.RunUpdateProcessorFactory"/>
>> <processor
>> class="org.apache.solr.update.TopicQuestsDocumentProcessFactory">
>> <str name="inputField">hello</str>
>> </processor>
>> <processor class="solr.LogUpdateProcessorFactory"/>
>> </updateRequestProcessorChain>
>>
>> <requestHandler name="/update/harvest"
>> class="solr.DirectUpdateHandler2">
>> <lst name="defaults">
>> <str name="update.chain">harvest</str>
>> </lst>
>>
>> </requestHandler>
>>
>> The problem returns. It simply appears that I cannot declare a named
>> requestHandler using that class.
>>
>> Jack
>>
>> On Tue, Mar 12, 2013 at 12:22 PM, Jack Park <jackp...@topicquests.org> wrote:
>>> 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(SolrResourceLoader.
>>> java:432)
>>> at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:507)
>>>
>>> This suggests that I might be doing something wrong elsewhere in
>>> solrconfig.xml.
>>>
>>> The possibly relevant parts (my contributions) are these:
>>>
>>> <updateRequestProcessorChain name="partial" default="true">
>>> <processor class="solr.RunUpdateProcessorFactory"/>
>>> <processor class="solr.LogUpdateProcessorFactory"/>
>>> </updateRequestProcessorChain>
>>>
>>> <updateRequestProcessorChain name="harvest" default="true">
>>> <processor class="solr.RunUpdateProcessorFactory"/>
>>> <processor
>>> class="org.apache.solr.update.TopicQuestsDocumentProcessFactory">
>>> <str name="inputField">hello</str>
>>> </processor>
>>> <processor class="solr.LogUpdateProcessorFactory"/>
>>> </updateRequestProcessorChain>
>>>
>>> <requestHandler name="/update/harvest"
>>> class="solr.DirectUpdateHandler2">
>>> <lst name="defaults">
>>> <str name="update.chain">harvest</str>
>>> </lst>
>>>
>>> </requestHandler>
>>>
>>> <requestHandler name="/update/partial"
>>> class="solr.DirectUpdateHandler2">
>>> <lst name="defaults">
>>> <str name="update.chain">partial</str>
>>> </lst>
>>> </requestHandler>
>>>
>>> Thanks
>>> Jack
>>>
>>> On Tue, Mar 12, 2013 at 12:16 PM, Mark Miller <markrmil...@gmail.com> wrote:
>>>> 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 <jackp...@topicquests.org> wrote:
>>>>
>>>>> 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 update log.
>>>>> But, can't boot now.
>>>>>
>>>>> All the jars are in place; I'm able to import that class in my code.
>>>>>
>>>>> Is there any news on that issue?
>>>>>
>>>>> Many thanks
>>>>> Jack
>>>>
>> FLAGS ()
>
