You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by James Brady <ja...@gmail.com> on 2009/08/03 17:41:53 UTC
ClassCastException from custom request handler
Hi,
I'm creating a custom request handler to return a list of live cores in
Solr.
On startup, I get this exception for each core:
Jul 31, 2009 5:20:39 PM org.apache.solr.common. SolrException log
SEVERE: java.lang.ClassCastException: LiveCoresHandler
at
org.apache.solr.core.RequestHandlers$1.create(RequestHandlers.java:152)
at
org.apache.solr.core.RequestHandlers$1.create(RequestHandlers.java:161)
at
org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:140)
at
org.apache.solr.core.RequestHandlers.initHandlersFromConfig(RequestHandlers.java:169)
at org.apache.solr.core.SolrCore.<init>(SolrCore.java:444)
I've tried a few variations on the class definition, including extending
RequestHandlerBase (as suggested here:
http://wiki.apache.org/solr/SolrRequestHandler#head-1de7365d7ecf2eac079c5f8b92ee9af712ed75c2)
and implementing SolrRequestHandler directly.
I'm sure that the Solr libraries I built against and those I'm running on
are the same version too, as I unzipped the Solr war file and copies the
relevant jars out of there to build against.
Any ideas on what could be causing the ClassCastException? I've attached a
debugger to the running Solr process but it didn't shed any light on the
issue...
Thanks!
James
Re: ClassCastException from custom request handler
Posted by James Brady <ja...@gmail.com>.
OK, problem solved! Well, worked around.
I gave up on the new style plugin loading in a multicore Jetty setup, and
packaged up my plugin in a rebuilt solr.war.
I had tried this before, but only putting the class files in WEB-INF/lib. If
I put a jar file in there, it works.
2009/8/4 Chantal Ackermann <ch...@btelligent.de>
>
>
> James Brady schrieb:
>
>> Yeah I was thinking T would be SolrRequestHandler too. Eclipse's debugger
>> can't tell me...
>>
>
> You could try disassembling. Or Eclipse opens classes in a very rudimentary
> format when there is no source code attached. Maybe it shows the actual
> return value there, instead of T.
>
>
>> Lot's of other handlers are created with no problem before my plugin falls
>> over, so I don't think it's a problem with T not being what we expected.
>>
>> Do you know of any working examples of plugins I can download and build in
>> my environment to see what happens?
>>
>
> No sorry. I've only overwritten the EntityProcessor from DataImportHandler,
> and that is not configured in solrconfig.xml.
>
>
>
>
>> 2009/8/4 Chantal Ackermann <ch...@btelligent.de>
>>
>> Code is from AbstractPluginLoader in the solr plugin package, 1.3 (the
>>> regular stable release, no svn checkout).
>>>
>>>
>>> 80-84
>>>
>>>> @SuppressWarnings("unchecked")
>>>> protected T create( ResourceLoader loader, String name, String
>>>> className, Node node ) throws Exception
>>>> {
>>>> return (T) loader.newInstance( className, getDefaultPackages() );
>>>> }
>>>>
>>>>
>>
>> --
>> http://twitter.com/goodgravy
>> 512 300 4210
>> http://webmynd.com/
>> Sent from Bury, United Kingdom
>>
>
--
http://twitter.com/goodgravy
512 300 4210
http://webmynd.com/
Sent from Bury, United Kingdom
Re: ClassCastException from custom request handler
Posted by Chantal Ackermann <ch...@btelligent.de>.
James Brady schrieb:
> Yeah I was thinking T would be SolrRequestHandler too. Eclipse's debugger
> can't tell me...
You could try disassembling. Or Eclipse opens classes in a very
rudimentary format when there is no source code attached. Maybe it shows
the actual return value there, instead of T.
>
> Lot's of other handlers are created with no problem before my plugin falls
> over, so I don't think it's a problem with T not being what we expected.
>
> Do you know of any working examples of plugins I can download and build in
> my environment to see what happens?
No sorry. I've only overwritten the EntityProcessor from
DataImportHandler, and that is not configured in solrconfig.xml.
>
> 2009/8/4 Chantal Ackermann <ch...@btelligent.de>
>
>> Code is from AbstractPluginLoader in the solr plugin package, 1.3 (the
>> regular stable release, no svn checkout).
>>
>>
>> 80-84
>>> @SuppressWarnings("unchecked")
>>> protected T create( ResourceLoader loader, String name, String
>>> className, Node node ) throws Exception
>>> {
>>> return (T) loader.newInstance( className, getDefaultPackages() );
>>> }
>>>
>
>
> --
> http://twitter.com/goodgravy
> 512 300 4210
> http://webmynd.com/
> Sent from Bury, United Kingdom
Re: ClassCastException from custom request handler
Posted by James Brady <ja...@gmail.com>.
Yeah I was thinking T would be SolrRequestHandler too. Eclipse's debugger
can't tell me...
Lot's of other handlers are created with no problem before my plugin falls
over, so I don't think it's a problem with T not being what we expected.
Do you know of any working examples of plugins I can download and build in
my environment to see what happens?
2009/8/4 Chantal Ackermann <ch...@btelligent.de>
> Code is from AbstractPluginLoader in the solr plugin package, 1.3 (the
> regular stable release, no svn checkout).
>
>
> 80-84
>> @SuppressWarnings("unchecked")
>> protected T create( ResourceLoader loader, String name, String
>> className, Node node ) throws Exception
>> {
>> return (T) loader.newInstance( className, getDefaultPackages() );
>> }
>>
>
--
http://twitter.com/goodgravy
512 300 4210
http://webmynd.com/
Sent from Bury, United Kingdom
Re: ClassCastException from custom request handler
Posted by Chantal Ackermann <ch...@btelligent.de>.
Code is from AbstractPluginLoader in the solr plugin package, 1.3 (the
regular stable release, no svn checkout).
> 80-84
> @SuppressWarnings("unchecked")
> protected T create( ResourceLoader loader, String name, String
> className, Node node ) throws Exception
> {
> return (T) loader.newInstance( className, getDefaultPackages() );
> }
Re: ClassCastException from custom request handler
Posted by Chantal Ackermann <ch...@btelligent.de>.
Hi there,
could it be that something with the Generics code in the plugin loader
classes works not as expected? Citing for example
http://stackoverflow.com/questions/372250/java-generics-arrays-and-the-classcastexception
this is because
"""
Generics only provide type-safety at compile-time.
"""
80-84
@SuppressWarnings("unchecked")
protected T create( ResourceLoader loader, String name, String
className, Node node ) throws Exception
{
return (T) loader.newInstance( className, getDefaultPackages() );
}
I am not sure what T is at runtime in this case. The subclass (anonymous
in RequestHandlers line 139) replaces T with SolrRequestHandler. But
what happens in the superclass? Is it using Object? Sorry, I'm not that
deep into Generics.
Chantal
James Brady schrieb:
> Hi Chantal!
> I've included a stack trace below.
>
> I've attached a debugger to the server starting up, and it is finding my
> class file as expected... I agree it looks like something wrong with how
> I've deployed the compiled code, but perhaps different Solr versions at
> compile time and run time? However, I've checked and rechecked that and
> can't see a problem!
>
> The actually ClassCastException is being thrown in a anonymous
> AbstractPluginLoader instance's create method:
> http://svn.apache.org/viewvc/lucene/solr/tags/release-1.3.0/src/java/org/apache/solr/util/plugin/AbstractPluginLoader.java?revision=695557
>
> It's the cast to SolrRequestHandler which fails.
>
> Aug 4, 2009 4:24:25 PM org.apache.solr.util.plugin.AbstractPluginLoader load
> INFO: created /update/csv:
> org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper
> Aug 4, 2009 4:24:25 PM org.apache.solr.util.plugin.AbstractPluginLoader load
> INFO: created /admin/: org.apache.solr.handler.admin.AdminHandlers
> Aug 4, 2009 4:24:25 PM org.apache.solr.common.SolrException log
> SEVERE: java.lang.ClassCastException: com.jmsbrdy.LiveCoresHandler
> at
> org.apache.solr.core.RequestHandlers$1.create(RequestHandlers.java:152)
> at
> org.apache.solr.core.RequestHandlers$1.create(RequestHandlers.java:161)
> at
> org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:140)
> at
> org.apache.solr.core.RequestHandlers.initHandlersFromConfig(RequestHandlers.java:169)
> at org.apache.solr.core.SolrCore.<init>(SolrCore.java:444)
> at org.apache.solr.core.CoreContainer.create(CoreContainer.java:323)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:216)
> at
> org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:104)
> at
> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:69)
> at org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:99)
>
> At the moment, my "deployment" is:
>
> 1. compile my single Java file from an Ant script (pointing at the Solr
> JARs from an exploded solr.war)
> 2. copy that class file's directory tree
> (com/jmsbrdy/LiveCoresHandler.class) to a "lib" in the root of my jetty
> install
> 3. add "lib" to Jetty's class path
> 4. add the Solr JARs from the exploded war to Jetty's class path
> 5. start the server
>
> Can you see any problems there?
>
> 2009/8/4 Chantal Ackermann <ch...@btelligent.de>
>
>> Hi James!
>>
>> James Brady schrieb:
>>
>>> There is *something* strange going on with classloaders; when I put my
>>> .class files in the right place in WEB-INF/lib in a repackaged solr.war
>>> file, it's not found by the plugin loader ("Error loading class").
>>>
>>> So the plugin classloader isn't seeing stuff inside WEB-INF/lib.
>>>
>>> That explains why the plugin loader sees my class files when I point
>>> jetty.class.path at the right directory, but in that situation I also need
>>> to point jetty.class.path at the Solr JARs explicitly.
>>>
>> you cannot be sure that it sees *your* files. It only sees a class that
>> qualifies with the name that is requested in your code. It's obviously not
>> the class the code expects, though - as it results in a ClassCastException
>> at some point. It might help to have a look at where and why that casting
>> went wrong.
>>
>> I wrote a custom EntityProcessor and deployed it first under
>> WEB-INF/classes, and now in the plugin directory, and that worked without a
>> problem. My first guess is that something with your packaging is wrong -
>> what do you mean by "default" package? What is the full name of your class
>> and how does its path in the file system look like?
>>
>> Can you paste the stack trace of the exception?
>>
>> Chantal
>>
>>
>>
>>> Still, how would ClassCastExceptions be caused by class loader paths not
>>> being set correctly? I don't follow you... To get a ClassCastException,
>>> the
>>> class to cast to must have been found. The cast-to class must not be in
>>> the
>>> object's inheritance hierarchy, or be built against a different version,
>>> no?
>>>
>>> 2009/8/4 Noble Paul നോബിള് नोब्ळ् <no...@corp.aol.com>
>>>
>>> I guess this is a classloader issue. it is worth trying to put it in
>>>> the WEB-INF/lib of the solr.war
>>>>
>>>>
>>>> On Tue, Aug 4, 2009 at 5:35 PM, James Brady<ja...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi, the LiveCoresHandler is in the default package - the behaviour's the
>>>>> same if I have it in a properly namespaced package too...
>>>>>
>>>>> The requestHandler name can start either be a path (starting with '/')
>>>>> or
>>>>>
>>>> a
>>>>
>>>>> qt name:
>>>>> http://wiki.apache.org/solr/SolrRequestHandler
>>>>>
>>>> starting w/ '/' helps in accessing it directly
>>>>
>>>>> 2009/8/4 Noble Paul നോബിള് नोब्ळ् <no...@corp.aol.com>
>>>>>
>>>>>> what is the package of LiveCoresHandler ?
>>>>>> I guess the requestHandler name should be name="/livecores"
>>>>>>
>>>>>> On Tue, Aug 4, 2009 at 5:04 PM, James Brady<
>>>>>> james.colin.brady@gmail.com
>>>>>> wrote:
>>>>>>
>>>>>>> Solr version: 1.3.0 694707
>>>>>>>
>>>>>>> solrconfig.xml:
>>>>>>> <requestHandler name="livecores" class="LiveCoresHandler" />
>>>>>>>
>>>>>>> public class LiveCoresHandler extends RequestHandlerBase {
>>>>>>> public void init(NamedList args) { }
>>>>>>> public String getDescription() { return ""; }
>>>>>>> public String getSource() { return ""; }
>>>>>>> public String getSourceId() { return ""; }
>>>>>>> public NamedList getStatistics() { return new NamedList(); }
>>>>>>> public String getVersion() { return ""; }
>>>>>>>
>>>>>>> public void handleRequestBody(SolrQueryRequest req,
>>>>>>>
>>>>>> SolrQueryResponse
>>>>> rsp) {
>>>>>>> Collection<String> names =
>>>>>>> req.getCore().getCoreDescriptor().getCoreContainer().getCoreNames();
>>>>>>> rsp.add("cores", names);
>>>>>>> // if the cores are dynamic, you prob don't want to cache
>>>>>>> rsp.setHttpCaching(false);
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> 2009/8/4 Avlesh Singh <av...@gmail.com>
>>>>>>>
>>>>>>> I'm sure I have the class name right - changing it to something
>>>>>>>>> patently
>>>>>>>>> incorrect results in the expected
>>>>>>>>> "org.apache.solr.common.SolrException:
>>>>>>>>> Error loading class ...", rather thanthe ClassCastException.
>>>>>>>>>
>>>>>>>>> You are right about that, James.
>>>>>>>> Which Solr version are you using?
>>>>>>>> Can you please paste the relevant pieces in your solrconfig.xml and
>>>>>>>>
>>>>>>> the
>>>>> request handler class you have created?
>>>>>>>> Cheers
>>>>>>>> Avlesh
>>>>>>>>
>>>>>>>> On Mon, Aug 3, 2009 at 10:51 PM, James Brady
>>>>>>>> <james.colin.brady@gmail.com
>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>> Hi,
>>>>>>>>> Thanks for your suggestions!
>>>>>>>>>
>>>>>>>>> I'm sure I have the class name right - changing it to something
>>>>>>>>> patently
>>>>>>>>> incorrect results in the expected
>>>>>>>>> "org.apache.solr.common.SolrException: Error loading class ...",
>>>>>>>>> rather
>>>>>>>>> than
>>>>>>>>> the ClassCastException.
>>>>>>>>>
>>>>>>>>> I did have some problems getting my class on the app server's
>>>>>>>>> classpath.
>>>>>>>>> I'm
>>>>>>>>> running with solr.home set to "multicore", but creating a
>>>>>>>>> multicore/lib
>>>>>>>>> directory and putting my request handler class in there resulted in
>>>>>>>>>
>>>>>>>> "Error
>>>>>>>>
>>>>>>>>> loading class" errors.
>>>>>>>>>
>>>>>>>>> I found that setting jetty.class.path to include multicore/lib (and
>>>>>>>>> also
>>>>>>>>> explicitly point at Solr's core and common JARs) fixed the "Error
>>>>>>>>> loading
>>>>>>>>> class" errors, leaving these ClassCastExceptions...
>>>>>>>>>
>>>>>>>>> 2009/8/3 Avlesh Singh <av...@gmail.com>
>>>>>>>>>
>>>>>>>>> Can you cross check the class attribute for your handler in
>>>>>>>>> solrconfig.xml?
>>>>>>>>>
>>>>>>>>>> My guess is that it is specified as "solr.LiveCoresHandler". It
>>>>>>>>>> should
>>>>>>>>>>
>>>>>>>>> be
>>>>>>>>> fully qualified class name - com.foo.path.to.LiveCoresHandler
>>>>>>>>>> instead.
>>>>>>>>>>
>>>>>>>>>> Moreover, I am damn sure that you did not forget to drop your jar
>>>>>>>>>> into
>>>>>>>>>> solr.home/lib. Checking once again might not be a bad idea :)
>>>>>>>>>>
>>>>>>>>>> Cheers
>>>>>>>>>> Avlesh
>>>>>>>>>>
>>>>>>>>>> On Mon, Aug 3, 2009 at 9:11 PM, James Brady <
>>>>>>>>>>
>>>>>>>>> james.colin.brady@gmail.com
>>>>>>>>> wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>> I'm creating a custom request handler to return a list of live
>>>>>>>>>>> cores
>>>>>>>>>>>
>>>>>>>>>> in
>>>>>>>>> Solr.
>>>>>>>>>>> On startup, I get this exception for each core:
>>>>>>>>>>>
>>>>>>>>>>> Jul 31, 2009 5:20:39 PM org.apache.solr.common. SolrException
>>>>>>>>>>>
>>>>>>>>>> log
>>>>> SEVERE: java.lang.ClassCastException: LiveCoresHandler
>>>>>>>>>>> at
>>>>>>>>>>>
>>>>>>>>>>> org.apache.solr.core.RequestHandlers$1.create(RequestHandlers.java:152)
>>>>> at
>>>>>>>>>>> org.apache.solr.core.RequestHandlers$1.create(RequestHandlers.java:161)
>>>>> at
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>> org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:140)
>>>>> at
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>> org.apache.solr.core.RequestHandlers.initHandlersFromConfig(RequestHandlers.java:169)
>>>>> at
>>>>>>>>>> org.apache.solr.core.SolrCore.<init>(SolrCore.java:444)
>>>>> I've tried a few variations on the class definition, including
>>>>>>>>>> extending
>>>>>>>>>> RequestHandlerBase (as suggested here:
>>>>>>>>>>>
>>>>>>>>>>>
>>>> http://wiki.apache.org/solr/SolrRequestHandler#head-1de7365d7ecf2eac079c5f8b92ee9af712ed75c2
>>>>
>>>>> )
>>>>>>>>>>> and implementing SolrRequestHandler directly.
>>>>>>>>>>>
>>>>>>>>>>> I'm sure that the Solr libraries I built against and those I'm
>>>>>>>>>>>
>>>>>>>>>> running
>>>>>>>>> on
>>>>>>>>>
>>>>>>>>>> are the same version too, as I unzipped the Solr war file and
>>>>>>>>>>> copies
>>>>>>>>>>>
>>>>>>>>>> the
>>>>>>>>>> relevant jars out of there to build against.
>>>>>>>>>>> Any ideas on what could be causing the ClassCastException? I've
>>>>>>>>>>>
>>>>>>>>>> attached
>>>>>>>>>> a
>>>>>>>>>>
>>>>>>>>>>> debugger to the running Solr process but it didn't shed any
>>>>>>>>>>>
>>>>>>>>>> light
>>>>> on
>>>>>>>>>> the
>>>>>>>>>> issue...
>>>>>>>>>>> Thanks!
>>>>>>>>>>> James
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> http://twitter.com/goodgravy
>>>>>>>>> 512 300 4210
>>>>>>>>> http://webmynd.com/
>>>>>>>>> Sent from Bury, United Kingdom
>>>>>>>>>
>>>>>>>>>
>>>>>>> --
>>>>>>> http://twitter.com/goodgravy
>>>>>>> 512 300 4210
>>>>>>> http://webmynd.com/
>>>>>>> Sent from Bury, United Kingdom
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> -----------------------------------------------------
>>>>>> Noble Paul | Principal Engineer| AOL | http://aol.com
>>>>>>
>>>>>
>>>>> --
>>>>> http://twitter.com/goodgravy
>>>>> 512 300 4210
>>>>> http://webmynd.com/
>>>>> Sent from Bury, United Kingdom
>>>>>
>>>>
>>>> --
>>>> -----------------------------------------------------
>>>> Noble Paul | Principal Engineer| AOL | http://aol.com
>>>>
>>>>
>>>
>>> --
>>> http://twitter.com/goodgravy
>>> 512 300 4210
>>> http://webmynd.com/
>>> Sent from Bury, United Kingdom
>>>
>> --
>> Chantal Ackermann
>> Consultant
>>
>> mobil +49 (176) 10 00 09 45
>> email chantal.ackermann@btelligent.de
>>
>>
>> --------------------------------------------------------------------------------------------------------
>>
>> b.telligent GmbH & Co. KG
>> Lichtenbergstraße 8
>> D-85748 Garching / München
>>
>> fon +49 (89) 54 84 25 60
>> fax +49 (89) 54 84 25 69
>> web www.btelligent.de
>>
>> Registered in Munich: HRA 84393
>> Managing Director: b.telligent Verwaltungs GmbH, HRB 153164 represented by
>> Sebastian Amtage and Klaus Blaschek
>> USt.Id.-Nr. DE814054803
>>
>>
>>
>> Confidentiality Note
>> This email is intended only for the use of the individual or entity to
>> which it is addressed, and may contain information that is privileged,
>> confidential and exempt from disclosure under applicable law. If the reader
>> of this email message is not the intended recipient, or the employee or
>> agent responsible for delivery of the message to the intended recipient, you
>> are hereby notified that any dissemination, distribution or copying of this
>> communication is prohibited. If you have received this email in error,
>> please notify us immediately by telephone at +49 (0) 89 54 84 25 60. Thank
>> you.
>>
>
>
>
> --
> http://twitter.com/goodgravy
> 512 300 4210
> http://webmynd.com/
> Sent from Bury, United Kingdom
--
Chantal Ackermann
Consultant
mobil +49 (176) 10 00 09 45
email chantal.ackermann@btelligent.de
--------------------------------------------------------------------------------------------------------
b.telligent GmbH & Co. KG
Lichtenbergstraße 8
D-85748 Garching / München
fon +49 (89) 54 84 25 60
fax +49 (89) 54 84 25 69
web www.btelligent.de
Registered in Munich: HRA 84393
Managing Director: b.telligent Verwaltungs GmbH, HRB 153164 represented
by Sebastian Amtage and Klaus Blaschek
USt.Id.-Nr. DE814054803
Confidentiality Note
This email is intended only for the use of the individual or entity to
which it is addressed, and may contain information that is privileged,
confidential and exempt from disclosure under applicable law. If the
reader of this email message is not the intended recipient, or the
employee or agent responsible for delivery of the message to the
intended recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is prohibited. If you have
received this email in error, please notify us immediately by telephone
at +49 (0) 89 54 84 25 60. Thank you.
Re: ClassCastException from custom request handler
Posted by James Brady <ja...@gmail.com>.
Hi Chantal!
I've included a stack trace below.
I've attached a debugger to the server starting up, and it is finding my
class file as expected... I agree it looks like something wrong with how
I've deployed the compiled code, but perhaps different Solr versions at
compile time and run time? However, I've checked and rechecked that and
can't see a problem!
The actually ClassCastException is being thrown in a anonymous
AbstractPluginLoader instance's create method:
http://svn.apache.org/viewvc/lucene/solr/tags/release-1.3.0/src/java/org/apache/solr/util/plugin/AbstractPluginLoader.java?revision=695557
It's the cast to SolrRequestHandler which fails.
Aug 4, 2009 4:24:25 PM org.apache.solr.util.plugin.AbstractPluginLoader load
INFO: created /update/csv:
org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper
Aug 4, 2009 4:24:25 PM org.apache.solr.util.plugin.AbstractPluginLoader load
INFO: created /admin/: org.apache.solr.handler.admin.AdminHandlers
Aug 4, 2009 4:24:25 PM org.apache.solr.common.SolrException log
SEVERE: java.lang.ClassCastException: com.jmsbrdy.LiveCoresHandler
at
org.apache.solr.core.RequestHandlers$1.create(RequestHandlers.java:152)
at
org.apache.solr.core.RequestHandlers$1.create(RequestHandlers.java:161)
at
org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:140)
at
org.apache.solr.core.RequestHandlers.initHandlersFromConfig(RequestHandlers.java:169)
at org.apache.solr.core.SolrCore.<init>(SolrCore.java:444)
at org.apache.solr.core.CoreContainer.create(CoreContainer.java:323)
at org.apache.solr.core.CoreContainer.load(CoreContainer.java:216)
at
org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:104)
at
org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:69)
at org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:99)
At the moment, my "deployment" is:
1. compile my single Java file from an Ant script (pointing at the Solr
JARs from an exploded solr.war)
2. copy that class file's directory tree
(com/jmsbrdy/LiveCoresHandler.class) to a "lib" in the root of my jetty
install
3. add "lib" to Jetty's class path
4. add the Solr JARs from the exploded war to Jetty's class path
5. start the server
Can you see any problems there?
2009/8/4 Chantal Ackermann <ch...@btelligent.de>
> Hi James!
>
> James Brady schrieb:
>
>> There is *something* strange going on with classloaders; when I put my
>> .class files in the right place in WEB-INF/lib in a repackaged solr.war
>> file, it's not found by the plugin loader ("Error loading class").
>>
>> So the plugin classloader isn't seeing stuff inside WEB-INF/lib.
>>
>> That explains why the plugin loader sees my class files when I point
>> jetty.class.path at the right directory, but in that situation I also need
>> to point jetty.class.path at the Solr JARs explicitly.
>>
>
> you cannot be sure that it sees *your* files. It only sees a class that
> qualifies with the name that is requested in your code. It's obviously not
> the class the code expects, though - as it results in a ClassCastException
> at some point. It might help to have a look at where and why that casting
> went wrong.
>
> I wrote a custom EntityProcessor and deployed it first under
> WEB-INF/classes, and now in the plugin directory, and that worked without a
> problem. My first guess is that something with your packaging is wrong -
> what do you mean by "default" package? What is the full name of your class
> and how does its path in the file system look like?
>
> Can you paste the stack trace of the exception?
>
> Chantal
>
>
>
>> Still, how would ClassCastExceptions be caused by class loader paths not
>> being set correctly? I don't follow you... To get a ClassCastException,
>> the
>> class to cast to must have been found. The cast-to class must not be in
>> the
>> object's inheritance hierarchy, or be built against a different version,
>> no?
>>
>> 2009/8/4 Noble Paul നോബിള് नोब्ळ् <no...@corp.aol.com>
>>
>> I guess this is a classloader issue. it is worth trying to put it in
>>> the WEB-INF/lib of the solr.war
>>>
>>>
>>> On Tue, Aug 4, 2009 at 5:35 PM, James Brady<ja...@gmail.com>
>>> wrote:
>>>
>>>> Hi, the LiveCoresHandler is in the default package - the behaviour's the
>>>> same if I have it in a properly namespaced package too...
>>>>
>>>> The requestHandler name can start either be a path (starting with '/')
>>>> or
>>>>
>>> a
>>>
>>>> qt name:
>>>> http://wiki.apache.org/solr/SolrRequestHandler
>>>>
>>> starting w/ '/' helps in accessing it directly
>>>
>>>> 2009/8/4 Noble Paul നോബിള് नोब्ळ् <no...@corp.aol.com>
>>>>
>>>>> what is the package of LiveCoresHandler ?
>>>>> I guess the requestHandler name should be name="/livecores"
>>>>>
>>>>> On Tue, Aug 4, 2009 at 5:04 PM, James Brady<
>>>>> james.colin.brady@gmail.com
>>>>> wrote:
>>>>>
>>>>>> Solr version: 1.3.0 694707
>>>>>>
>>>>>> solrconfig.xml:
>>>>>> <requestHandler name="livecores" class="LiveCoresHandler" />
>>>>>>
>>>>>> public class LiveCoresHandler extends RequestHandlerBase {
>>>>>> public void init(NamedList args) { }
>>>>>> public String getDescription() { return ""; }
>>>>>> public String getSource() { return ""; }
>>>>>> public String getSourceId() { return ""; }
>>>>>> public NamedList getStatistics() { return new NamedList(); }
>>>>>> public String getVersion() { return ""; }
>>>>>>
>>>>>> public void handleRequestBody(SolrQueryRequest req,
>>>>>>
>>>>> SolrQueryResponse
>>>
>>>> rsp) {
>>>>>> Collection<String> names =
>>>>>> req.getCore().getCoreDescriptor().getCoreContainer().getCoreNames();
>>>>>> rsp.add("cores", names);
>>>>>> // if the cores are dynamic, you prob don't want to cache
>>>>>> rsp.setHttpCaching(false);
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> 2009/8/4 Avlesh Singh <av...@gmail.com>
>>>>>>
>>>>>> I'm sure I have the class name right - changing it to something
>>>>>>>> patently
>>>>>>>> incorrect results in the expected
>>>>>>>> "org.apache.solr.common.SolrException:
>>>>>>>> Error loading class ...", rather thanthe ClassCastException.
>>>>>>>>
>>>>>>>> You are right about that, James.
>>>>>>>
>>>>>>> Which Solr version are you using?
>>>>>>> Can you please paste the relevant pieces in your solrconfig.xml and
>>>>>>>
>>>>>> the
>>>
>>>> request handler class you have created?
>>>>>>>
>>>>>>> Cheers
>>>>>>> Avlesh
>>>>>>>
>>>>>>> On Mon, Aug 3, 2009 at 10:51 PM, James Brady
>>>>>>> <james.colin.brady@gmail.com
>>>>>>>
>>>>>>>> wrote:
>>>>>>>> Hi,
>>>>>>>> Thanks for your suggestions!
>>>>>>>>
>>>>>>>> I'm sure I have the class name right - changing it to something
>>>>>>>> patently
>>>>>>>> incorrect results in the expected
>>>>>>>> "org.apache.solr.common.SolrException: Error loading class ...",
>>>>>>>> rather
>>>>>>>> than
>>>>>>>> the ClassCastException.
>>>>>>>>
>>>>>>>> I did have some problems getting my class on the app server's
>>>>>>>> classpath.
>>>>>>>> I'm
>>>>>>>> running with solr.home set to "multicore", but creating a
>>>>>>>> multicore/lib
>>>>>>>> directory and putting my request handler class in there resulted in
>>>>>>>>
>>>>>>> "Error
>>>>>>>
>>>>>>>> loading class" errors.
>>>>>>>>
>>>>>>>> I found that setting jetty.class.path to include multicore/lib (and
>>>>>>>> also
>>>>>>>> explicitly point at Solr's core and common JARs) fixed the "Error
>>>>>>>> loading
>>>>>>>> class" errors, leaving these ClassCastExceptions...
>>>>>>>>
>>>>>>>> 2009/8/3 Avlesh Singh <av...@gmail.com>
>>>>>>>>
>>>>>>>> Can you cross check the class attribute for your handler in
>>>>>>>>>
>>>>>>>> solrconfig.xml?
>>>>>>>>
>>>>>>>>> My guess is that it is specified as "solr.LiveCoresHandler". It
>>>>>>>>> should
>>>>>>>>>
>>>>>>>> be
>>>>>>>
>>>>>>>> fully qualified class name - com.foo.path.to.LiveCoresHandler
>>>>>>>>> instead.
>>>>>>>>>
>>>>>>>>> Moreover, I am damn sure that you did not forget to drop your jar
>>>>>>>>> into
>>>>>>>>> solr.home/lib. Checking once again might not be a bad idea :)
>>>>>>>>>
>>>>>>>>> Cheers
>>>>>>>>> Avlesh
>>>>>>>>>
>>>>>>>>> On Mon, Aug 3, 2009 at 9:11 PM, James Brady <
>>>>>>>>>
>>>>>>>> james.colin.brady@gmail.com
>>>>>>>
>>>>>>>> wrote:
>>>>>>>>>> Hi,
>>>>>>>>>> I'm creating a custom request handler to return a list of live
>>>>>>>>>> cores
>>>>>>>>>>
>>>>>>>>> in
>>>>>>>
>>>>>>>> Solr.
>>>>>>>>>>
>>>>>>>>>> On startup, I get this exception for each core:
>>>>>>>>>>
>>>>>>>>>> Jul 31, 2009 5:20:39 PM org.apache.solr.common. SolrException
>>>>>>>>>>
>>>>>>>>> log
>>>
>>>> SEVERE: java.lang.ClassCastException: LiveCoresHandler
>>>>>>>>>> at
>>>>>>>>>>
>>>>>>>>>> org.apache.solr.core.RequestHandlers$1.create(RequestHandlers.java:152)
>>>
>>>> at
>>>>>>>>>>
>>>>>>>>>> org.apache.solr.core.RequestHandlers$1.create(RequestHandlers.java:161)
>>>
>>>> at
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:140)
>>>
>>>> at
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> org.apache.solr.core.RequestHandlers.initHandlersFromConfig(RequestHandlers.java:169)
>>>
>>>> at
>>>>>>>>>>
>>>>>>>>> org.apache.solr.core.SolrCore.<init>(SolrCore.java:444)
>>>
>>>> I've tried a few variations on the class definition, including
>>>>>>>>>>
>>>>>>>>> extending
>>>>>>>>
>>>>>>>>> RequestHandlerBase (as suggested here:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>
>>> http://wiki.apache.org/solr/SolrRequestHandler#head-1de7365d7ecf2eac079c5f8b92ee9af712ed75c2
>>>
>>>> )
>>>>>>>>>> and implementing SolrRequestHandler directly.
>>>>>>>>>>
>>>>>>>>>> I'm sure that the Solr libraries I built against and those I'm
>>>>>>>>>>
>>>>>>>>> running
>>>>>>>
>>>>>>>> on
>>>>>>>>
>>>>>>>>> are the same version too, as I unzipped the Solr war file and
>>>>>>>>>> copies
>>>>>>>>>>
>>>>>>>>> the
>>>>>>>>
>>>>>>>>> relevant jars out of there to build against.
>>>>>>>>>>
>>>>>>>>>> Any ideas on what could be causing the ClassCastException? I've
>>>>>>>>>>
>>>>>>>>> attached
>>>>>>>>
>>>>>>>>> a
>>>>>>>>>
>>>>>>>>>> debugger to the running Solr process but it didn't shed any
>>>>>>>>>>
>>>>>>>>> light
>>>
>>>> on
>>>>>>>>>>
>>>>>>>>> the
>>>>>>>>
>>>>>>>>> issue...
>>>>>>>>>>
>>>>>>>>>> Thanks!
>>>>>>>>>> James
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> http://twitter.com/goodgravy
>>>>>>>> 512 300 4210
>>>>>>>> http://webmynd.com/
>>>>>>>> Sent from Bury, United Kingdom
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>> --
>>>>>> http://twitter.com/goodgravy
>>>>>> 512 300 4210
>>>>>> http://webmynd.com/
>>>>>> Sent from Bury, United Kingdom
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> -----------------------------------------------------
>>>>> Noble Paul | Principal Engineer| AOL | http://aol.com
>>>>>
>>>>
>>>>
>>>> --
>>>> http://twitter.com/goodgravy
>>>> 512 300 4210
>>>> http://webmynd.com/
>>>> Sent from Bury, United Kingdom
>>>>
>>>
>>>
>>> --
>>> -----------------------------------------------------
>>> Noble Paul | Principal Engineer| AOL | http://aol.com
>>>
>>>
>>
>>
>> --
>> http://twitter.com/goodgravy
>> 512 300 4210
>> http://webmynd.com/
>> Sent from Bury, United Kingdom
>>
>
> --
> Chantal Ackermann
> Consultant
>
> mobil +49 (176) 10 00 09 45
> email chantal.ackermann@btelligent.de
>
>
> --------------------------------------------------------------------------------------------------------
>
> b.telligent GmbH & Co. KG
> Lichtenbergstraße 8
> D-85748 Garching / München
>
> fon +49 (89) 54 84 25 60
> fax +49 (89) 54 84 25 69
> web www.btelligent.de
>
> Registered in Munich: HRA 84393
> Managing Director: b.telligent Verwaltungs GmbH, HRB 153164 represented by
> Sebastian Amtage and Klaus Blaschek
> USt.Id.-Nr. DE814054803
>
>
>
> Confidentiality Note
> This email is intended only for the use of the individual or entity to
> which it is addressed, and may contain information that is privileged,
> confidential and exempt from disclosure under applicable law. If the reader
> of this email message is not the intended recipient, or the employee or
> agent responsible for delivery of the message to the intended recipient, you
> are hereby notified that any dissemination, distribution or copying of this
> communication is prohibited. If you have received this email in error,
> please notify us immediately by telephone at +49 (0) 89 54 84 25 60. Thank
> you.
>
--
http://twitter.com/goodgravy
512 300 4210
http://webmynd.com/
Sent from Bury, United Kingdom
Re: ClassCastException from custom request handler
Posted by Chantal Ackermann <ch...@btelligent.de>.
Hi James!
James Brady schrieb:
> There is *something* strange going on with classloaders; when I put my
> .class files in the right place in WEB-INF/lib in a repackaged solr.war
> file, it's not found by the plugin loader ("Error loading class").
>
> So the plugin classloader isn't seeing stuff inside WEB-INF/lib.
>
> That explains why the plugin loader sees my class files when I point
> jetty.class.path at the right directory, but in that situation I also need
> to point jetty.class.path at the Solr JARs explicitly.
you cannot be sure that it sees *your* files. It only sees a class that
qualifies with the name that is requested in your code. It's obviously
not the class the code expects, though - as it results in a
ClassCastException at some point. It might help to have a look at where
and why that casting went wrong.
I wrote a custom EntityProcessor and deployed it first under
WEB-INF/classes, and now in the plugin directory, and that worked
without a problem. My first guess is that something with your packaging
is wrong - what do you mean by "default" package? What is the full name
of your class and how does its path in the file system look like?
Can you paste the stack trace of the exception?
Chantal
>
> Still, how would ClassCastExceptions be caused by class loader paths not
> being set correctly? I don't follow you... To get a ClassCastException, the
> class to cast to must have been found. The cast-to class must not be in the
> object's inheritance hierarchy, or be built against a different version, no?
>
> 2009/8/4 Noble Paul നോബിള് नोब्ळ् <no...@corp.aol.com>
>
>> I guess this is a classloader issue. it is worth trying to put it in
>> the WEB-INF/lib of the solr.war
>>
>>
>> On Tue, Aug 4, 2009 at 5:35 PM, James Brady<ja...@gmail.com>
>> wrote:
>>> Hi, the LiveCoresHandler is in the default package - the behaviour's the
>>> same if I have it in a properly namespaced package too...
>>>
>>> The requestHandler name can start either be a path (starting with '/') or
>> a
>>> qt name:
>>> http://wiki.apache.org/solr/SolrRequestHandler
>> starting w/ '/' helps in accessing it directly
>>> 2009/8/4 Noble Paul നോബിള് नोब्ळ् <no...@corp.aol.com>
>>>> what is the package of LiveCoresHandler ?
>>>> I guess the requestHandler name should be name="/livecores"
>>>>
>>>> On Tue, Aug 4, 2009 at 5:04 PM, James Brady<james.colin.brady@gmail.com
>>>> wrote:
>>>>> Solr version: 1.3.0 694707
>>>>>
>>>>> solrconfig.xml:
>>>>> <requestHandler name="livecores" class="LiveCoresHandler" />
>>>>>
>>>>> public class LiveCoresHandler extends RequestHandlerBase {
>>>>> public void init(NamedList args) { }
>>>>> public String getDescription() { return ""; }
>>>>> public String getSource() { return ""; }
>>>>> public String getSourceId() { return ""; }
>>>>> public NamedList getStatistics() { return new NamedList(); }
>>>>> public String getVersion() { return ""; }
>>>>>
>>>>> public void handleRequestBody(SolrQueryRequest req,
>> SolrQueryResponse
>>>>> rsp) {
>>>>> Collection<String> names =
>>>>> req.getCore().getCoreDescriptor().getCoreContainer().getCoreNames();
>>>>> rsp.add("cores", names);
>>>>> // if the cores are dynamic, you prob don't want to cache
>>>>> rsp.setHttpCaching(false);
>>>>> }
>>>>> }
>>>>>
>>>>> 2009/8/4 Avlesh Singh <av...@gmail.com>
>>>>>
>>>>>>> I'm sure I have the class name right - changing it to something
>>>>>>> patently
>>>>>>> incorrect results in the expected
>>>>>>> "org.apache.solr.common.SolrException:
>>>>>>> Error loading class ...", rather thanthe ClassCastException.
>>>>>>>
>>>>>> You are right about that, James.
>>>>>>
>>>>>> Which Solr version are you using?
>>>>>> Can you please paste the relevant pieces in your solrconfig.xml and
>> the
>>>>>> request handler class you have created?
>>>>>>
>>>>>> Cheers
>>>>>> Avlesh
>>>>>>
>>>>>> On Mon, Aug 3, 2009 at 10:51 PM, James Brady
>>>>>> <james.colin.brady@gmail.com
>>>>>>> wrote:
>>>>>>> Hi,
>>>>>>> Thanks for your suggestions!
>>>>>>>
>>>>>>> I'm sure I have the class name right - changing it to something
>>>>>>> patently
>>>>>>> incorrect results in the expected
>>>>>>> "org.apache.solr.common.SolrException: Error loading class ...",
>>>>>>> rather
>>>>>>> than
>>>>>>> the ClassCastException.
>>>>>>>
>>>>>>> I did have some problems getting my class on the app server's
>>>>>>> classpath.
>>>>>>> I'm
>>>>>>> running with solr.home set to "multicore", but creating a
>>>>>>> multicore/lib
>>>>>>> directory and putting my request handler class in there resulted in
>>>>>> "Error
>>>>>>> loading class" errors.
>>>>>>>
>>>>>>> I found that setting jetty.class.path to include multicore/lib (and
>>>>>>> also
>>>>>>> explicitly point at Solr's core and common JARs) fixed the "Error
>>>>>>> loading
>>>>>>> class" errors, leaving these ClassCastExceptions...
>>>>>>>
>>>>>>> 2009/8/3 Avlesh Singh <av...@gmail.com>
>>>>>>>
>>>>>>>> Can you cross check the class attribute for your handler in
>>>>>>> solrconfig.xml?
>>>>>>>> My guess is that it is specified as "solr.LiveCoresHandler". It
>>>>>>>> should
>>>>>> be
>>>>>>>> fully qualified class name - com.foo.path.to.LiveCoresHandler
>>>>>>>> instead.
>>>>>>>>
>>>>>>>> Moreover, I am damn sure that you did not forget to drop your jar
>>>>>>>> into
>>>>>>>> solr.home/lib. Checking once again might not be a bad idea :)
>>>>>>>>
>>>>>>>> Cheers
>>>>>>>> Avlesh
>>>>>>>>
>>>>>>>> On Mon, Aug 3, 2009 at 9:11 PM, James Brady <
>>>>>> james.colin.brady@gmail.com
>>>>>>>>> wrote:
>>>>>>>>> Hi,
>>>>>>>>> I'm creating a custom request handler to return a list of live
>>>>>>>>> cores
>>>>>> in
>>>>>>>>> Solr.
>>>>>>>>>
>>>>>>>>> On startup, I get this exception for each core:
>>>>>>>>>
>>>>>>>>> Jul 31, 2009 5:20:39 PM org.apache.solr.common. SolrException
>> log
>>>>>>>>> SEVERE: java.lang.ClassCastException: LiveCoresHandler
>>>>>>>>> at
>>>>>>>>>
>> org.apache.solr.core.RequestHandlers$1.create(RequestHandlers.java:152)
>>>>>>>>> at
>>>>>>>>>
>> org.apache.solr.core.RequestHandlers$1.create(RequestHandlers.java:161)
>>>>>>>>> at
>>>>>>>>>
>>>>>>>>>
>>>>>>
>> org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:140)
>>>>>>>>> at
>>>>>>>>>
>>>>>>>>>
>>>>>>
>> org.apache.solr.core.RequestHandlers.initHandlersFromConfig(RequestHandlers.java:169)
>>>>>>>>> at
>> org.apache.solr.core.SolrCore.<init>(SolrCore.java:444)
>>>>>>>>> I've tried a few variations on the class definition, including
>>>>>>> extending
>>>>>>>>> RequestHandlerBase (as suggested here:
>>>>>>>>>
>>>>>>>>>
>>>>>>
>> http://wiki.apache.org/solr/SolrRequestHandler#head-1de7365d7ecf2eac079c5f8b92ee9af712ed75c2
>>>>>>>>> )
>>>>>>>>> and implementing SolrRequestHandler directly.
>>>>>>>>>
>>>>>>>>> I'm sure that the Solr libraries I built against and those I'm
>>>>>> running
>>>>>>> on
>>>>>>>>> are the same version too, as I unzipped the Solr war file and
>>>>>>>>> copies
>>>>>>> the
>>>>>>>>> relevant jars out of there to build against.
>>>>>>>>>
>>>>>>>>> Any ideas on what could be causing the ClassCastException? I've
>>>>>>> attached
>>>>>>>> a
>>>>>>>>> debugger to the running Solr process but it didn't shed any
>> light
>>>>>>>>> on
>>>>>>> the
>>>>>>>>> issue...
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>> James
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> http://twitter.com/goodgravy
>>>>>>> 512 300 4210
>>>>>>> http://webmynd.com/
>>>>>>> Sent from Bury, United Kingdom
>>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> http://twitter.com/goodgravy
>>>>> 512 300 4210
>>>>> http://webmynd.com/
>>>>> Sent from Bury, United Kingdom
>>>>>
>>>>
>>>>
>>>> --
>>>> -----------------------------------------------------
>>>> Noble Paul | Principal Engineer| AOL | http://aol.com
>>>
>>>
>>> --
>>> http://twitter.com/goodgravy
>>> 512 300 4210
>>> http://webmynd.com/
>>> Sent from Bury, United Kingdom
>>
>>
>> --
>> -----------------------------------------------------
>> Noble Paul | Principal Engineer| AOL | http://aol.com
>>
>
>
>
> --
> http://twitter.com/goodgravy
> 512 300 4210
> http://webmynd.com/
> Sent from Bury, United Kingdom
--
Chantal Ackermann
Consultant
mobil +49 (176) 10 00 09 45
email chantal.ackermann@btelligent.de
--------------------------------------------------------------------------------------------------------
b.telligent GmbH & Co. KG
Lichtenbergstraße 8
D-85748 Garching / München
fon +49 (89) 54 84 25 60
fax +49 (89) 54 84 25 69
web www.btelligent.de
Registered in Munich: HRA 84393
Managing Director: b.telligent Verwaltungs GmbH, HRB 153164 represented
by Sebastian Amtage and Klaus Blaschek
USt.Id.-Nr. DE814054803
Confidentiality Note
This email is intended only for the use of the individual or entity to
which it is addressed, and may contain information that is privileged,
confidential and exempt from disclosure under applicable law. If the
reader of this email message is not the intended recipient, or the
employee or agent responsible for delivery of the message to the
intended recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is prohibited. If you have
received this email in error, please notify us immediately by telephone
at +49 (0) 89 54 84 25 60. Thank you.
Re: ClassCastException from custom request handler
Posted by James Brady <ja...@gmail.com>.
There is *something* strange going on with classloaders; when I put my
.class files in the right place in WEB-INF/lib in a repackaged solr.war
file, it's not found by the plugin loader ("Error loading class").
So the plugin classloader isn't seeing stuff inside WEB-INF/lib.
That explains why the plugin loader sees my class files when I point
jetty.class.path at the right directory, but in that situation I also need
to point jetty.class.path at the Solr JARs explicitly.
Still, how would ClassCastExceptions be caused by class loader paths not
being set correctly? I don't follow you... To get a ClassCastException, the
class to cast to must have been found. The cast-to class must not be in the
object's inheritance hierarchy, or be built against a different version, no?
2009/8/4 Noble Paul നോബിള് नोब्ळ् <no...@corp.aol.com>
> I guess this is a classloader issue. it is worth trying to put it in
> the WEB-INF/lib of the solr.war
>
>
> On Tue, Aug 4, 2009 at 5:35 PM, James Brady<ja...@gmail.com>
> wrote:
> > Hi, the LiveCoresHandler is in the default package - the behaviour's the
> > same if I have it in a properly namespaced package too...
> >
> > The requestHandler name can start either be a path (starting with '/') or
> a
> > qt name:
> > http://wiki.apache.org/solr/SolrRequestHandler
> starting w/ '/' helps in accessing it directly
> >
> > 2009/8/4 Noble Paul നോബിള് नोब्ळ् <no...@corp.aol.com>
> >>
> >> what is the package of LiveCoresHandler ?
> >> I guess the requestHandler name should be name="/livecores"
> >>
> >> On Tue, Aug 4, 2009 at 5:04 PM, James Brady<james.colin.brady@gmail.com
> >
> >> wrote:
> >> > Solr version: 1.3.0 694707
> >> >
> >> > solrconfig.xml:
> >> > <requestHandler name="livecores" class="LiveCoresHandler" />
> >> >
> >> > public class LiveCoresHandler extends RequestHandlerBase {
> >> > public void init(NamedList args) { }
> >> > public String getDescription() { return ""; }
> >> > public String getSource() { return ""; }
> >> > public String getSourceId() { return ""; }
> >> > public NamedList getStatistics() { return new NamedList(); }
> >> > public String getVersion() { return ""; }
> >> >
> >> > public void handleRequestBody(SolrQueryRequest req,
> SolrQueryResponse
> >> > rsp) {
> >> > Collection<String> names =
> >> > req.getCore().getCoreDescriptor().getCoreContainer().getCoreNames();
> >> > rsp.add("cores", names);
> >> > // if the cores are dynamic, you prob don't want to cache
> >> > rsp.setHttpCaching(false);
> >> > }
> >> > }
> >> >
> >> > 2009/8/4 Avlesh Singh <av...@gmail.com>
> >> >
> >> >> >
> >> >> > I'm sure I have the class name right - changing it to something
> >> >> > patently
> >> >> > incorrect results in the expected
> >> >> > "org.apache.solr.common.SolrException:
> >> >> > Error loading class ...", rather thanthe ClassCastException.
> >> >> >
> >> >> You are right about that, James.
> >> >>
> >> >> Which Solr version are you using?
> >> >> Can you please paste the relevant pieces in your solrconfig.xml and
> the
> >> >> request handler class you have created?
> >> >>
> >> >> Cheers
> >> >> Avlesh
> >> >>
> >> >> On Mon, Aug 3, 2009 at 10:51 PM, James Brady
> >> >> <james.colin.brady@gmail.com
> >> >> >wrote:
> >> >>
> >> >> > Hi,
> >> >> > Thanks for your suggestions!
> >> >> >
> >> >> > I'm sure I have the class name right - changing it to something
> >> >> > patently
> >> >> > incorrect results in the expected
> >> >> > "org.apache.solr.common.SolrException: Error loading class ...",
> >> >> > rather
> >> >> > than
> >> >> > the ClassCastException.
> >> >> >
> >> >> > I did have some problems getting my class on the app server's
> >> >> > classpath.
> >> >> > I'm
> >> >> > running with solr.home set to "multicore", but creating a
> >> >> > multicore/lib
> >> >> > directory and putting my request handler class in there resulted in
> >> >> "Error
> >> >> > loading class" errors.
> >> >> >
> >> >> > I found that setting jetty.class.path to include multicore/lib (and
> >> >> > also
> >> >> > explicitly point at Solr's core and common JARs) fixed the "Error
> >> >> > loading
> >> >> > class" errors, leaving these ClassCastExceptions...
> >> >> >
> >> >> > 2009/8/3 Avlesh Singh <av...@gmail.com>
> >> >> >
> >> >> > > Can you cross check the class attribute for your handler in
> >> >> > solrconfig.xml?
> >> >> > > My guess is that it is specified as "solr.LiveCoresHandler". It
> >> >> > > should
> >> >> be
> >> >> > > fully qualified class name - com.foo.path.to.LiveCoresHandler
> >> >> > > instead.
> >> >> > >
> >> >> > > Moreover, I am damn sure that you did not forget to drop your jar
> >> >> > > into
> >> >> > > solr.home/lib. Checking once again might not be a bad idea :)
> >> >> > >
> >> >> > > Cheers
> >> >> > > Avlesh
> >> >> > >
> >> >> > > On Mon, Aug 3, 2009 at 9:11 PM, James Brady <
> >> >> james.colin.brady@gmail.com
> >> >> > > >wrote:
> >> >> > >
> >> >> > > > Hi,
> >> >> > > > I'm creating a custom request handler to return a list of live
> >> >> > > > cores
> >> >> in
> >> >> > > > Solr.
> >> >> > > >
> >> >> > > > On startup, I get this exception for each core:
> >> >> > > >
> >> >> > > > Jul 31, 2009 5:20:39 PM org.apache.solr.common. SolrException
> log
> >> >> > > > SEVERE: java.lang.ClassCastException: LiveCoresHandler
> >> >> > > > at
> >> >> > > >
> >> >>
> org.apache.solr.core.RequestHandlers$1.create(RequestHandlers.java:152)
> >> >> > > > at
> >> >> > > >
> >> >>
> org.apache.solr.core.RequestHandlers$1.create(RequestHandlers.java:161)
> >> >> > > > at
> >> >> > > >
> >> >> > > >
> >> >> > >
> >> >> >
> >> >>
> >> >>
> org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:140)
> >> >> > > > at
> >> >> > > >
> >> >> > > >
> >> >> > >
> >> >> >
> >> >>
> >> >>
> org.apache.solr.core.RequestHandlers.initHandlersFromConfig(RequestHandlers.java:169)
> >> >> > > > at
> org.apache.solr.core.SolrCore.<init>(SolrCore.java:444)
> >> >> > > >
> >> >> > > > I've tried a few variations on the class definition, including
> >> >> > extending
> >> >> > > > RequestHandlerBase (as suggested here:
> >> >> > > >
> >> >> > > >
> >> >> > >
> >> >> >
> >> >>
> >> >>
> http://wiki.apache.org/solr/SolrRequestHandler#head-1de7365d7ecf2eac079c5f8b92ee9af712ed75c2
> >> >> > > > )
> >> >> > > > and implementing SolrRequestHandler directly.
> >> >> > > >
> >> >> > > > I'm sure that the Solr libraries I built against and those I'm
> >> >> running
> >> >> > on
> >> >> > > > are the same version too, as I unzipped the Solr war file and
> >> >> > > > copies
> >> >> > the
> >> >> > > > relevant jars out of there to build against.
> >> >> > > >
> >> >> > > > Any ideas on what could be causing the ClassCastException? I've
> >> >> > attached
> >> >> > > a
> >> >> > > > debugger to the running Solr process but it didn't shed any
> light
> >> >> > > > on
> >> >> > the
> >> >> > > > issue...
> >> >> > > >
> >> >> > > > Thanks!
> >> >> > > > James
> >> >> > > >
> >> >> > >
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > http://twitter.com/goodgravy
> >> >> > 512 300 4210
> >> >> > http://webmynd.com/
> >> >> > Sent from Bury, United Kingdom
> >> >> >
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > http://twitter.com/goodgravy
> >> > 512 300 4210
> >> > http://webmynd.com/
> >> > Sent from Bury, United Kingdom
> >> >
> >>
> >>
> >>
> >> --
> >> -----------------------------------------------------
> >> Noble Paul | Principal Engineer| AOL | http://aol.com
> >
> >
> >
> > --
> > http://twitter.com/goodgravy
> > 512 300 4210
> > http://webmynd.com/
> > Sent from Bury, United Kingdom
>
>
>
> --
> -----------------------------------------------------
> Noble Paul | Principal Engineer| AOL | http://aol.com
>
--
http://twitter.com/goodgravy
512 300 4210
http://webmynd.com/
Sent from Bury, United Kingdom
Re: ClassCastException from custom request handler
Posted by James Brady <ja...@gmail.com>.
Hi, the LiveCoresHandler is in the default package - the behaviour's the
same if I have it in a properly namespaced package too...
The requestHandler name can start either be a path (starting with '/') or a
qt name:
http://wiki.apache.org/solr/SolrRequestHandler
2009/8/4 Noble Paul നോബിള് नोब्ळ् <no...@corp.aol.com>
> what is the package of LiveCoresHandler ?
> I guess the requestHandler name should be name="/livecores"
>
> On Tue, Aug 4, 2009 at 5:04 PM, James Brady<ja...@gmail.com>
> wrote:
> > Solr version: 1.3.0 694707
> >
> > solrconfig.xml:
> > <requestHandler name="livecores" class="LiveCoresHandler" />
> >
> > public class LiveCoresHandler extends RequestHandlerBase {
> > public void init(NamedList args) { }
> > public String getDescription() { return ""; }
> > public String getSource() { return ""; }
> > public String getSourceId() { return ""; }
> > public NamedList getStatistics() { return new NamedList(); }
> > public String getVersion() { return ""; }
> >
> > public void handleRequestBody(SolrQueryRequest req, SolrQueryResponse
> > rsp) {
> > Collection<String> names =
> > req.getCore().getCoreDescriptor().getCoreContainer().getCoreNames();
> > rsp.add("cores", names);
> > // if the cores are dynamic, you prob don't want to cache
> > rsp.setHttpCaching(false);
> > }
> > }
> >
> > 2009/8/4 Avlesh Singh <av...@gmail.com>
> >
> >> >
> >> > I'm sure I have the class name right - changing it to something
> patently
> >> > incorrect results in the expected
> "org.apache.solr.common.SolrException:
> >> > Error loading class ...", rather thanthe ClassCastException.
> >> >
> >> You are right about that, James.
> >>
> >> Which Solr version are you using?
> >> Can you please paste the relevant pieces in your solrconfig.xml and the
> >> request handler class you have created?
> >>
> >> Cheers
> >> Avlesh
> >>
> >> On Mon, Aug 3, 2009 at 10:51 PM, James Brady <
> james.colin.brady@gmail.com
> >> >wrote:
> >>
> >> > Hi,
> >> > Thanks for your suggestions!
> >> >
> >> > I'm sure I have the class name right - changing it to something
> patently
> >> > incorrect results in the expected
> >> > "org.apache.solr.common.SolrException: Error loading class ...",
> rather
> >> > than
> >> > the ClassCastException.
> >> >
> >> > I did have some problems getting my class on the app server's
> classpath.
> >> > I'm
> >> > running with solr.home set to "multicore", but creating a
> multicore/lib
> >> > directory and putting my request handler class in there resulted in
> >> "Error
> >> > loading class" errors.
> >> >
> >> > I found that setting jetty.class.path to include multicore/lib (and
> also
> >> > explicitly point at Solr's core and common JARs) fixed the "Error
> loading
> >> > class" errors, leaving these ClassCastExceptions...
> >> >
> >> > 2009/8/3 Avlesh Singh <av...@gmail.com>
> >> >
> >> > > Can you cross check the class attribute for your handler in
> >> > solrconfig.xml?
> >> > > My guess is that it is specified as "solr.LiveCoresHandler". It
> should
> >> be
> >> > > fully qualified class name - com.foo.path.to.LiveCoresHandler
> instead.
> >> > >
> >> > > Moreover, I am damn sure that you did not forget to drop your jar
> into
> >> > > solr.home/lib. Checking once again might not be a bad idea :)
> >> > >
> >> > > Cheers
> >> > > Avlesh
> >> > >
> >> > > On Mon, Aug 3, 2009 at 9:11 PM, James Brady <
> >> james.colin.brady@gmail.com
> >> > > >wrote:
> >> > >
> >> > > > Hi,
> >> > > > I'm creating a custom request handler to return a list of live
> cores
> >> in
> >> > > > Solr.
> >> > > >
> >> > > > On startup, I get this exception for each core:
> >> > > >
> >> > > > Jul 31, 2009 5:20:39 PM org.apache.solr.common. SolrException log
> >> > > > SEVERE: java.lang.ClassCastException: LiveCoresHandler
> >> > > > at
> >> > > >
> >> org.apache.solr.core.RequestHandlers$1.create(RequestHandlers.java:152)
> >> > > > at
> >> > > >
> >> org.apache.solr.core.RequestHandlers$1.create(RequestHandlers.java:161)
> >> > > > at
> >> > > >
> >> > > >
> >> > >
> >> >
> >>
> org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:140)
> >> > > > at
> >> > > >
> >> > > >
> >> > >
> >> >
> >>
> org.apache.solr.core.RequestHandlers.initHandlersFromConfig(RequestHandlers.java:169)
> >> > > > at org.apache.solr.core.SolrCore.<init>(SolrCore.java:444)
> >> > > >
> >> > > > I've tried a few variations on the class definition, including
> >> > extending
> >> > > > RequestHandlerBase (as suggested here:
> >> > > >
> >> > > >
> >> > >
> >> >
> >>
> http://wiki.apache.org/solr/SolrRequestHandler#head-1de7365d7ecf2eac079c5f8b92ee9af712ed75c2
> >> > > > )
> >> > > > and implementing SolrRequestHandler directly.
> >> > > >
> >> > > > I'm sure that the Solr libraries I built against and those I'm
> >> running
> >> > on
> >> > > > are the same version too, as I unzipped the Solr war file and
> copies
> >> > the
> >> > > > relevant jars out of there to build against.
> >> > > >
> >> > > > Any ideas on what could be causing the ClassCastException? I've
> >> > attached
> >> > > a
> >> > > > debugger to the running Solr process but it didn't shed any light
> on
> >> > the
> >> > > > issue...
> >> > > >
> >> > > > Thanks!
> >> > > > James
> >> > > >
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> > http://twitter.com/goodgravy
> >> > 512 300 4210
> >> > http://webmynd.com/
> >> > Sent from Bury, United Kingdom
> >> >
> >>
> >
> >
> >
> > --
> > http://twitter.com/goodgravy
> > 512 300 4210
> > http://webmynd.com/
> > Sent from Bury, United Kingdom
> >
>
>
>
> --
> -----------------------------------------------------
> Noble Paul | Principal Engineer| AOL | http://aol.com
>
--
http://twitter.com/goodgravy
512 300 4210
http://webmynd.com/
Sent from Bury, United Kingdom
Re: ClassCastException from custom request handler
Posted by Noble Paul നോബിള് नोब्ळ् <no...@corp.aol.com>.
what is the package of LiveCoresHandler ?
I guess the requestHandler name should be name="/livecores"
On Tue, Aug 4, 2009 at 5:04 PM, James Brady<ja...@gmail.com> wrote:
> Solr version: 1.3.0 694707
>
> solrconfig.xml:
> <requestHandler name="livecores" class="LiveCoresHandler" />
>
> public class LiveCoresHandler extends RequestHandlerBase {
> public void init(NamedList args) { }
> public String getDescription() { return ""; }
> public String getSource() { return ""; }
> public String getSourceId() { return ""; }
> public NamedList getStatistics() { return new NamedList(); }
> public String getVersion() { return ""; }
>
> public void handleRequestBody(SolrQueryRequest req, SolrQueryResponse
> rsp) {
> Collection<String> names =
> req.getCore().getCoreDescriptor().getCoreContainer().getCoreNames();
> rsp.add("cores", names);
> // if the cores are dynamic, you prob don't want to cache
> rsp.setHttpCaching(false);
> }
> }
>
> 2009/8/4 Avlesh Singh <av...@gmail.com>
>
>> >
>> > I'm sure I have the class name right - changing it to something patently
>> > incorrect results in the expected "org.apache.solr.common.SolrException:
>> > Error loading class ...", rather thanthe ClassCastException.
>> >
>> You are right about that, James.
>>
>> Which Solr version are you using?
>> Can you please paste the relevant pieces in your solrconfig.xml and the
>> request handler class you have created?
>>
>> Cheers
>> Avlesh
>>
>> On Mon, Aug 3, 2009 at 10:51 PM, James Brady <james.colin.brady@gmail.com
>> >wrote:
>>
>> > Hi,
>> > Thanks for your suggestions!
>> >
>> > I'm sure I have the class name right - changing it to something patently
>> > incorrect results in the expected
>> > "org.apache.solr.common.SolrException: Error loading class ...", rather
>> > than
>> > the ClassCastException.
>> >
>> > I did have some problems getting my class on the app server's classpath.
>> > I'm
>> > running with solr.home set to "multicore", but creating a multicore/lib
>> > directory and putting my request handler class in there resulted in
>> "Error
>> > loading class" errors.
>> >
>> > I found that setting jetty.class.path to include multicore/lib (and also
>> > explicitly point at Solr's core and common JARs) fixed the "Error loading
>> > class" errors, leaving these ClassCastExceptions...
>> >
>> > 2009/8/3 Avlesh Singh <av...@gmail.com>
>> >
>> > > Can you cross check the class attribute for your handler in
>> > solrconfig.xml?
>> > > My guess is that it is specified as "solr.LiveCoresHandler". It should
>> be
>> > > fully qualified class name - com.foo.path.to.LiveCoresHandler instead.
>> > >
>> > > Moreover, I am damn sure that you did not forget to drop your jar into
>> > > solr.home/lib. Checking once again might not be a bad idea :)
>> > >
>> > > Cheers
>> > > Avlesh
>> > >
>> > > On Mon, Aug 3, 2009 at 9:11 PM, James Brady <
>> james.colin.brady@gmail.com
>> > > >wrote:
>> > >
>> > > > Hi,
>> > > > I'm creating a custom request handler to return a list of live cores
>> in
>> > > > Solr.
>> > > >
>> > > > On startup, I get this exception for each core:
>> > > >
>> > > > Jul 31, 2009 5:20:39 PM org.apache.solr.common. SolrException log
>> > > > SEVERE: java.lang.ClassCastException: LiveCoresHandler
>> > > > at
>> > > >
>> org.apache.solr.core.RequestHandlers$1.create(RequestHandlers.java:152)
>> > > > at
>> > > >
>> org.apache.solr.core.RequestHandlers$1.create(RequestHandlers.java:161)
>> > > > at
>> > > >
>> > > >
>> > >
>> >
>> org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:140)
>> > > > at
>> > > >
>> > > >
>> > >
>> >
>> org.apache.solr.core.RequestHandlers.initHandlersFromConfig(RequestHandlers.java:169)
>> > > > at org.apache.solr.core.SolrCore.<init>(SolrCore.java:444)
>> > > >
>> > > > I've tried a few variations on the class definition, including
>> > extending
>> > > > RequestHandlerBase (as suggested here:
>> > > >
>> > > >
>> > >
>> >
>> http://wiki.apache.org/solr/SolrRequestHandler#head-1de7365d7ecf2eac079c5f8b92ee9af712ed75c2
>> > > > )
>> > > > and implementing SolrRequestHandler directly.
>> > > >
>> > > > I'm sure that the Solr libraries I built against and those I'm
>> running
>> > on
>> > > > are the same version too, as I unzipped the Solr war file and copies
>> > the
>> > > > relevant jars out of there to build against.
>> > > >
>> > > > Any ideas on what could be causing the ClassCastException? I've
>> > attached
>> > > a
>> > > > debugger to the running Solr process but it didn't shed any light on
>> > the
>> > > > issue...
>> > > >
>> > > > Thanks!
>> > > > James
>> > > >
>> > >
>> >
>> >
>> >
>> > --
>> > http://twitter.com/goodgravy
>> > 512 300 4210
>> > http://webmynd.com/
>> > Sent from Bury, United Kingdom
>> >
>>
>
>
>
> --
> http://twitter.com/goodgravy
> 512 300 4210
> http://webmynd.com/
> Sent from Bury, United Kingdom
>
--
-----------------------------------------------------
Noble Paul | Principal Engineer| AOL | http://aol.com
Re: ClassCastException from custom request handler
Posted by James Brady <ja...@gmail.com>.
Solr version: 1.3.0 694707
solrconfig.xml:
<requestHandler name="livecores" class="LiveCoresHandler" />
public class LiveCoresHandler extends RequestHandlerBase {
public void init(NamedList args) { }
public String getDescription() { return ""; }
public String getSource() { return ""; }
public String getSourceId() { return ""; }
public NamedList getStatistics() { return new NamedList(); }
public String getVersion() { return ""; }
public void handleRequestBody(SolrQueryRequest req, SolrQueryResponse
rsp) {
Collection<String> names =
req.getCore().getCoreDescriptor().getCoreContainer().getCoreNames();
rsp.add("cores", names);
// if the cores are dynamic, you prob don't want to cache
rsp.setHttpCaching(false);
}
}
2009/8/4 Avlesh Singh <av...@gmail.com>
> >
> > I'm sure I have the class name right - changing it to something patently
> > incorrect results in the expected "org.apache.solr.common.SolrException:
> > Error loading class ...", rather thanthe ClassCastException.
> >
> You are right about that, James.
>
> Which Solr version are you using?
> Can you please paste the relevant pieces in your solrconfig.xml and the
> request handler class you have created?
>
> Cheers
> Avlesh
>
> On Mon, Aug 3, 2009 at 10:51 PM, James Brady <james.colin.brady@gmail.com
> >wrote:
>
> > Hi,
> > Thanks for your suggestions!
> >
> > I'm sure I have the class name right - changing it to something patently
> > incorrect results in the expected
> > "org.apache.solr.common.SolrException: Error loading class ...", rather
> > than
> > the ClassCastException.
> >
> > I did have some problems getting my class on the app server's classpath.
> > I'm
> > running with solr.home set to "multicore", but creating a multicore/lib
> > directory and putting my request handler class in there resulted in
> "Error
> > loading class" errors.
> >
> > I found that setting jetty.class.path to include multicore/lib (and also
> > explicitly point at Solr's core and common JARs) fixed the "Error loading
> > class" errors, leaving these ClassCastExceptions...
> >
> > 2009/8/3 Avlesh Singh <av...@gmail.com>
> >
> > > Can you cross check the class attribute for your handler in
> > solrconfig.xml?
> > > My guess is that it is specified as "solr.LiveCoresHandler". It should
> be
> > > fully qualified class name - com.foo.path.to.LiveCoresHandler instead.
> > >
> > > Moreover, I am damn sure that you did not forget to drop your jar into
> > > solr.home/lib. Checking once again might not be a bad idea :)
> > >
> > > Cheers
> > > Avlesh
> > >
> > > On Mon, Aug 3, 2009 at 9:11 PM, James Brady <
> james.colin.brady@gmail.com
> > > >wrote:
> > >
> > > > Hi,
> > > > I'm creating a custom request handler to return a list of live cores
> in
> > > > Solr.
> > > >
> > > > On startup, I get this exception for each core:
> > > >
> > > > Jul 31, 2009 5:20:39 PM org.apache.solr.common. SolrException log
> > > > SEVERE: java.lang.ClassCastException: LiveCoresHandler
> > > > at
> > > >
> org.apache.solr.core.RequestHandlers$1.create(RequestHandlers.java:152)
> > > > at
> > > >
> org.apache.solr.core.RequestHandlers$1.create(RequestHandlers.java:161)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:140)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.solr.core.RequestHandlers.initHandlersFromConfig(RequestHandlers.java:169)
> > > > at org.apache.solr.core.SolrCore.<init>(SolrCore.java:444)
> > > >
> > > > I've tried a few variations on the class definition, including
> > extending
> > > > RequestHandlerBase (as suggested here:
> > > >
> > > >
> > >
> >
> http://wiki.apache.org/solr/SolrRequestHandler#head-1de7365d7ecf2eac079c5f8b92ee9af712ed75c2
> > > > )
> > > > and implementing SolrRequestHandler directly.
> > > >
> > > > I'm sure that the Solr libraries I built against and those I'm
> running
> > on
> > > > are the same version too, as I unzipped the Solr war file and copies
> > the
> > > > relevant jars out of there to build against.
> > > >
> > > > Any ideas on what could be causing the ClassCastException? I've
> > attached
> > > a
> > > > debugger to the running Solr process but it didn't shed any light on
> > the
> > > > issue...
> > > >
> > > > Thanks!
> > > > James
> > > >
> > >
> >
> >
> >
> > --
> > http://twitter.com/goodgravy
> > 512 300 4210
> > http://webmynd.com/
> > Sent from Bury, United Kingdom
> >
>
--
http://twitter.com/goodgravy
512 300 4210
http://webmynd.com/
Sent from Bury, United Kingdom
Re: ClassCastException from custom request handler
Posted by Avlesh Singh <av...@gmail.com>.
>
> I'm sure I have the class name right - changing it to something patently
> incorrect results in the expected "org.apache.solr.common.SolrException:
> Error loading class ...", rather thanthe ClassCastException.
>
You are right about that, James.
Which Solr version are you using?
Can you please paste the relevant pieces in your solrconfig.xml and the
request handler class you have created?
Cheers
Avlesh
On Mon, Aug 3, 2009 at 10:51 PM, James Brady <ja...@gmail.com>wrote:
> Hi,
> Thanks for your suggestions!
>
> I'm sure I have the class name right - changing it to something patently
> incorrect results in the expected
> "org.apache.solr.common.SolrException: Error loading class ...", rather
> than
> the ClassCastException.
>
> I did have some problems getting my class on the app server's classpath.
> I'm
> running with solr.home set to "multicore", but creating a multicore/lib
> directory and putting my request handler class in there resulted in "Error
> loading class" errors.
>
> I found that setting jetty.class.path to include multicore/lib (and also
> explicitly point at Solr's core and common JARs) fixed the "Error loading
> class" errors, leaving these ClassCastExceptions...
>
> 2009/8/3 Avlesh Singh <av...@gmail.com>
>
> > Can you cross check the class attribute for your handler in
> solrconfig.xml?
> > My guess is that it is specified as "solr.LiveCoresHandler". It should be
> > fully qualified class name - com.foo.path.to.LiveCoresHandler instead.
> >
> > Moreover, I am damn sure that you did not forget to drop your jar into
> > solr.home/lib. Checking once again might not be a bad idea :)
> >
> > Cheers
> > Avlesh
> >
> > On Mon, Aug 3, 2009 at 9:11 PM, James Brady <james.colin.brady@gmail.com
> > >wrote:
> >
> > > Hi,
> > > I'm creating a custom request handler to return a list of live cores in
> > > Solr.
> > >
> > > On startup, I get this exception for each core:
> > >
> > > Jul 31, 2009 5:20:39 PM org.apache.solr.common. SolrException log
> > > SEVERE: java.lang.ClassCastException: LiveCoresHandler
> > > at
> > > org.apache.solr.core.RequestHandlers$1.create(RequestHandlers.java:152)
> > > at
> > > org.apache.solr.core.RequestHandlers$1.create(RequestHandlers.java:161)
> > > at
> > >
> > >
> >
> org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:140)
> > > at
> > >
> > >
> >
> org.apache.solr.core.RequestHandlers.initHandlersFromConfig(RequestHandlers.java:169)
> > > at org.apache.solr.core.SolrCore.<init>(SolrCore.java:444)
> > >
> > > I've tried a few variations on the class definition, including
> extending
> > > RequestHandlerBase (as suggested here:
> > >
> > >
> >
> http://wiki.apache.org/solr/SolrRequestHandler#head-1de7365d7ecf2eac079c5f8b92ee9af712ed75c2
> > > )
> > > and implementing SolrRequestHandler directly.
> > >
> > > I'm sure that the Solr libraries I built against and those I'm running
> on
> > > are the same version too, as I unzipped the Solr war file and copies
> the
> > > relevant jars out of there to build against.
> > >
> > > Any ideas on what could be causing the ClassCastException? I've
> attached
> > a
> > > debugger to the running Solr process but it didn't shed any light on
> the
> > > issue...
> > >
> > > Thanks!
> > > James
> > >
> >
>
>
>
> --
> http://twitter.com/goodgravy
> 512 300 4210
> http://webmynd.com/
> Sent from Bury, United Kingdom
>
Re: ClassCastException from custom request handler
Posted by James Brady <ja...@gmail.com>.
Hi,
Thanks for your suggestions!
I'm sure I have the class name right - changing it to something patently
incorrect results in the expected
"org.apache.solr.common.SolrException: Error loading class ...", rather than
the ClassCastException.
I did have some problems getting my class on the app server's classpath. I'm
running with solr.home set to "multicore", but creating a multicore/lib
directory and putting my request handler class in there resulted in "Error
loading class" errors.
I found that setting jetty.class.path to include multicore/lib (and also
explicitly point at Solr's core and common JARs) fixed the "Error loading
class" errors, leaving these ClassCastExceptions...
2009/8/3 Avlesh Singh <av...@gmail.com>
> Can you cross check the class attribute for your handler in solrconfig.xml?
> My guess is that it is specified as "solr.LiveCoresHandler". It should be
> fully qualified class name - com.foo.path.to.LiveCoresHandler instead.
>
> Moreover, I am damn sure that you did not forget to drop your jar into
> solr.home/lib. Checking once again might not be a bad idea :)
>
> Cheers
> Avlesh
>
> On Mon, Aug 3, 2009 at 9:11 PM, James Brady <james.colin.brady@gmail.com
> >wrote:
>
> > Hi,
> > I'm creating a custom request handler to return a list of live cores in
> > Solr.
> >
> > On startup, I get this exception for each core:
> >
> > Jul 31, 2009 5:20:39 PM org.apache.solr.common. SolrException log
> > SEVERE: java.lang.ClassCastException: LiveCoresHandler
> > at
> > org.apache.solr.core.RequestHandlers$1.create(RequestHandlers.java:152)
> > at
> > org.apache.solr.core.RequestHandlers$1.create(RequestHandlers.java:161)
> > at
> >
> >
> org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:140)
> > at
> >
> >
> org.apache.solr.core.RequestHandlers.initHandlersFromConfig(RequestHandlers.java:169)
> > at org.apache.solr.core.SolrCore.<init>(SolrCore.java:444)
> >
> > I've tried a few variations on the class definition, including extending
> > RequestHandlerBase (as suggested here:
> >
> >
> http://wiki.apache.org/solr/SolrRequestHandler#head-1de7365d7ecf2eac079c5f8b92ee9af712ed75c2
> > )
> > and implementing SolrRequestHandler directly.
> >
> > I'm sure that the Solr libraries I built against and those I'm running on
> > are the same version too, as I unzipped the Solr war file and copies the
> > relevant jars out of there to build against.
> >
> > Any ideas on what could be causing the ClassCastException? I've attached
> a
> > debugger to the running Solr process but it didn't shed any light on the
> > issue...
> >
> > Thanks!
> > James
> >
>
--
http://twitter.com/goodgravy
512 300 4210
http://webmynd.com/
Sent from Bury, United Kingdom
Re: ClassCastException from custom request handler
Posted by Avlesh Singh <av...@gmail.com>.
Can you cross check the class attribute for your handler in solrconfig.xml?
My guess is that it is specified as "solr.LiveCoresHandler". It should be
fully qualified class name - com.foo.path.to.LiveCoresHandler instead.
Moreover, I am damn sure that you did not forget to drop your jar into
solr.home/lib. Checking once again might not be a bad idea :)
Cheers
Avlesh
On Mon, Aug 3, 2009 at 9:11 PM, James Brady <ja...@gmail.com>wrote:
> Hi,
> I'm creating a custom request handler to return a list of live cores in
> Solr.
>
> On startup, I get this exception for each core:
>
> Jul 31, 2009 5:20:39 PM org.apache.solr.common. SolrException log
> SEVERE: java.lang.ClassCastException: LiveCoresHandler
> at
> org.apache.solr.core.RequestHandlers$1.create(RequestHandlers.java:152)
> at
> org.apache.solr.core.RequestHandlers$1.create(RequestHandlers.java:161)
> at
>
> org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:140)
> at
>
> org.apache.solr.core.RequestHandlers.initHandlersFromConfig(RequestHandlers.java:169)
> at org.apache.solr.core.SolrCore.<init>(SolrCore.java:444)
>
> I've tried a few variations on the class definition, including extending
> RequestHandlerBase (as suggested here:
>
> http://wiki.apache.org/solr/SolrRequestHandler#head-1de7365d7ecf2eac079c5f8b92ee9af712ed75c2
> )
> and implementing SolrRequestHandler directly.
>
> I'm sure that the Solr libraries I built against and those I'm running on
> are the same version too, as I unzipped the Solr war file and copies the
> relevant jars out of there to build against.
>
> Any ideas on what could be causing the ClassCastException? I've attached a
> debugger to the running Solr process but it didn't shed any light on the
> issue...
>
> Thanks!
> James
>
Re: ClassCastException from custom request handler
Posted by Noble Paul നോബിള് नोब्ळ् <no...@corp.aol.com>.
I guess a requesthandler may not be the right component to implement.
try implementing a CoreAdminHandler .
http://wiki.apache.org/solr/CoreAdmin#head-dfab3233db613c1976e05cdf894aa326ca64d312
On Mon, Aug 3, 2009 at 9:11 PM, James Brady<ja...@gmail.com> wrote:
> Hi,
> I'm creating a custom request handler to return a list of live cores in
> Solr.
>
> On startup, I get this exception for each core:
>
> Jul 31, 2009 5:20:39 PM org.apache.solr.common. SolrException log
> SEVERE: java.lang.ClassCastException: LiveCoresHandler
> at
> org.apache.solr.core.RequestHandlers$1.create(RequestHandlers.java:152)
> at
> org.apache.solr.core.RequestHandlers$1.create(RequestHandlers.java:161)
> at
> org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:140)
> at
> org.apache.solr.core.RequestHandlers.initHandlersFromConfig(RequestHandlers.java:169)
> at org.apache.solr.core.SolrCore.<init>(SolrCore.java:444)
>
> I've tried a few variations on the class definition, including extending
> RequestHandlerBase (as suggested here:
> http://wiki.apache.org/solr/SolrRequestHandler#head-1de7365d7ecf2eac079c5f8b92ee9af712ed75c2)
> and implementing SolrRequestHandler directly.
>
> I'm sure that the Solr libraries I built against and those I'm running on
> are the same version too, as I unzipped the Solr war file and copies the
> relevant jars out of there to build against.
>
> Any ideas on what could be causing the ClassCastException? I've attached a
> debugger to the running Solr process but it didn't shed any light on the
> issue...
>
> Thanks!
> James
>
--
-----------------------------------------------------
Noble Paul | Principal Engineer| AOL | http://aol.com