I can try again this weekend to get a clean environment. However, the order I did things in was the reverse of what you suggest. I got the AbstractSubTypeFieldType error first. Then I removed my jar from the sharedLib folder, and tried the war repacking solution. That is when I got NoClassDefFoundError on my custom class.
The spatial feature looks intriguing, although I have no idea if it could fit my use case. It looks fairly complex a concept, but maybe it is all the different shapes and geometry that is confusing me. If I thought of my problem in terms of geometry, I would say a chromosome region is like a segment of a line. I would need to define multiple line segments and be able to query by a single point and only return documents that have a line segment that the single point falls on. Does that make sense? Is that at all doable with a spatial query? -Kevin ________________________________________ From: Chris Hostetter [hossman_luc...@fucit.org] Sent: Friday, July 19, 2013 3:15 PM To: solr-user@lucene.apache.org Subject: Re: custom field type plugin : a chromosome (or gene, or other object types). All that really boils : down to is being able to give a number, e.g. 10234, and return documents : that have regions containing the number. So you'd have a document with a : list like ["10000:16090","400:8000","40123:43564"], and it should come You should take a look at some of the build in features using the spatial types... http://wiki.apache.org/solr/SpatialForTimeDurations I believe David also covered this usecase in his talk in san diego... http://www.lucenerevolution.org/2013/Lucene-Solr4-Spatial-Deep-Dive : But I get this error about it not being able to find the AbstractSubTypeFieldType class. : Here is the first bit of the trace: ... : Any hints as to what I did wrong? I can provide source code, or a fuller stack trace, config settings, etc. : : Also, I did try to unpack the solr.war, stick my jar in WEB-INF/lib, : then repack. However, when I did that, I get a NoClassDefFoundError for : my plugin itself. a fuller stack trace might help -- but the key question is what order did you try these two approaches in? and what exactly did you fieldType declaration look like? my guess is that you tried repacking the war first, and maybe your exploded war classpath is still polluted with your old jar from when you repacked it and now you have multiple copies in the plugin classloaders classpath. (the initial NoClassDefFoundError could have been from a mistake in your <fieldType/> declaration) try starting competley clean, using the stock war and sample configs and make sure you get no errors. then try declaring your custom fieldType, using hte fully qualified classname w/o even telling solr about your jar, and ensure that you get a NoClassDefFoundError for your custom class -- if you get an error about AbstractSubTypeFieldType again then you still have a copy of your custom class somwhere in the classpath. *THEN* try adding a <lib/> directive to load your jar to load it. if that still doesn't work provide us with the details of your servlet container, solr version, the full stack trace, the details of how you are configuring your <fieldType/>, how you declared the <lib/> what your filesystem looks like for your solrhome, war, etc... -Hoss The information in this email, including attachments, may be confidential and is intended solely for the addressee(s). If you believe you received this email by mistake, please notify the sender by return email as soon as possible.
