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 <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
--
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.
