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 <chantal.ackerm...@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 നോബിള് नोब्ळ् <noble.p...@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<james.colin.br...@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 നോബിള് नोब्ळ् <noble.p...@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.br...@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 <avl...@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.br...@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 <avl...@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.br...@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.ackerm...@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
