Could not initialize class org.apache.solr.core.SolrCore
Title: Could not initialize class org.apache.solr.core.SolrCore I am sure this is a dumb mistake, but i followed the set up of SOLR/tomcat 5.5.20, but i keep getting this error.. java.lang.NoClassDefFoundError: Could not initialize class org.apache.solr.core.SolrCore org.apache.jsp.admin.index_jsp._jspService(index_jsp.java:80) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:334) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) when viewing the admin page,i am sure i followed the install settings correctly. any ideas? Jeryl Cook
[jira] Updated: (SOLR-99) Allow default sort order
[
https://issues.apache.org/jira/browse/SOLR-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-99:
--
Attachment: DefaultSortOrder.patch
Allow default sort order
Key: SOLR-99
URL: https://issues.apache.org/jira/browse/SOLR-99
Project: Solr
Issue Type: Improvement
Components: search
Affects Versions: 1.2
Reporter: Ryan McKinley
Priority: Minor
Fix For: 1.2
Attachments: DefaultSortOrder.patch, DefaultSortOrder.patch
The current search throws an ArrayIndexOutOfBoundsException if you specify
a sort field but do not include an order. This is anoying and difficult to
debug (when you are starting)
Here is a patch to avoid the exception and use the default sort order if you
only specify a field. I'm not sure the 'null' case was even possible in the
current code:
Index: QueryParsing.java
===
--- QueryParsing.java (revision 494681)
+++ QueryParsing.java (working copy)
@@ -186,13 +186,12 @@
}
// get the direction of the sort
- str=parts[pos];
- if (top.equals(str) || desc.equals(str)) {
-top=true;
- } else if (bottom.equals(str) || asc.equals(str)) {
-top=false;
- } else {
-return null; // must not be a sort command
+ // by default, top is true, only change it if it is bottom or asc
+ if( parts.length pos ) {
+ str=parts[pos];
+ if (bottom.equals(str) || asc.equals(str)) {
+ top=false;
+ }
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SOLR-99) Allow default sort order
[
https://issues.apache.org/jira/browse/SOLR-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463530
]
Ryan McKinley commented on SOLR-99:
---
I apologize... the first version does not pass
ConvertedLegacyTest.testABunchOfConvertedStuff()!
This second version rewrites most of parseSort() and passes the tests.
I am a bit confused by the old parser because it seems to be handling a legacy
paging system. The javadocs show the sort formats as:
* Examples:
* pre
* top 10#take the top 10 by score
* desc 10 #take the top 10 by score
* score desc 10 #take the top 10 by score
* weight bottom 10 #sort by weight ascending and take the
first 10
* weight desc #sort by weight descending
* height desc,weight desc #sort by height descending, and use
weight descending to break any ties
* height desc,weight asc top 20 #sort by height descending, using weight
ascending as a tiebreaker
*/pre
This puts the count in the SortSpec.num field.
SortSpec.getCount() is only called from: SolrPluginUtils.doSimpleQuery(). Is
this a mistake? Isn't the count specified from rows=XXX?
Allow default sort order
Key: SOLR-99
URL: https://issues.apache.org/jira/browse/SOLR-99
Project: Solr
Issue Type: Improvement
Components: search
Affects Versions: 1.2
Reporter: Ryan McKinley
Priority: Minor
Fix For: 1.2
Attachments: DefaultSortOrder.patch, DefaultSortOrder.patch
The current search throws an ArrayIndexOutOfBoundsException if you specify
a sort field but do not include an order. This is anoying and difficult to
debug (when you are starting)
Here is a patch to avoid the exception and use the default sort order if you
only specify a field. I'm not sure the 'null' case was even possible in the
current code:
Index: QueryParsing.java
===
--- QueryParsing.java (revision 494681)
+++ QueryParsing.java (working copy)
@@ -186,13 +186,12 @@
}
// get the direction of the sort
- str=parts[pos];
- if (top.equals(str) || desc.equals(str)) {
-top=true;
- } else if (bottom.equals(str) || asc.equals(str)) {
-top=false;
- } else {
-return null; // must not be a sort command
+ // by default, top is true, only change it if it is bottom or asc
+ if( parts.length pos ) {
+ str=parts[pos];
+ if (bottom.equals(str) || asc.equals(str)) {
+ top=false;
+ }
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Could not initialize class org.apache.solr.core.SolrCore
On 1/10/07, Cook, Jeryl [EMAIL PROTECTED] wrote: I am sure this is a dumb mistake, but i followed the set up of SOLR/tomcat 5.5.20, but i keep getting this error.. java.lang.NoClassDefFoundError: Could not initialize class org.apache.solr.core.SolrCore Look for the first errors that appear in the tomcat log files. Hopefully at least one should provide an error message that points to the problem. -Yonik
Re: Handling disparate data sources in Solr
Chris Hostetter wrote: : 1. The document is already decomposed into fields before the : insert/update, but one or more of the fields requires special handling. : 2. The document contains both metadata and content. PDF is a good : example of such a document type. there's a third big example: multiple documents are compused into a single stream of raw data, and you want Solr to extract the individual documents. the simplest example of this case being that you want to point Solr at a CSV file where each record is a document. Or a tar file, or a zip file... Yes, that definitely seems like something that should be covered as well. : And for both of these you'd need to be able to specify the mapping : between the data/metadata in the source document and the corresponding : Solr schema fields. I'm not sure if you'd want this in the : solrconfig.xml file or in the indexing request itself. Doing it in : solrconfig.xml means you could change the disposition of the indexed : data without changing the clients submitting the content. right ... i think that's something that could be controlled on a per parser basis, much they way RequestHandlers can currently take in a lot of options at request time, but can also have default values (or invariant values) specified for those options in the solrconfig when they are registered. Agreed. : That was the reasoning behind my initial suggestion: : : | Extend the doc and field element with the following attributes: Right, i was suggesting we take it to the next level, and allow for plugins to handle updates that didn't have to have any XML encapsulation at all -- the options and the raw data stream could be expressed entirely in the HttpServletRequest for the update .. which would still allow us to add the type of syntax you are describing to some new XmlUpdateSource containing the refactored code which currently parses updates in SolrCore. Hmm. Any idea of how much work this involves? As I said I can put time towards this, but I don't know the innards of Solr as well as you and the other folks on this list. -- Alan Burlison --
Re: Could not initialize class org.apache.solr.core.SolrCore
I just ran into this myself, it's because there is no jndi entry for solr.home. A little further down on the wiki for installing tomcat is the instruction to create a solr.xml file and place it in TOMCAT_HOME/conf/Catalina/localhost you have to change the Environment entry to point to your solr.home; ie, where your indexes actually live. Hope that helps, Rick --- Yonik Seeley [EMAIL PROTECTED] wrote: On 1/10/07, Cook, Jeryl [EMAIL PROTECTED] wrote: I am sure this is a dumb mistake, but i followed the set up of SOLR/tomcat 5.5.20, but i keep getting this error.. java.lang.NoClassDefFoundError: Could not initialize class org.apache.solr.core.SolrCore Look for the first errors that appear in the tomcat log files. Hopefully at least one should provide an error message that points to the problem. -Yonik
[jira] Updated: (SOLR-100) Exception handling for Solrb w/ test
[ https://issues.apache.org/jira/browse/SOLR-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Groppe updated SOLR-100: Attachment: exception_handling.patch Exception handling for Solrb w/ test Key: SOLR-100 URL: https://issues.apache.org/jira/browse/SOLR-100 Project: Solr Issue Type: Improvement Components: clients - ruby - flare Environment: Darwin rocket 8.8.1 Darwin Kernel Version 8.8.1: Mon Sep 25 19:42:00 PDT 2006; root:xnu-792.13.8.obj~1/RELEASE_I386 i386 i386 Reporter: William Groppe Attachments: exception_handling.patch This patch includes modifications for raising both HTTP, and Solr errors during the handling of a request. A unit test is included. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SOLR-100) Exception handling for Solrb w/ test
Exception handling for Solrb w/ test Key: SOLR-100 URL: https://issues.apache.org/jira/browse/SOLR-100 Project: Solr Issue Type: Improvement Components: clients - ruby - flare Environment: Darwin rocket 8.8.1 Darwin Kernel Version 8.8.1: Mon Sep 25 19:42:00 PDT 2006; root:xnu-792.13.8.obj~1/RELEASE_I386 i386 i386 Reporter: William Groppe Attachments: exception_handling.patch This patch includes modifications for raising both HTTP, and Solr errors during the handling of a request. A unit test is included. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SOLR-99) Allow default sort order
[
https://issues.apache.org/jira/browse/SOLR-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463695
]
Hoss Man commented on SOLR-99:
--
specifying the number of results to return as part of the sort information is
in fact some fairly legacy behavior that we probably don't need to worry
about supporting (i don't think anyone has ever used it in the history of
Solar/Solr ... but in general i don't think the proper way to address this bug
is to assume a default direction if all the user does is specify a field name
... mainly because i don't know that we can really assume a particular
default ... failing with an error at query time definitely seems like the
right behavior to me ... but we should certainly return a usefull eror message
instead of an ArrayIndexOutOfBoundsException.
In the same way a query which can't be parsed cleanly generates a
ParseException, a sort specification which can't be parsed cleanly should
generate a ParseException (or soemthing like it)
Allow default sort order
Key: SOLR-99
URL: https://issues.apache.org/jira/browse/SOLR-99
Project: Solr
Issue Type: Improvement
Components: search
Affects Versions: 1.2
Reporter: Ryan McKinley
Priority: Minor
Fix For: 1.2
Attachments: DefaultSortOrder.patch, DefaultSortOrder.patch
The current search throws an ArrayIndexOutOfBoundsException if you specify
a sort field but do not include an order. This is anoying and difficult to
debug (when you are starting)
Here is a patch to avoid the exception and use the default sort order if you
only specify a field. I'm not sure the 'null' case was even possible in the
current code:
Index: QueryParsing.java
===
--- QueryParsing.java (revision 494681)
+++ QueryParsing.java (working copy)
@@ -186,13 +186,12 @@
}
// get the direction of the sort
- str=parts[pos];
- if (top.equals(str) || desc.equals(str)) {
-top=true;
- } else if (bottom.equals(str) || asc.equals(str)) {
-top=false;
- } else {
-return null; // must not be a sort command
+ // by default, top is true, only change it if it is bottom or asc
+ if( parts.length pos ) {
+ str=parts[pos];
+ if (bottom.equals(str) || asc.equals(str)) {
+ top=false;
+ }
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SOLR-99) Allow default sort order
[
https://issues.apache.org/jira/browse/SOLR-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463702
]
Yonik Seeley commented on SOLR-99:
--
The number was there because I originally thought about allowing a chain of
sorts to narrow results, so you could do things like:
give me TVs with a 50 screen or bigger, then take the bottom 50% by weight,
then take the bottom 50% by depth, then give me the top 10 by review rating.
expressible by the following syntax:
inches:[50 TO *]; weight bottom 50%; depth bottom 50%; rating top 10
But I never really got around to implementing that :-)
Related bugs: https://issues.apache.org/jira/browse/SOLR-9
Allow default sort order
Key: SOLR-99
URL: https://issues.apache.org/jira/browse/SOLR-99
Project: Solr
Issue Type: Improvement
Components: search
Affects Versions: 1.2
Reporter: Ryan McKinley
Priority: Minor
Fix For: 1.2
Attachments: DefaultSortOrder.patch, DefaultSortOrder.patch
The current search throws an ArrayIndexOutOfBoundsException if you specify
a sort field but do not include an order. This is anoying and difficult to
debug (when you are starting)
Here is a patch to avoid the exception and use the default sort order if you
only specify a field. I'm not sure the 'null' case was even possible in the
current code:
Index: QueryParsing.java
===
--- QueryParsing.java (revision 494681)
+++ QueryParsing.java (working copy)
@@ -186,13 +186,12 @@
}
// get the direction of the sort
- str=parts[pos];
- if (top.equals(str) || desc.equals(str)) {
-top=true;
- } else if (bottom.equals(str) || asc.equals(str)) {
-top=false;
- } else {
-return null; // must not be a sort command
+ // by default, top is true, only change it if it is bottom or asc
+ if( parts.length pos ) {
+ str=parts[pos];
+ if (bottom.equals(str) || asc.equals(str)) {
+ top=false;
+ }
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Update Plugins (was Re: Handling disparate data sources in Solr)
: indexing app I wrote into SOLR. It occurred to me that it would almost : be simpler to use the plugin-friendly QueryRequest mechanism rather than : the UpdateRequest mechanism; coupled with what you wrote below, Hoss, it : makes me think that a little refactoring of request handling might go a : long way: I think you are definitely right ... refacting some of the SolrRequestHandler/SolrQueryRequest/SolrQueryResponse interfaces/abstract base classes to have some bases extendeable by some other SolrUpdateHandler/SolrUpdateRequest/SolrUpdateResponse interfaces/abstract base classes would go a long way. Your post also made me realize that i'd total discounted the issue of returning information about the *results* of the update back to the client ... currently it's done with XML which is ok because in order to send an update the client has to udnerstand XML -- but if we start supporting arbitrary formats for updates, we need to be able to respond in kind. Your comment about reusing SolrQueryResponse and QueryResponseWriters for this sounds perfect. The one hitch i think to the the notion that updates and queries map cleanlly with something like this... SolrRequestHandler = SolrUpdateHandler SolrQueryRequest = SolrUpdateRequest SolrQueryResponse = SolrUpdateResponse (possibly the same class) QueryResponseWriter = UpdateResponseWriter (possible the same class) ...is that with queries, the input tends to be fairly simple. very generic code can be run by the query Servlet to get all of the input params and build the SolrQueryRequest ... but with updates this isn't quite as simple. there's the two issues i spoke of in my earlier mail which should be independenly confiugable: 1) where does the stream of update data come from? is it in the raw POST body? is it in a POSTed multi-part MIME part? is it a remote resource refrenced by URL? 2) how should the raw binary stream of update data be parsed? is it XML? (in the current update format) is it a CSV file? is it a PDF? ...#2 can be what the SolrUpdateHandler interface is all about -- when hitting the update url you specify a ut (update type) that determines that logic ... but it should be independed of #1 maybe the full list of stream sources for #1 is finite and the code for all of them can live in the UpdateServlet ... but it still needs to be an option configured as a param, and it seems like it might as well be a plugin so it's easy for people to write new ones in the future. -Hoss
Re: Handling disparate data sources in Solr
: Hmm. Any idea of how much work this involves? As I said I can put time : towards this, but I don't know the innards of Solr as well as you and : the other folks on this list. I really can't even guess ... i've never even really looked at the current update code. :) -Hoss
[jira] Commented: (SOLR-99) Allow default sort order
[
https://issues.apache.org/jira/browse/SOLR-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463740
]
Yonik Seeley commented on SOLR-99:
--
I agree that throwing a ParseException (ideally a SolrException with a code of
400) with a meaningful error message to help out the user is the right way to
go.
Allow default sort order
Key: SOLR-99
URL: https://issues.apache.org/jira/browse/SOLR-99
Project: Solr
Issue Type: Improvement
Components: search
Affects Versions: 1.2
Reporter: Ryan McKinley
Priority: Minor
Fix For: 1.2
Attachments: DefaultSortOrder.patch, DefaultSortOrder.patch
The current search throws an ArrayIndexOutOfBoundsException if you specify
a sort field but do not include an order. This is anoying and difficult to
debug (when you are starting)
Here is a patch to avoid the exception and use the default sort order if you
only specify a field. I'm not sure the 'null' case was even possible in the
current code:
Index: QueryParsing.java
===
--- QueryParsing.java (revision 494681)
+++ QueryParsing.java (working copy)
@@ -186,13 +186,12 @@
}
// get the direction of the sort
- str=parts[pos];
- if (top.equals(str) || desc.equals(str)) {
-top=true;
- } else if (bottom.equals(str) || asc.equals(str)) {
-top=false;
- } else {
-return null; // must not be a sort command
+ // by default, top is true, only change it if it is bottom or asc
+ if( parts.length pos ) {
+ str=parts[pos];
+ if (bottom.equals(str) || asc.equals(str)) {
+ top=false;
+ }
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SOLR-99) Allow default sort order
[
https://issues.apache.org/jira/browse/SOLR-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463813
]
Ryan McKinley commented on SOLR-99:
---
Ok, we all agree, that it should
1. Throw a reasonable error if something goes wrong
2. Throw an error if you sort on a non-indexed field (SOLR-9)
I still think it should have a default sort order (SQL does) but as long as it
does not throw an ArrayIndexOutOfBoundsException exception I am happy :)
What should happen with the 'legacy' format?
a. leave it as is. (perhaps add a comment for the next person who can't figure
out what it does)
b. get rid of it.
Allow default sort order
Key: SOLR-99
URL: https://issues.apache.org/jira/browse/SOLR-99
Project: Solr
Issue Type: Improvement
Components: search
Affects Versions: 1.2
Reporter: Ryan McKinley
Priority: Minor
Fix For: 1.2
Attachments: DefaultSortOrder.patch, DefaultSortOrder.patch
The current search throws an ArrayIndexOutOfBoundsException if you specify
a sort field but do not include an order. This is anoying and difficult to
debug (when you are starting)
Here is a patch to avoid the exception and use the default sort order if you
only specify a field. I'm not sure the 'null' case was even possible in the
current code:
Index: QueryParsing.java
===
--- QueryParsing.java (revision 494681)
+++ QueryParsing.java (working copy)
@@ -186,13 +186,12 @@
}
// get the direction of the sort
- str=parts[pos];
- if (top.equals(str) || desc.equals(str)) {
-top=true;
- } else if (bottom.equals(str) || asc.equals(str)) {
-top=false;
- } else {
-return null; // must not be a sort command
+ // by default, top is true, only change it if it is bottom or asc
+ if( parts.length pos ) {
+ str=parts[pos];
+ if (bottom.equals(str) || asc.equals(str)) {
+ top=false;
+ }
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
adding modes to the add command
How do you all feel about adding various modes to the add command? Something like: mode=add or replace document (default, the current behavior) mode=add or replace fields mode=add fields mode=add distinct fields The reason i ask is that i would like to frequently update a few fields without having to know anything about the other fields. Ideally it would be from a command like this: addFromSQL mode=add or replace fields connection=jdbc:mysql://localhost/nblmc?username=xxxpassword=xxx driver=com.mysql.jdbc.Driver multifieldSeperator=\n SELECT * FROM my_stats_table /addFromSQL (I'll save the discussion of addFromSQL ... for the next email) To give you examples of how i think these modes would behave, consider you have a database with the following document: doc field name=idXYZ/field field name=count10/field field name=catA/field field name=catB/field field name=catC/field /doc AFTER: add mode=add or replace fields doc field name=idXYZ/field field name=catC/field field name=catD/field /doc /add You would have: doc field name=idXYZ/field field name=count10/field field name=catC/field field name=catD/field /doc -- AFTER: add mode=add fields doc field name=idXYZ/field field name=catC/field field name=catD/field /doc /add You would have: doc field name=idXYZ/field field name=count10/field field name=catA/field field name=catB/field field name=catC/field field name=catC/field field name=catD/field /doc - AFTER: add mode=add distinct fields doc field name=idXYZ/field field name=catC/field field name=catD/field /doc /add You would have: doc field name=idXYZ/field field name=count10/field field name=catA/field field name=catB/field field name=catC/field field name=catD/field /doc I *think* it should even have the same thing if it were given: add mode=add distinct fields doc field name=idXYZ/field field name=catC/field field name=catC/field field name=catC/field field name=catC/field field name=catD/field /doc /add --- Although I am suggesting this for my immediate need (update from SQL), it seems like this would also be useful for anyone building a javascript 'tagging' library. The client could use the add distinct fields mode without worrying about the rest of the document. Essentially, this would ask the server to load and merge documents. If it were added, i think it would go in DirectUpdateHandler.addDoc(AddupdateCommand) [line 312] before checking dupes and overwrite stuff. To accuratly load the 'current' document, it would have to first check the updateHandler.searcher (in case the document is in the updating index) then check the 'real' index. BUT, checking the DirectUpdateHandler.searcher every time you add a document would not be great because the searcher is closed each time. Thoughts? ryan
SQL UpdatePlugin?
I'd like to be able to add/update documents from an SQL query. Perhaps: addFromSQL mode=add or replace fields connection=jdbc:mysql://localhost/nblmc?username=xxxpassword=xxx driver=com.mysql.jdbc.Driver multifieldSeperator=\n SELECT * FROM my_stats_table /addFromSQL This would use the the column names as the field name, and the cell value.toString() as the field value. If the schema says the field can have multiple values AND a multifieldSeperator is defined, it will split the value on that string. To get intended results, you may need to use the 'AS' command and perhaps format the cells using SQL. For example: SELECT itemID AS id, name, DATE_FORMAT( addedTime, '%Y-%m-%dT%H:%i:%s.000Z' ) Should this be an implemented as an Update Plugin? or added directly to the DirectUpdateHandler. If it should be an UpdatePlugin, how do i get started? thanks ryan
Re: adding modes to the add command
On 1/11/07, Ryan McKinley [EMAIL PROTECTED] wrote: How do you all feel about adding various modes to the add command? Something like: mode=add or replace document (default, the current behavior) mode=add or replace fields mode=add fields mode=add distinct fields... Although this is useful as you explain, I like the current simplicity of the Solr HTTP/XML interface very much. The more options we add, the harder it becomes to understand and test the interface. So, IMHO, it would be good for this functionality to be provided in a plugin, disabled by default. IIUC the modifications the the Solr core are minimal, these can included in the core, but (again IMHO, this is debatable for sure) the public interface to this should be provided by a special plugin. -Bertrand
