[jira] [Commented] (SOLR-3038) Solrj should use javabin wireformat by default with updaterequests
[ https://issues.apache.org/jira/browse/SOLR-3038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13258349#comment-13258349 ] Ryan McKinley commented on SOLR-3038: - +1 to use javabin as the default big -1 to remove XML from solrj in 4.x. Forcing people to upgrade the index and client at the same time does not make any sense -- we spend a lot of effort in solr making sure the client facing behavior does not change regardless of internal changes. bq. 4.x cannot read any indexes older than 3.x with XML, it it can read pre 3.x -- the compatibility problem is with javabin Solrj should use javabin wireformat by default with updaterequests -- Key: SOLR-3038 URL: https://issues.apache.org/jira/browse/SOLR-3038 Project: Solr Issue Type: Improvement Components: clients - java Affects Versions: 4.0 Reporter: Sami Siren Priority: Minor The javabin wire format is faster than xml when feeding Solr - it should become the default. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3387) UpdateRequestHandler should support XML,CSV,JSON, and javabin
[
https://issues.apache.org/jira/browse/SOLR-3387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13258387#comment-13258387
]
Ryan McKinley commented on SOLR-3387:
-
yes -- i'm looking at something like:
{code:java}
private void setDefaultWT(String wt, SolrQueryRequest req) {
SolrParams params = req.getParams();
if( params.get(CommonParams.WT) == null ) {
MapString,String map = new HashMapString,String(1);
map.put(CommonParams.WT, wt);
req.setParams(SolrParams.wrapDefaults(params,
new MapSolrParams(map)));
}
}
{code}
The big change would be that content-type is important. So far only the
charset is used. I think this is an OK change for 4.x and is inline with any
REST service
UpdateRequestHandler should support XML,CSV,JSON, and javabin
-
Key: SOLR-3387
URL: https://issues.apache.org/jira/browse/SOLR-3387
Project: Solr
Issue Type: Improvement
Reporter: Ryan McKinley
Fix For: 4.0
Rather then have 4 handlers to support 4 content types, we should use a
single endpoint and pick the ContentStreamLoader based on the ContentType
This will simplify configuration problems for clients that want to swtich
format (see SOLR-3038)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3387) UpdateRequestHandler should support XML,CSV,JSON, and javabin
[
https://issues.apache.org/jira/browse/SOLR-3387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13258399#comment-13258399
]
Ryan McKinley commented on SOLR-3387:
-
as a quick sketch, I'm looking at something like:
{code:java}
return new ContentStreamLoader() {
XMLLoader xml = null;
JavabinLoader javabin = null;
JsonLoader json = null;
CSVLoader csv = null;
@Override
public void load(SolrQueryRequest req, SolrQueryResponse rsp,
ContentStream stream) throws Exception {
ContentStreamLoader loader = null;
String type = stream.getContentType();
if (type.contains(javabin)) {
if (javabin == null) {
javabin = new JavabinLoader(processor);
setDefaultWT(javabin, req);
}
loader = javabin;
} else if (type.contains(xml)) {
if (xml == null) {
xml = new XMLLoader(processor, inputFactory);
setDefaultWT(xml, req);
}
loader = xml;
} else if (type.contains(json)) {
if (json == null) {
json = new JsonLoader(req, processor);
setDefaultWT(json, req);
}
loader = json;
} else if (type.contains(csv)) {
if (csv == null) {
csv = new SingleThreadedCSVLoader(req, processor);
// setDefaultWT(csv, req); Should this default?
}
loader = csv;
}
if (loader == null) {
throw new SolrException(ErrorCode.BAD_REQUEST,
Unsupported Content-Type: ' + type + ');
}
loader.load(req, rsp, stream);
}
private void setDefaultWT(String wt, SolrQueryRequest req) {
SolrParams params = req.getParams();
if( params.get(CommonParams.WT) == null ) {
MapString,String map = new HashMapString,String(1);
map.put(CommonParams.WT, wt);
req.setParams(SolrParams.wrapDefaults(params,
new MapSolrParams(map)));
}
}
};
{code}
Any red flags? We could have more strict content-type rules
If we like the general idea/approach I'll clean things up with tests etc.
For back compatibility any opinions?
* @Deprecated JsonUpdateRequestHandler could simply extend the general
UpdateRequestHandler (now requiring proper content-type)
* @Deprecated JsonUpdateRequestHandler could could call JsonLoader explicitly
(same as 3.x)
* remove it completely
UpdateRequestHandler should support XML,CSV,JSON, and javabin
-
Key: SOLR-3387
URL: https://issues.apache.org/jira/browse/SOLR-3387
Project: Solr
Issue Type: Improvement
Reporter: Ryan McKinley
Fix For: 4.0
Rather then have 4 handlers to support 4 content types, we should use a
single endpoint and pick the ContentStreamLoader based on the ContentType
This will simplify configuration problems for clients that want to swtich
format (see SOLR-3038)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3038) Solrj should use javabin wireformat by default with updaterequests
[
https://issues.apache.org/jira/browse/SOLR-3038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13258413#comment-13258413
]
Ryan McKinley commented on SOLR-3038:
-
hymm -- to make sure I am not crazy, i just:
1. downloaded solr 1.4.1
2. java -jar start.jar
3. added docs with post.sh
4. ran this quick test from /trunk
{code:java}
public static void main(String[] args) throws SolrServerException {
HttpSolrServer solr = new HttpSolrServer(http://localhost:8983/solr;);
solr.setParser(new XMLResponseParser());
SolrDocumentList docs = solr.query(new SolrQuery(*:*)).getResults();
for( SolrDocument doc : docs ) {
System.out.println(doc);
}
}
{code}
it prints out everything just fine
The lucene index format is unrelated to the XML format that solr uses
Solrj should use javabin wireformat by default with updaterequests
--
Key: SOLR-3038
URL: https://issues.apache.org/jira/browse/SOLR-3038
Project: Solr
Issue Type: Improvement
Components: clients - java
Affects Versions: 4.0
Reporter: Sami Siren
Priority: Minor
The javabin wire format is faster than xml when feeding Solr - it should
become the default.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3387) UpdateRequestHandler should support XML,CSV,JSON, and javabin
[ https://issues.apache.org/jira/browse/SOLR-3387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13258430#comment-13258430 ] Ryan McKinley commented on SOLR-3387: - bq. What about stream.body? stream.body is used to create the ContentStream -- so it does not change anything bq. And how does this play with multi-part uploads? The one difference is that this would let you have different content types in each part -- not really a feature, but worth noting. bq. I wonder if we could do some sort of auto-detect I'll poke -- getStream().mark()/reset() can probably work for XML/JSON but it may break things for javabin UpdateRequestHandler should support XML,CSV,JSON, and javabin - Key: SOLR-3387 URL: https://issues.apache.org/jira/browse/SOLR-3387 Project: Solr Issue Type: Improvement Reporter: Ryan McKinley Fix For: 4.0 Rather then have 4 handlers to support 4 content types, we should use a single endpoint and pick the ContentStreamLoader based on the ContentType This will simplify configuration problems for clients that want to swtich format (see SOLR-3038) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3038) Solrj should use javabin wireformat by default with updaterequests
[ https://issues.apache.org/jira/browse/SOLR-3038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13258460#comment-13258460 ] Ryan McKinley commented on SOLR-3038: - I don't see the motivation for dropping XML -- what is the advantage? Is the hope to drop XMLResponseParser? If so I am strongly against dropping the only plain text way to read NamedList. Ideally we would get out of the object serialization business and delegate to thrift/avero/msgpack/xstream/whatever but that is a long way off. Solrj should use javabin wireformat by default with updaterequests -- Key: SOLR-3038 URL: https://issues.apache.org/jira/browse/SOLR-3038 Project: Solr Issue Type: Improvement Components: clients - java Affects Versions: 4.0 Reporter: Sami Siren Priority: Minor The javabin wire format is faster than xml when feeding Solr - it should become the default. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3038) Solrj should use javabin wireformat by default with updaterequests
[ https://issues.apache.org/jira/browse/SOLR-3038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13258468#comment-13258468 ] Ryan McKinley commented on SOLR-3038: - Having a java client that reads from an old server and writes to a new server does not seem like a crazy thing to support. There needs to be a good reason to drop this basic functionality. Solrj should use javabin wireformat by default with updaterequests -- Key: SOLR-3038 URL: https://issues.apache.org/jira/browse/SOLR-3038 Project: Solr Issue Type: Improvement Components: clients - java Affects Versions: 4.0 Reporter: Sami Siren Priority: Minor The javabin wire format is faster than xml when feeding Solr - it should become the default. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3387) UpdateRequestHandler should support XML,CSV,JSON, and javabin
[
https://issues.apache.org/jira/browse/SOLR-3387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13258509#comment-13258509
]
Ryan McKinley commented on SOLR-3387:
-
Since solr 1.1, the content-type is required for post body
{code}
curl http://localhost:8983/solr/update --data-binary @books.json
{code}
returns 400 'missing content stream'
We could try to auto detect the content type, but that is unrelated to this
issue. To support this, we would want a different approach in
SolrRequestParsers. see line 394 in SolrRequestParsers
Yonik do you want to open a new issue for trying to auto-detect content-type?
UpdateRequestHandler should support XML,CSV,JSON, and javabin
-
Key: SOLR-3387
URL: https://issues.apache.org/jira/browse/SOLR-3387
Project: Solr
Issue Type: Improvement
Reporter: Ryan McKinley
Fix For: 4.0
Rather then have 4 handlers to support 4 content types, we should use a
single endpoint and pick the ContentStreamLoader based on the ContentType
This will simplify configuration problems for clients that want to swtich
format (see SOLR-3038)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3371) Admin UI breaks with a core named 'logging' or 'threads'
[ https://issues.apache.org/jira/browse/SOLR-3371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257571#comment-13257571 ] Ryan McKinley commented on SOLR-3371: - got it. +1 when you are ready I'm also +1 to commit SOLR-3174 as a work in progress BTW -- as long as it does not break anything obvious and moves things forward. Getting feedback and iterating is much easier on /trunk then having people apply patches etc. Admin UI breaks with a core named 'logging' or 'threads' Key: SOLR-3371 URL: https://issues.apache.org/jira/browse/SOLR-3371 Project: Solr Issue Type: Bug Components: web gui Reporter: Ryan McKinley Assignee: Stefan Matheis (steffkes) Fix For: 4.0 Attachments: SOLR-3371.patch If you make a core with the name logging or threads the UI gets confused with the logging or threads page. It seems like the ~threads and ~logging should be enough to distinguish -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3364) Logging UI allows multiple selections staying open
[ https://issues.apache.org/jira/browse/SOLR-3364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256266#comment-13256266 ] Ryan McKinley commented on SOLR-3364: - +1 looks good Logging UI allows multiple selections staying open -- Key: SOLR-3364 URL: https://issues.apache.org/jira/browse/SOLR-3364 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.0 Reporter: Stefan Matheis (steffkes) Assignee: Stefan Matheis (steffkes) Fix For: 4.0 Attachments: SOLR-3364.patch, multiple.png [Jan pointed out|https://issues.apache.org/jira/browse/SOLR-3327?focusedCommentId=13252884page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13252884], that the Logging UI currently allows multiple open selections. Opening a new selection should close all others. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3330) Show changes in plugin statistics across multiple requests
[ https://issues.apache.org/jira/browse/SOLR-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256269#comment-13256269 ] Ryan McKinley commented on SOLR-3330: - bq. fetching the 'reference xml' is now done right after loading the initial page. eeep. I would expect the changes to be based on when I click the button. I think the way to solve our issue is for the diff request to return the things that did not change as well. I'll make a patch for that and see if we can make that work Show changes in plugin statistics across multiple requests -- Key: SOLR-3330 URL: https://issues.apache.org/jira/browse/SOLR-3330 Project: Solr Issue Type: New Feature Components: web gui Reporter: Ryan McKinley Fix For: 4.0 Attachments: SOLR-3330-pluggins-diff.patch, SOLR-3330-pluggins-diff.patch, SOLR-3330-plugins.png, SOLR-3330-record-changes-ui.patch, SOLR-3330-record-changes-ui.patch, SOLR-3330-ui-update.patch, SOLR-3330.patch When debugging configuration and performance, I often: 1. Look at stats values 2. run some queries 3. See how the stats values changed This is fine, but is often a bit clunky and you have to really know what you are looking for to see any changes. It would be great if the 'plugins' page had a button that would make this easier -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3373) Unknown Characters in MBeanHandler-Output while using diff-feature
[
https://issues.apache.org/jira/browse/SOLR-3373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256276#comment-13256276
]
Ryan McKinley commented on SOLR-3373:
-
check r1327410
If that fixes things, can you resolve the issue?
Unknown Characters in MBeanHandler-Output while using diff-feature
--
Key: SOLR-3373
URL: https://issues.apache.org/jira/browse/SOLR-3373
Project: Solr
Issue Type: Bug
Components: web gui
Affects Versions: 4.0
Reporter: Stefan Matheis (steffkes)
Assignee: Ryan McKinley
Fix For: 4.0
i've been watching for changes, in the meantime i requested {{/admin/ping}}
for the first time after starting the instance.
The {{stream.body}}-Property of the {{POST}}-Request to {{/admin/mbeans}}
contains this for the ping-handler:
{code}lst name=org.apache.solr.handler.PingRequestHandler
str name=classorg.apache.solr.handler.PingRequestHandler/str
str name=version4.0.0.2012.04.16.10.12.28/str
str name=descriptionReports application health to a
load-balancer/str
str name=src$URL:
https://svn.apache.org/repos/asf/lucene/dev/trunk/solr/core/src/java/org/apache/solr/handler/PingRequestHandler.java
$/str
lst name=stats
long name=handlerStart1334564025566/long
long name=requests0/long
long name=errors0/long
long name=timeouts0/long
long name=totalTime0/long
float name=avgTimePerRequestNaN/float
float name=avgRequestsPerSecond0.0/float
/lst
/lst{code}
The diff-output contains the following:
{code}/admin/ping:{
class:org.apache.solr.handler.PingRequestHandler,
version:4.0.0.2012.04.16.10.12.28,
description:Reports application health to a load-balancer,
src:$URL:
https://svn.apache.org/repos/asf/lucene/dev/trunk/solr/core/src/java/org/apache/solr/handler/PingRequestHandler.java
$,
stats:{
handlerStart:1334564025566,
requests:Was: 0, Now: 1, Delta: 1,
errors:0,
timeouts:0,
totalTime:Was: 0, Now: 207, Delta: 207,
avgTimePerRequest:Was: NaN, Now: 207.0, Delta: �
}
}{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3358) Capture Logging Events from JUL and Log4j
[ https://issues.apache.org/jira/browse/SOLR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256694#comment-13256694 ] Ryan McKinley commented on SOLR-3358: - thanks steven I'm looking at the pom issue now. Ideally the -over-* will be optional dependencies in solrj, excluded from solr-core and included in the .war (this lets the end user decide what logging framework they actually use) For the ant build path, any suggestions? we can exclude it from core, and then add it back to the .war file. I'm not sure how to get the ivy stuff setup to have .war dependencies though. Capture Logging Events from JUL and Log4j - Key: SOLR-3358 URL: https://issues.apache.org/jira/browse/SOLR-3358 Project: Solr Issue Type: New Feature Reporter: Ryan McKinley Assignee: Ryan McKinley Attachments: SOLR-3358-logging.patch, SOLR-3358-logging.patch The UI should be able to show the last few log messages. To support this, we will need to register an Appender (log4j) or Handler (JUL) and keep a buffer of recent log events. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3358) Capture Logging Events from JUL and Log4j
[ https://issues.apache.org/jira/browse/SOLR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256723#comment-13256723 ] Ryan McKinley commented on SOLR-3358: - bq. so I don't understand why the log4j jar is being added! Why is this necessary? The log4j-over-slf4j.jar only wraps the calls to write events, it does not wrap anything for handling events (Appender and LoggingEvent). Ideally log4j would only be in the classpath for: https://svn.apache.org/repos/asf/lucene/dev/trunk/solr/core/src/java/org/apache/solr/logging/log4j/ The point of this is to capture events if the end user binds JUL or Log4j. Alternatively I could put the log4j implementation elsewhere, but that seems kinda silly since lots of people actually use log4j Capture Logging Events from JUL and Log4j - Key: SOLR-3358 URL: https://issues.apache.org/jira/browse/SOLR-3358 Project: Solr Issue Type: New Feature Reporter: Ryan McKinley Assignee: Ryan McKinley Attachments: SOLR-3358-compile-path.patch, SOLR-3358-logging.patch, SOLR-3358-logging.patch The UI should be able to show the last few log messages. To support this, we will need to register an Appender (log4j) or Handler (JUL) and keep a buffer of recent log events. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3358) Capture Logging Events from JUL and Log4j
[ https://issues.apache.org/jira/browse/SOLR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256762#comment-13256762 ] Ryan McKinley commented on SOLR-3358: - bq. *I would like that we revert this commit and discuss the logging again!* I'll pull out the log4j implementation, but leave in the JUL one -- is that OK for now? or take out the whole thing? Capture Logging Events from JUL and Log4j - Key: SOLR-3358 URL: https://issues.apache.org/jira/browse/SOLR-3358 Project: Solr Issue Type: New Feature Reporter: Ryan McKinley Assignee: Ryan McKinley Attachments: SOLR-3358-compile-path.patch, SOLR-3358-logging.patch, SOLR-3358-logging.patch The UI should be able to show the last few log messages. To support this, we will need to register an Appender (log4j) or Handler (JUL) and keep a buffer of recent log events. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3358) Capture Logging Events from JUL and Log4j
[ https://issues.apache.org/jira/browse/SOLR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256796#comment-13256796 ] Ryan McKinley commented on SOLR-3358: - log4j implementation pulled out in r1327608 Let me know if you want me to pull out the whole thing... bq. This will be a pain for all WAR users Note the .war does not include log4j.jar The aim is to provide a log4j implementation that can be used *if* the end user implements logging with log4j. Again, I am happy to put this elsewhere, but given that log4j is pretty common it would be nice to make it work out-of-the-box The first question is if we want to support log4j out of the box. If so, I think the right approach is to add a new lib folder to webapp and put all the slf4j-over .jar files in there Capture Logging Events from JUL and Log4j - Key: SOLR-3358 URL: https://issues.apache.org/jira/browse/SOLR-3358 Project: Solr Issue Type: New Feature Reporter: Ryan McKinley Assignee: Ryan McKinley Attachments: SOLR-3358-compile-path.patch, SOLR-3358-logging.patch, SOLR-3358-logging.patch The UI should be able to show the last few log messages. To support this, we will need to register an Appender (log4j) or Handler (JUL) and keep a buffer of recent log events. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3358) Capture Logging Events from JUL and Log4j
[ https://issues.apache.org/jira/browse/SOLR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256860#comment-13256860 ] Ryan McKinley commented on SOLR-3358: - yes, solr classpath is a disaster! I agree with everything you say/suggest, i figured this was the tradeoff for avoiding maven The other thing to consider is a test classpath -- the only class that uses jetty in the src tree is JettySolrRunner. I think that could be moved to test. re SpellChecker in solrj. The maven build should fail if you do this since it does use different classpaths for each module. (not a real solution, but just pointing it out) As a first step, I think we should remove the single solr/lib folder and replace it with: solrj/lib core/lib core/lib-test (includes jetty) webapp/lib (has the slf4j-over stuff) Capture Logging Events from JUL and Log4j - Key: SOLR-3358 URL: https://issues.apache.org/jira/browse/SOLR-3358 Project: Solr Issue Type: New Feature Reporter: Ryan McKinley Assignee: Ryan McKinley Attachments: SOLR-3358-compile-path.patch, SOLR-3358-logging.patch, SOLR-3358-logging.patch The UI should be able to show the last few log messages. To support this, we will need to register an Appender (log4j) or Handler (JUL) and keep a buffer of recent log events. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3358) Capture Logging Events from JUL and Log4j
[ https://issues.apache.org/jira/browse/SOLR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256863#comment-13256863 ] Ryan McKinley commented on SOLR-3358: - bq. For compiling Solr-webapp, this API is enough and we must test and compile against and only against servlet-api-2.4 FWIW, the maven build uses 2.4 so we would get a jenkins failure if we use something 3.0 specific if we had different lib/classpath for core/lib-test and example/lib we could use jetty-7 in core/lib-test and jetty-8 in example/lib -- this would let us test both jetty 7 and 8 Capture Logging Events from JUL and Log4j - Key: SOLR-3358 URL: https://issues.apache.org/jira/browse/SOLR-3358 Project: Solr Issue Type: New Feature Reporter: Ryan McKinley Assignee: Ryan McKinley Attachments: SOLR-3358-compile-path.patch, SOLR-3358-logging.patch, SOLR-3358-logging.patch The UI should be able to show the last few log messages. To support this, we will need to register an Appender (log4j) or Handler (JUL) and keep a buffer of recent log events. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3371) Admin UI breaks with a core named 'logging' or 'threads'
[
https://issues.apache.org/jira/browse/SOLR-3371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257059#comment-13257059
]
Ryan McKinley commented on SOLR-3371:
-
This works for everything except the cores page -- I tried following the
pattern and chaning:
{code}
===
--- web/js/scripts/cores.js (revision 1327715)
+++ web/js/scripts/cores.js (working copy)
@@ -104,7 +104,7 @@
// #/~cores
sammy.get
(
- /^#\/~(cores)$/,
+ /^#\/(~cores)$/,
function( context )
{
delete app.cores_template;
{code}
but that fails when I click on it. (i links to /#/~cores/core0)
Admin UI breaks with a core named 'logging' or 'threads'
Key: SOLR-3371
URL: https://issues.apache.org/jira/browse/SOLR-3371
Project: Solr
Issue Type: Bug
Components: web gui
Reporter: Ryan McKinley
Assignee: Stefan Matheis (steffkes)
Fix For: 4.0
Attachments: SOLR-3371.patch
If you make a core with the name logging or threads the UI gets confused
with the logging or threads page.
It seems like the ~threads and ~logging should be enough to distinguish
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3330) Show changes in plugin statistics across multiple requests
[ https://issues.apache.org/jira/browse/SOLR-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257155#comment-13257155 ] Ryan McKinley commented on SOLR-3330: - In r1327775 I added an option to get back all the ref elements as well. Add all=true as a param, and you will get everything back. It now appends a field to the changed items: _changed_: true The thought is you can update everything, but only highlight the elements that have _changed_ stefan, go ahead and commit the style changes to make the highlight more prominent Show changes in plugin statistics across multiple requests -- Key: SOLR-3330 URL: https://issues.apache.org/jira/browse/SOLR-3330 Project: Solr Issue Type: New Feature Components: web gui Reporter: Ryan McKinley Fix For: 4.0 Attachments: SOLR-3330-pluggins-diff.patch, SOLR-3330-pluggins-diff.patch, SOLR-3330-plugins.png, SOLR-3330-record-changes-ui.patch, SOLR-3330-record-changes-ui.patch, SOLR-3330-ui-update.patch, SOLR-3330.patch When debugging configuration and performance, I often: 1. Look at stats values 2. run some queries 3. See how the stats values changed This is fine, but is often a bit clunky and you have to really know what you are looking for to see any changes. It would be great if the 'plugins' page had a button that would make this easier -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3324) Put field name/type in the analysis URL
[ https://issues.apache.org/jira/browse/SOLR-3324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13254825#comment-13254825 ] Ryan McKinley commented on SOLR-3324: - Stefan -- looks great. added in r1326690 For the verbose field -- i don't think it needs to trigger a reload when you click it. But it would be nice to have it in the URL after you click the button. Put field name/type in the analysis URL Key: SOLR-3324 URL: https://issues.apache.org/jira/browse/SOLR-3324 Project: Solr Issue Type: Improvement Components: web gui Reporter: Ryan McKinley Fix For: 4.0 Attachments: SOLR-3324.patch, SOLR-3324.patch It would be nice to be able to link directly to a page that loads the right field in the analysis UI. This will also let us link the query-browser page to the analysis page -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3358) Show Logging Events in Admin UI
[ https://issues.apache.org/jira/browse/SOLR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13254390#comment-13254390 ] Ryan McKinley commented on SOLR-3358: - After thinking a bit more on this, I think we can (optionally) take it another step forward. The log appender/handler could actually send the event to a solr index. Then we could support more complex search/filtering directly with solr. As a first step, I'll replace my custom format with a SolrDocumentList so that anything we do for the in-memory solution could be reused for an index based solution. In a cloud/distributed environment, if all the instances log to the same server it would be much easier to spot problems across the whole system. I'll work up a patch bq. Right now, i was not able to produce one entry which contains a trace-element try: http://localhost:8983/solr/admin/logging?since=0test=true this will add a message (and exception) at each level Show Logging Events in Admin UI --- Key: SOLR-3358 URL: https://issues.apache.org/jira/browse/SOLR-3358 Project: Solr Issue Type: Bug Components: web gui Reporter: Ryan McKinley Assignee: Ryan McKinley Attachments: SOLR-3358-logging.patch The UI should be able to show the last few log messages. To support this, we will need to register an Appender (log4j) or Handler (JUL) and keep a buffer of recent log events. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3357) Add Generics to ResourceLoader.newInstance
[ https://issues.apache.org/jira/browse/SOLR-3357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13253505#comment-13253505 ] Ryan McKinley commented on SOLR-3357: - +1 Add Generics to ResourceLoader.newInstance -- Key: SOLR-3357 URL: https://issues.apache.org/jira/browse/SOLR-3357 Project: Solr Issue Type: Improvement Reporter: Chris Male Attachments: SOLR-3357.patch Came out of LUCENE-2510. We can add generics to ResourceLoader.newInstance so it returns T instead of Object. This will add improved type safety and remove the need for casting the result to a specific type. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3356) Logging UI (and LogLevelHandler) should support Log4j
[
https://issues.apache.org/jira/browse/SOLR-3356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13253508#comment-13253508
]
Ryan McKinley commented on SOLR-3356:
-
Added in r1325828
This uses {{StaticLoggerBinder.getSingleton().getLoggerFactoryClassStr()}} to
detect the logging framework, and will do the right thing for JUL or Log4j
otherwise it will return an error
Logging UI (and LogLevelHandler) should support Log4j
-
Key: SOLR-3356
URL: https://issues.apache.org/jira/browse/SOLR-3356
Project: Solr
Issue Type: Improvement
Reporter: Ryan McKinley
Assignee: Ryan McKinley
Priority: Minor
Fix For: 4.0
Attachments: SOLR-3356-log4j.patch
The Logging UI and LogLevelHandler can work using Log4j rather then just JUL
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3327) Logging UI should indicate which loggers are set vs implicit
[ https://issues.apache.org/jira/browse/SOLR-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13253512#comment-13253512 ] Ryan McKinley commented on SOLR-3327: - bq. Is there any way to give users the slf4j level options Not easily; SLF4j only helps to set the level -- it has no way to ask what the current level is, this is done with the relevant framework. Logging UI should indicate which loggers are set vs implicit Key: SOLR-3327 URL: https://issues.apache.org/jira/browse/SOLR-3327 Project: Solr Issue Type: Improvement Components: web gui Reporter: Ryan McKinley Priority: Trivial Fix For: 4.0 Attachments: SOLR-3327.patch, logging.png The new logging UI looks great! http://localhost:8983/solr/#/~logging It would be nice to indicate which ones are set explicitly vs implicit -- perhaps making the line bold when set=true -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3330) Show changes in plugin statistics across multiple requests
[ https://issues.apache.org/jira/browse/SOLR-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13253724#comment-13253724 ] Ryan McKinley commented on SOLR-3330: - It is already using POST with stream.body as a application/x-www-form-urlencoded param Are you seeing the long URL in the logs, or in your browser? Show changes in plugin statistics across multiple requests -- Key: SOLR-3330 URL: https://issues.apache.org/jira/browse/SOLR-3330 Project: Solr Issue Type: New Feature Components: web gui Reporter: Ryan McKinley Fix For: 4.0 Attachments: SOLR-3330-pluggins-diff.patch, SOLR-3330-pluggins-diff.patch, SOLR-3330-plugins.png, SOLR-3330-record-changes-ui.patch, SOLR-3330-record-changes-ui.patch When debugging configuration and performance, I often: 1. Look at stats values 2. run some queries 3. See how the stats values changed This is fine, but is often a bit clunky and you have to really know what you are looking for to see any changes. It would be great if the 'plugins' page had a button that would make this easier -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3324) Put field name/type in the analysis URL
[ https://issues.apache.org/jira/browse/SOLR-3324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13252635#comment-13252635 ] Ryan McKinley commented on SOLR-3324: - This looks good -- can the URL update when you click Analyse Values so that it is easy to know the bookmarkable URL? Can verbose also be in the URL? Looking at this a bit more, how does 'type_or_name' work? I have field names that are the same as the type name -- typically they use the same type, so it does not really matter... but it seems better to avoid that assumption. Perhaps the param could look like: f=type.pint or f=name.id Put field name/type in the analysis URL Key: SOLR-3324 URL: https://issues.apache.org/jira/browse/SOLR-3324 Project: Solr Issue Type: Improvement Components: web gui Reporter: Ryan McKinley Fix For: 4.0 Attachments: SOLR-3324.patch It would be nice to be able to link directly to a page that loads the right field in the analysis UI. This will also let us link the query-browser page to the analysis page -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3330) Show changes in plugin statistics across multiple requests
[ https://issues.apache.org/jira/browse/SOLR-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13251698#comment-13251698 ] Ryan McKinley commented on SOLR-3330: - sweet! Thanks Stefan. I commited this in r1324839 I think it makes sense to only show the changed elements. The values in the non-changed elements reflect the values when you first visited the page, not when you click Watch Changes I see two ways to resolve this: a. remove them from the UI b. change the diff handler so it returns all the values, not just the changed ones. It would add a marker for things that have changed I think it makes sense to add in a 'reload' button that will refresh all the stats Show changes in plugin statistics across multiple requests -- Key: SOLR-3330 URL: https://issues.apache.org/jira/browse/SOLR-3330 Project: Solr Issue Type: New Feature Components: web gui Reporter: Ryan McKinley Fix For: 4.0 Attachments: SOLR-3330-pluggins-diff.patch, SOLR-3330-pluggins-diff.patch, SOLR-3330-record-changes-ui.patch, SOLR-3330-record-changes-ui.patch When debugging configuration and performance, I often: 1. Look at stats values 2. run some queries 3. See how the stats values changed This is fine, but is often a bit clunky and you have to really know what you are looking for to see any changes. It would be great if the 'plugins' page had a button that would make this easier -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3330) Show changes in plugin statistics across multiple requests
[ https://issues.apache.org/jira/browse/SOLR-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13251738#comment-13251738 ] Ryan McKinley commented on SOLR-3330: - bq. but (b) is what we already have? No, right now it *only* returns the changed items. There are three points in time: 1. When the page first loads 2. When you click 'Watch Changes' 3. When you click 'Show Changes' Right now the UI shows the values from 1, then updates the changes between 23 -- the problem is that the values that may have changed between 12 are not reflected in the UI. (Not a huge deal, but not accurate) I think the highlight you already added looks good -- the New icon is a bit misleading because it implies that it is a new value (not just a changed one) Show changes in plugin statistics across multiple requests -- Key: SOLR-3330 URL: https://issues.apache.org/jira/browse/SOLR-3330 Project: Solr Issue Type: New Feature Components: web gui Reporter: Ryan McKinley Fix For: 4.0 Attachments: SOLR-3330-pluggins-diff.patch, SOLR-3330-pluggins-diff.patch, SOLR-3330-plugins.png, SOLR-3330-record-changes-ui.patch, SOLR-3330-record-changes-ui.patch When debugging configuration and performance, I often: 1. Look at stats values 2. run some queries 3. See how the stats values changed This is fine, but is often a bit clunky and you have to really know what you are looking for to see any changes. It would be great if the 'plugins' page had a button that would make this easier -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3330) Show changes in plugin statistics across multiple requests
[ https://issues.apache.org/jira/browse/SOLR-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13249897#comment-13249897 ] Ryan McKinley commented on SOLR-3330: - Changed NamedList to SimpleOrderedMap in revision 1311292 It should now look the same in JSON Show changes in plugin statistics across multiple requests -- Key: SOLR-3330 URL: https://issues.apache.org/jira/browse/SOLR-3330 Project: Solr Issue Type: New Feature Components: web gui Reporter: Ryan McKinley Fix For: 4.0 Attachments: SOLR-3330-pluggins-diff.patch, SOLR-3330-pluggins-diff.patch, SOLR-3330-record-changes-ui.patch When debugging configuration and performance, I often: 1. Look at stats values 2. run some queries 3. See how the stats values changed This is fine, but is often a bit clunky and you have to really know what you are looking for to see any changes. It would be great if the 'plugins' page had a button that would make this easier -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3340) MBeansHandlerTest fail (reproducable)
[ https://issues.apache.org/jira/browse/SOLR-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13249671#comment-13249671 ] Ryan McKinley commented on SOLR-3340: - thanks robert MBeansHandlerTest fail (reproducable) - Key: SOLR-3340 URL: https://issues.apache.org/jira/browse/SOLR-3340 Project: Solr Issue Type: Bug Reporter: Robert Muir Fix For: 4.0 ant test -Dtestcase=MBeansHandlerTest -Dtestmethod=testDiff -Dtests.seed=27d371738f445cbb:2b2027ac0f5fd0bf:-32d4ecfbc56c868c -Dargs=-Dfile.encoding=UTF-8 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3923) fail the build on wrong svn:eol-style
[ https://issues.apache.org/jira/browse/LUCENE-3923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13248176#comment-13248176 ] Ryan McKinley commented on LUCENE-3923: --- All the $Id$ and $Revision$ tags have been removed (SOLR-3329) fail the build on wrong svn:eol-style - Key: LUCENE-3923 URL: https://issues.apache.org/jira/browse/LUCENE-3923 Project: Lucene - Java Issue Type: Task Components: general/build Reporter: Robert Muir I'm tired of fixing this before releases. Jenkins should detect and fail on this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3923) fail the build on wrong svn:eol-style
[
https://issues.apache.org/jira/browse/LUCENE-3923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13247812#comment-13247812
]
Ryan McKinley commented on LUCENE-3923:
---
Perhaps we should also fail if a .java file does not have keywords set.
Lots of javadocs use
@version $Id$
{code}
svn propset svn:keywords Date Author Id Revision HeadURL *.java
{code}
In solr, MBeans expose $URL$, but we often don't set it
fail the build on wrong svn:eol-style
-
Key: LUCENE-3923
URL: https://issues.apache.org/jira/browse/LUCENE-3923
Project: Lucene - Java
Issue Type: Task
Components: general/build
Reporter: Robert Muir
I'm tired of fixing this before releases. Jenkins should detect and fail on
this.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3329) Use consistent svn:keywords
[
https://issues.apache.org/jira/browse/SOLR-3329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13247921#comment-13247921
]
Ryan McKinley commented on SOLR-3329:
-
In general, we need to decide what to do for SolrInfoMBean -- the current
typical implemention is:
{code}
@Override
public String getVersion() {
return $Revision: 1306018 $;
}
@Override
public String getSourceId() {
return $Id: RealTimeGetComponent.java 1306018 2012-03-27 20:58:34Z yonik
$;
}
@Override
public String getSource() {
return $URL:
https://svn.apache.org/repos/asf/lucene/dev/trunk/solr/core/src/java/org/apache/solr/handler/component/RealTimeGetComponent.java
$;
}
{code}
but we often forget to set the svn:keyword property when adding new MBeans...
Use consistent svn:keywords
---
Key: SOLR-3329
URL: https://issues.apache.org/jira/browse/SOLR-3329
Project: Solr
Issue Type: Improvement
Reporter: Ryan McKinley
Fix For: 4.0
In solr, use use svn:keywords haphazardly
We have lots of places with:
{code}
svn propset svn:keywords Date Author Id Revision HeadURL *.java
{code}
In LUCENE-3923, there is a suggestion to get rid of many of these.
The MBeans interface often exposes HeadURL, but we likely want to get rid of
the rest
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3311) System Admin UI not loading memory graph
[
https://issues.apache.org/jira/browse/SOLR-3311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13246117#comment-13246117
]
Ryan McKinley commented on SOLR-3311:
-
system?wt=json looks like it loads OK (from firebug)
{code:javascript}
{
responseHeader:{
status:0,
QTime:1},
core:{
schema:example,
host:10.0.1.9,
now:2012-04-04T08:38:48.972Z,
start:2012-04-04T08:34:15.303Z,
directory:{
cwd:C:\\workspace\\apache\\trunk\\solr,
instance:C:\\workspace\\apache\\trunk\\solr\\example\\solr\\.,
data:C:\\workspace\\apache\\trunk\\solr\\example\\solr\\.\\data,
index:C:\\workspace\\apache\\trunk\\solr\\example\\solr\\data\\index}},
lucene:{
solr-spec-version:null,
solr-impl-version:null,
lucene-spec-version:null,
lucene-impl-version:null},
jvm:{
version:22.1-b02,
name:Java HotSpot(TM) 64-Bit Server VM,
processors:8,
memory:{
free:293.1 MB,
total:328.1 MB,
max:2.7 GB,
used:35 MB (%1.3),
raw:{
free:307349784,
total:344064000,
max:2861498368,
used:36714216,
used%:1.2830416543505083}},
jmx:{
bootclasspath:C:\\java\\jdk1.7.0_03\\jre\\lib\\resources.jar;C:\\java\\jdk1.7.0_03\\jre\\lib\\rt.jar;C:\\java\\jdk1.7.0_03\\jre\\lib\\sunrsasign.jar;C:\\java\\jdk1.7.0_03\\jre\\lib\\jsse.jar;C:\\java\\jdk1.7.0_03\\jre\\lib\\jce.jar;C:\\java\\jdk1.7.0_03\\jre\\lib\\charsets.jar;C:\\java\\jdk1.7.0_03\\jre\\classes,
[jira] [Commented] (SOLR-3311) System Admin UI not loading memory graph
[ https://issues.apache.org/jira/browse/SOLR-3311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13246122#comment-13246122 ] Ryan McKinley commented on SOLR-3311: - ah yes: system_data.system.uptime is undefined perhaps related, but for me the refresh arrow in the upper right does not do anything either System Admin UI not loading memory graph Key: SOLR-3311 URL: https://issues.apache.org/jira/browse/SOLR-3311 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.0 Environment: windows Reporter: Ryan McKinley Assignee: Stefan Matheis (steffkes) Priority: Minor Attachments: system.png The memory graphs on the system dashboard don't show memory useage anymore. !system.png! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3311) System Admin UI not loading memory graph
[
https://issues.apache.org/jira/browse/SOLR-3311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13246126#comment-13246126
]
Ryan McKinley commented on SOLR-3311:
-
with the patch I now see:
{code}
data[key] is null
.text( data[key].esc() );
{code}
index.js (line 258)
System Admin UI not loading memory graph
Key: SOLR-3311
URL: https://issues.apache.org/jira/browse/SOLR-3311
Project: Solr
Issue Type: Bug
Components: web gui
Affects Versions: 4.0
Environment: windows
Reporter: Ryan McKinley
Assignee: Stefan Matheis (steffkes)
Priority: Minor
Attachments: SOLR-3311.patch, system.png
The memory graphs on the system dashboard don't show memory useage anymore.
!system.png!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3311) System Admin UI not loading memory graph
[ https://issues.apache.org/jira/browse/SOLR-3311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13246445#comment-13246445 ] Ryan McKinley commented on SOLR-3311: - thanks! The spec-version does not show up if you aren't running from a .jar file (from eclipse or exploded .class files) I committed this in 1309485 System Admin UI not loading memory graph Key: SOLR-3311 URL: https://issues.apache.org/jira/browse/SOLR-3311 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.0 Environment: windows Reporter: Ryan McKinley Assignee: Stefan Matheis (steffkes) Priority: Minor Fix For: 4.0 Attachments: SOLR-3311.patch, SOLR-3311.patch, system.png The memory graphs on the system dashboard don't show memory useage anymore. !system.png! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3238) Sequel of Admin UI
[ https://issues.apache.org/jira/browse/SOLR-3238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13246938#comment-13246938 ] Ryan McKinley commented on SOLR-3238: - I'm not sure what issue to attach this to, so it may make sense to make a new issue. Here is general wishlist of things I think would help... * From the analysis page, can there be a link to the relevant field/fieldType in schema-browser? * From the schema-browser, can there be a link to the analysis page (with the right field selected?) Perhaps the text Index Analyzer and Query Analyzer could be links * In the schema-browser, when you click on a term, it loads in the query window, it should also execute the query! * Why does Autoload™ have a tm? * I assume Autoload is writing a cookie... can it also keep the number of terms? Perhaps also the checked state on analysis verbose output? * On the schema-browser page, the text Index Analyzer shows up on one line, but Query Analyzer gets broken into two lines. * When showing the number of matching Docs for a field, can the number be a link to a query? For example with the field id, the link can be to: q=id:[* TO *] * The plural names in schema-browser are inappropriate at times -- not a big deal, but if we replaced Fields/Types with Field:/Type: I think it works OK in both singular and plural cases * In the plugin page, there are lots of URLs that would be great if they were actually URLS. When we show a link to http://wiki.apache.org/solr/StandardRequestHandler; that should be a real URL Things are really looking great! Sequel of Admin UI -- Key: SOLR-3238 URL: https://issues.apache.org/jira/browse/SOLR-3238 Project: Solr Issue Type: Improvement Components: web gui Affects Versions: 4.0 Reporter: Stefan Matheis (steffkes) Assignee: Stefan Matheis (steffkes) Fix For: 4.0 Attachments: SOLR-3238.patch, SOLR-3238.patch, SOLR-3238.patch, solradminbug.png Catch-All Issue for all upcoming Bugs/Reports/Suggestions on the Admin UI -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3930) nuke jars from source tree and use ivy
[ https://issues.apache.org/jira/browse/LUCENE-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13242493#comment-13242493 ] Ryan McKinley commented on LUCENE-3930: --- bq. In my opinion this is ready to go into trunk. I'll wait a bit for any feedback though. +1 ant test worked on my first try (after ivy bootstrap) HUGE thanks for looking into this nuke jars from source tree and use ivy -- Key: LUCENE-3930 URL: https://issues.apache.org/jira/browse/LUCENE-3930 Project: Lucene - Java Issue Type: Task Components: general/build Reporter: Robert Muir Assignee: Robert Muir Priority: Blocker Fix For: 3.6 Attachments: LUCENE-3930-skip-sources-javadoc.patch, LUCENE-3930-solr-example.patch, LUCENE-3930-solr-example.patch, LUCENE-3930.patch, LUCENE-3930.patch, LUCENE-3930.patch, LUCENE-3930__ivy_bootstrap_target.patch, ant_-verbose_clean_test.out.txt, noggit-commons-csv.patch, patch-jetty-build.patch As mentioned on the ML thread: switch jars to ivy mechanism?. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2000) Use covariant clone() return types
[
https://issues.apache.org/jira/browse/LUCENE-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13241413#comment-13241413
]
Ryan McKinley commented on LUCENE-2000:
---
I just checked in a bunch of stuff... kept removing things until:
{code}
ant compile | grep redundant cast
{code}
was empty
Use covariant clone() return types
--
Key: LUCENE-2000
URL: https://issues.apache.org/jira/browse/LUCENE-2000
Project: Lucene - Java
Issue Type: Task
Components: core/other
Affects Versions: 3.0
Reporter: Uwe Schindler
Assignee: Ryan McKinley
Priority: Minor
Fix For: 4.0
Attachments: LUCENE-2000-clone_covariance.patch,
LUCENE-2000-clone_covariance.patch
*Paul Cowan wrote in LUCENE-1257:*
OK, thought I'd jump in and help out here with one of my Java 5 favourites.
Haven't seen anyone discuss this, and don't believe any of the patches
address this, so thought I'd throw a patch out there (against SVN HEAD @
revision 827821) which uses Java 5 covariant return types for (almost) all of
the Object#clone() implementations in core.
i.e. this:
public Object clone() {
changes to:
public SpanNotQuery clone() {
which lets us get rid of a whole bunch of now-unnecessary casts, so e.g.
if (clone == null) clone = (SpanNotQuery) this.clone();
becomes
if (clone == null) clone = this.clone();
Almost everything has been done and all downcasts removed, in core, with the
exception of
Some SpanQuery stuff, where it's assumed that it's safe to cast the clone()
of a SpanQuery to a SpanQuery - this can't be made covariant without
declaring abstract SpanQuery clone() in SpanQuery itself, which breaks
those SpanQuerys that don't declare their own clone()
Some IndexReaders, e.g. DirectoryReader - we can't be more specific than
changing .clone() to return IndexReader, because it returns the result of
IndexReader.clone(boolean). We could use covariant types for THAT, which
would work fine, but that didn't follow the pattern of the others so that
could be a later commit.
Two changes were also made in contrib/, where not making the changes would
have broken code by trying to widen IndexInput#clone() back out to returning
Object, which is not permitted. contrib/ was otherwise left untouched.
Let me know what you think, or if you have any other questions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3271) ShardHandlerFactory really could be an interface
[ https://issues.apache.org/jira/browse/SOLR-3271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13241603#comment-13241603 ] Ryan McKinley commented on SOLR-3271: - Is there a real advantage to have this as an interface? (i mean besides good design :) The problem with interfaces and a strong back-compatible policy. With an abstract class, we can at least add default behavior without breaking compatibility in the future. ShardHandlerFactory really could be an interface Key: SOLR-3271 URL: https://issues.apache.org/jira/browse/SOLR-3271 Project: Solr Issue Type: Improvement Affects Versions: 3.6, 4.0 Reporter: Greg Bowyer Priority: Minor Labels: distributed, shard Attachments: SOLR-3271.patch, SOLR-3271.patch While I was browsing the code and playing about with a silly idea I had that messes with the distributed search from the perspective of the ShardHandlerFactory I noticed that the code makes the ShardHandlerFactory a pure virtual class. I wonder if it could just be an interface instead ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3295) Binaries contain 1.6 classes
[
https://issues.apache.org/jira/browse/SOLR-3295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13241771#comment-13241771
]
Ryan McKinley commented on SOLR-3295:
-
Solr is at java 1.6 in 3.x right?
so I think we only need to worry about the stuff in lucene
Binaries contain 1.6 classes
Key: SOLR-3295
URL: https://issues.apache.org/jira/browse/SOLR-3295
Project: Solr
Issue Type: Bug
Reporter: Dawid Weiss
Priority: Minor
Fix For: 3.6
Attachments: output.log
I've ran this tool (does the job): http://code.google.com/p/versioncheck/ on
the checkout of branch_3x. To my surprise there is a JAR which contains Java
1.6 code:
{noformat}
Major.Minor Version : 50.0 JAVA compatibility : Java 1.6
platform: 45.3-50.0
Number of classes : 60
Classes are :
c:\Work\lucene-solr\.\solr\contrib\extraction\lib\netcdf-4.2-min.jar [:]
ucar/unidata/geoloc/Bearing.class
...
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-435) QParser must validate existance/absense of q parameter
[
https://issues.apache.org/jira/browse/SOLR-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238560#comment-13238560
]
Ryan McKinley commented on SOLR-435:
bq. if no query string is supplied, or if its blank or just whitespace, then
the default is to match all documents.
-0
When I opened this issue (4 years ago!) I was only worried that you get a NPE
from a missing 'q'
bq. don't think we should do it w/o also add q.alt support to the LuceneQParser
so people can override it.
+1
Match none seems like the most appropriate behavior unless you explicitly say
something else
QParser must validate existance/absense of q parameter
Key: SOLR-435
URL: https://issues.apache.org/jira/browse/SOLR-435
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 1.3
Reporter: Ryan McKinley
Assignee: Ryan McKinley
Fix For: 3.6, 4.0
Attachments: SOLR-435_q_defaults_to_all-docs.patch
Each QParser should check if q exists or not. For some it will be required
others not.
currently it throws a null pointer:
{code}
java.lang.NullPointerException
at org.apache.solr.common.util.StrUtils.splitSmart(StrUtils.java:36)
at
org.apache.solr.search.OldLuceneQParser.parse(LuceneQParserPlugin.java:104)
at org.apache.solr.search.QParser.getQuery(QParser.java:80)
at
org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:67)
at
org.apache.solr.handler.SearchHandler.handleRequestBody(SearchHandler.java:150)
...
{code}
see:
http://www.nabble.com/query-parsing-error-to14124285.html#a14140108
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2020) HttpComponentsSolrServer
[ https://issues.apache.org/jira/browse/SOLR-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13236740#comment-13236740 ] Ryan McKinley commented on SOLR-2020: - looks good HttpComponentsSolrServer Key: SOLR-2020 URL: https://issues.apache.org/jira/browse/SOLR-2020 Project: Solr Issue Type: New Feature Components: clients - java Affects Versions: 1.4.1 Environment: Any Reporter: Chantal Ackermann Priority: Minor Fix For: 4.0 Attachments: HttpComponentsSolrServer.java, HttpComponentsSolrServerTest.java, SOLR-2020-3x.patch, SOLR-2020-HttpSolrServer.patch, SOLR-2020.patch, SOLR-2020.patch, SOLR-2020.patch, SOLR-2020.patch Implementation of SolrServer that uses the Apache Http Components framework. Http Components (http://hc.apache.org/) is the successor of Commons HttpClient and thus HttpComponentsSolrServer would be a successor of CommonsHttpSolrServer, in the future. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3260) Improve exception handling / logging for ScriptTransformer.init()
[ https://issues.apache.org/jira/browse/SOLR-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234472#comment-13234472 ] Ryan McKinley commented on SOLR-3260: - bq. class javax.servlet.FilterRegistration's signer information does not match signer information of other classes in the same package I have seen this before when servlet-2.5 and servlet-api 3.0 are both in the classpath Improve exception handling / logging for ScriptTransformer.init() - Key: SOLR-3260 URL: https://issues.apache.org/jira/browse/SOLR-3260 Project: Solr Issue Type: Bug Components: contrib - DataImportHandler Affects Versions: 3.5, 4.0 Reporter: James Dyer Assignee: James Dyer Priority: Trivial Fix For: 3.6, 4.0 Attachments: SOLR-3260.patch This came up on the user-list. ScriptTransformer logs the same need a =1.6 jre message for several problems, making debugging difficult for users. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3074) SolrPluginUtils.docListToSolrDocumentList is broken, existing test is also broken
[ https://issues.apache.org/jira/browse/SOLR-3074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234814#comment-13234814 ] Ryan McKinley commented on SOLR-3074: - bq. remove these methods in trunk +1 I *think* this was used long ago before the javabin format took over serializing DocList SolrPluginUtils.docListToSolrDocumentList is broken, existing test is also broken - Key: SOLR-3074 URL: https://issues.apache.org/jira/browse/SOLR-3074 Project: Solr Issue Type: Bug Components: search Affects Versions: 3.5 Reporter: Ahmet Arslan Assignee: Hoss Man Priority: Minor Fix For: 3.6, 4.0 Attachments: SOLR-3074.patch, SOLR-3074.patch testDocListConversion() is not testing what it's suppossed to test. Because added test documents are not committed. http://search-lucene.com/m/uwh9l2SHH4e -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3263) Stop including more than one servlet-api jar version in the test classpath in the Maven build
[
https://issues.apache.org/jira/browse/SOLR-3263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13235045#comment-13235045
]
Ryan McKinley commented on SOLR-3263:
-
thanks Steven!
Stop including more than one servlet-api jar version in the test classpath in
the Maven build
-
Key: SOLR-3263
URL: https://issues.apache.org/jira/browse/SOLR-3263
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 4.0
Reporter: Steven Rowe
Assignee: Steven Rowe
Fix For: 4.0
Attachments: SOLR-3263.patch
[Today's nightly Jenkins Maven trunk
build|https://builds.apache.org/job/Lucene-Solr-Maven-trunk/431/testReport/]
has several test failures with the error message:
{noformat}
class javax.servlet.FilterRegistration's signer information does not match
signer information of other classes in the same package
{noformat}
On SOLR-3260, [Ryan McKinley
mentioned|https://issues.apache.org/jira/browse/SOLR-3260?focusedCommentId=13234472page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13234472]
that these errors can be caused by mixing servlet-api jar versions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3238) Sequel of Admin UI
[ https://issues.apache.org/jira/browse/SOLR-3238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232437#comment-13232437 ] Ryan McKinley commented on SOLR-3238: - +1 Stefan -- go ahead and commit! Sequel of Admin UI -- Key: SOLR-3238 URL: https://issues.apache.org/jira/browse/SOLR-3238 Project: Solr Issue Type: Improvement Components: web gui Affects Versions: 4.0 Reporter: Stefan Matheis (steffkes) Assignee: Stefan Matheis (steffkes) Fix For: 4.0 Attachments: SOLR-3238.patch, solradminbug.png Catch-All Issue for all upcoming Bugs/Reports/Suggestions on the Admin UI -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3251) dynamically add field to schema
[ https://issues.apache.org/jira/browse/SOLR-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13230381#comment-13230381 ] Ryan McKinley commented on SOLR-3251: - Does this imply that the schema would be writeable? The PUT/POST option is nicer dynamically add field to schema --- Key: SOLR-3251 URL: https://issues.apache.org/jira/browse/SOLR-3251 Project: Solr Issue Type: New Feature Reporter: Yonik Seeley Attachments: SOLR-3251.patch One related piece of functionality needed for SOLR-3250 is the ability to dynamically add a field to the schema. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3251) dynamically add field to schema
[ https://issues.apache.org/jira/browse/SOLR-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13230390#comment-13230390 ] Ryan McKinley commented on SOLR-3251: - What are the thoughts on error handling? are you only able to add fields that don't exist? If they exist in the schema but not in the index? What about if the index Analyzer is identical, but the query Analyzer has changed? dynamically add field to schema --- Key: SOLR-3251 URL: https://issues.apache.org/jira/browse/SOLR-3251 Project: Solr Issue Type: New Feature Reporter: Yonik Seeley Attachments: SOLR-3251.patch One related piece of functionality needed for SOLR-3250 is the ability to dynamically add a field to the schema. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3251) dynamically add field to schema
[ https://issues.apache.org/jira/browse/SOLR-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13230406#comment-13230406 ] Ryan McKinley commented on SOLR-3251: - bq. separate file alongside schema.xml This makes sense. As is, the ad-hoc naming conventions in schema make writing out the full schema pretty daunting. dynamically add field to schema --- Key: SOLR-3251 URL: https://issues.apache.org/jira/browse/SOLR-3251 Project: Solr Issue Type: New Feature Reporter: Yonik Seeley Attachments: SOLR-3251.patch One related piece of functionality needed for SOLR-3250 is the ability to dynamically add a field to the schema. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3795) Replace spatial contrib module with LSP's spatial-lucene module
[ https://issues.apache.org/jira/browse/LUCENE-3795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13230565#comment-13230565 ] Ryan McKinley commented on LUCENE-3795: --- did not mean to 'resolve' the Math.toRadians issue though -- I think we should change that back to multiplication... Math.* seems to be pretty clunky Replace spatial contrib module with LSP's spatial-lucene module --- Key: LUCENE-3795 URL: https://issues.apache.org/jira/browse/LUCENE-3795 Project: Lucene - Java Issue Type: New Feature Components: modules/spatial Reporter: David Smiley Assignee: David Smiley Fix For: 4.0 I propose that Lucene's spatial contrib module be replaced with the spatial-lucene module within Lucene Spatial Playground (LSP). LSP has been in development for approximately 1 year by David Smiley, Ryan McKinley, and Chris Male and we feel it is ready. LSP is here: http://code.google.com/p/lucene-spatial-playground/ and the spatial-lucene module is intuitively in svn/trunk/spatial-lucene/. I'll add more comments to prevent the issue description from being too long. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3795) Replace spatial contrib module with LSP's spatial-lucene module
[ https://issues.apache.org/jira/browse/LUCENE-3795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13230648#comment-13230648 ] Ryan McKinley commented on LUCENE-3795: --- bq. I did benchmark it after the fact (after you questioned it), and it was indeed the case that Math.toRadians was much slower than a simple multiply. Can I see the benchmark? The trivial things I am trying seems to end up equivalent Replace spatial contrib module with LSP's spatial-lucene module --- Key: LUCENE-3795 URL: https://issues.apache.org/jira/browse/LUCENE-3795 Project: Lucene - Java Issue Type: New Feature Components: modules/spatial Reporter: David Smiley Assignee: David Smiley Fix For: 4.0 I propose that Lucene's spatial contrib module be replaced with the spatial-lucene module within Lucene Spatial Playground (LSP). LSP has been in development for approximately 1 year by David Smiley, Ryan McKinley, and Chris Male and we feel it is ready. LSP is here: http://code.google.com/p/lucene-spatial-playground/ and the spatial-lucene module is intuitively in svn/trunk/spatial-lucene/. I'll add more comments to prevent the issue description from being too long. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3795) Replace spatial contrib module with LSP's spatial-lucene module
[ https://issues.apache.org/jira/browse/LUCENE-3795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13230736#comment-13230736 ] Ryan McKinley commented on LUCENE-3795: --- yup -- I get the same results as you. I've updated things to use this optimization at spatial4j Replace spatial contrib module with LSP's spatial-lucene module --- Key: LUCENE-3795 URL: https://issues.apache.org/jira/browse/LUCENE-3795 Project: Lucene - Java Issue Type: New Feature Components: modules/spatial Reporter: David Smiley Assignee: David Smiley Fix For: 4.0 I propose that Lucene's spatial contrib module be replaced with the spatial-lucene module within Lucene Spatial Playground (LSP). LSP has been in development for approximately 1 year by David Smiley, Ryan McKinley, and Chris Male and we feel it is ready. LSP is here: http://code.google.com/p/lucene-spatial-playground/ and the spatial-lucene module is intuitively in svn/trunk/spatial-lucene/. I'll add more comments to prevent the issue description from being too long. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3795) Replace spatial contrib module with LSP's spatial-lucene module
[ https://issues.apache.org/jira/browse/LUCENE-3795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13228791#comment-13228791 ] Ryan McKinley commented on LUCENE-3795: --- ok -- with the logging issue solved, i think we can move things forward Replace spatial contrib module with LSP's spatial-lucene module --- Key: LUCENE-3795 URL: https://issues.apache.org/jira/browse/LUCENE-3795 Project: Lucene - Java Issue Type: New Feature Components: modules/spatial Reporter: David Smiley Assignee: David Smiley Fix For: 4.0 I propose that Lucene's spatial contrib module be replaced with the spatial-lucene module within Lucene Spatial Playground (LSP). LSP has been in development for approximately 1 year by David Smiley, Ryan McKinley, and Chris Male and we feel it is ready. LSP is here: http://code.google.com/p/lucene-spatial-playground/ and the spatial-lucene module is intuitively in svn/trunk/spatial-lucene/. I'll add more comments to prevent the issue description from being too long. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3098) analysis gui hangs if no tokens are output
[ https://issues.apache.org/jira/browse/SOLR-3098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227850#comment-13227850 ] Ryan McKinley commented on SOLR-3098: - Stefan... feel free to commit this type of change without review. For big things, it is good to have some review, but for minor fixes like this, just dive in! analysis gui hangs if no tokens are output -- Key: SOLR-3098 URL: https://issues.apache.org/jira/browse/SOLR-3098 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.0 Reporter: Robert Muir Assignee: Stefan Matheis (steffkes) Labels: newdev Attachments: SOLR-3098.patch try entering the for text_en -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3795) Replace spatial contrib module with LSP's spatial-lucene module
[ https://issues.apache.org/jira/browse/LUCENE-3795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13228041#comment-13228041 ] Ryan McKinley commented on LUCENE-3795: --- I think this is ready for /trunk Unless there are objections, I will commit tomorrow -- and we can iterate from there Replace spatial contrib module with LSP's spatial-lucene module --- Key: LUCENE-3795 URL: https://issues.apache.org/jira/browse/LUCENE-3795 Project: Lucene - Java Issue Type: New Feature Components: modules/spatial Reporter: David Smiley Assignee: David Smiley Fix For: 4.0 I propose that Lucene's spatial contrib module be replaced with the spatial-lucene module within Lucene Spatial Playground (LSP). LSP has been in development for approximately 1 year by David Smiley, Ryan McKinley, and Chris Male and we feel it is ready. LSP is here: http://code.google.com/p/lucene-spatial-playground/ and the spatial-lucene module is intuitively in svn/trunk/spatial-lucene/. I'll add more comments to prevent the issue description from being too long. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3795) Replace spatial contrib module with LSP's spatial-lucene module
[ https://issues.apache.org/jira/browse/LUCENE-3795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13228075#comment-13228075 ] Ryan McKinley commented on LUCENE-3795: --- I think we can remove logging... i'll take a look Replace spatial contrib module with LSP's spatial-lucene module --- Key: LUCENE-3795 URL: https://issues.apache.org/jira/browse/LUCENE-3795 Project: Lucene - Java Issue Type: New Feature Components: modules/spatial Reporter: David Smiley Assignee: David Smiley Fix For: 4.0 I propose that Lucene's spatial contrib module be replaced with the spatial-lucene module within Lucene Spatial Playground (LSP). LSP has been in development for approximately 1 year by David Smiley, Ryan McKinley, and Chris Male and we feel it is ready. LSP is here: http://code.google.com/p/lucene-spatial-playground/ and the spatial-lucene module is intuitively in svn/trunk/spatial-lucene/. I'll add more comments to prevent the issue description from being too long. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3862) DocValues getInt() returns long, getFloat() returns double
[ https://issues.apache.org/jira/browse/LUCENE-3862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227251#comment-13227251 ] Ryan McKinley commented on LUCENE-3862: --- In looking at replacing FieldCache with DocValues, I came to this same question. I also wonder how/if there should be any relationship with the [FunctionValues.java|https://svn.apache.org/repos/asf/lucene/dev/trunk/modules/queries/src/java/org/apache/lucene/queries/function/FunctionValues.java] class. DocValues getInt() returns long, getFloat() returns double -- Key: LUCENE-3862 URL: https://issues.apache.org/jira/browse/LUCENE-3862 Project: Lucene - Java Issue Type: Improvement Affects Versions: 4.0 Reporter: Robert Muir I think this is a bit confusing: especially for the case of something like norms where its really an 8 bit byte, a long is confusing. i think we should have the usual getFloat/getDouble/getInt/getShort/getByte instead? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3231) Add the ability to KStemmer to preserve the original token when stemming
[ https://issues.apache.org/jira/browse/SOLR-3231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227257#comment-13227257 ] Ryan McKinley commented on SOLR-3231: - If I understand the patch, this patch just sets the tokenType attribute to STEM right? Add the ability to KStemmer to preserve the original token when stemming Key: SOLR-3231 URL: https://issues.apache.org/jira/browse/SOLR-3231 Project: Solr Issue Type: Improvement Components: Schema and Analysis Affects Versions: 4.0 Reporter: Jamie Johnson Attachments: KStemFilter.patch While using the PorterStemmer, I found that there were often times that it was far to aggressive in it's stemming. In my particular case it is unrealistic to provide a protected word list which captures all possible words which should not be stemmed. To avoid this I proposed a solution whereby we store the original token as well as the stemmed token so exact searches would always work. Based on discussions on the mailing list Ahmet Arslan, I believe the attached patch to KStemmer provides the desired capabilities through a configuration parameter. This largely is a copy of the org.apache.lucene.wordnet.SynonymTokenFilter. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3159) Upgrade to Jetty 8
[ https://issues.apache.org/jira/browse/SOLR-3159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13226978#comment-13226978 ] Ryan McKinley commented on SOLR-3159: - They had a real 8.1.2 release... and I upgraded the .jar files in revision: 1299325 Upgrade to Jetty 8 -- Key: SOLR-3159 URL: https://issues.apache.org/jira/browse/SOLR-3159 Project: Solr Issue Type: Task Reporter: Ryan McKinley Priority: Minor Fix For: 4.0 Attachments: SOLR-3159-maven.patch Solr is currently tested (and bundled) with a patched jetty-6 version. Ideally we can release and test with a standard version. Jetty-6 (at codehaus) is just maintenance now. New development and improvements are now hosted at eclipse. Assuming performance is equivalent, I think we should switch to Jetty 8. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3219) StreamingUpdateSolrServer is not quiet at INFO, but CommonsHttpSolrServer is
[ https://issues.apache.org/jira/browse/SOLR-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225720#comment-13225720 ] Ryan McKinley commented on SOLR-3219: - bq. A knob to make it configurable would be cool, but that's probably a fair amount of work. Any logging framework will let you decide if that component should show INFO or not. I think the rationale behind showing it for SUSS is that it is starting up a pool of connections that are expected to run for a long while. But I don't really care if it stays or changes. 'Bug' seems extreme to me StreamingUpdateSolrServer is not quiet at INFO, but CommonsHttpSolrServer is Key: SOLR-3219 URL: https://issues.apache.org/jira/browse/SOLR-3219 Project: Solr Issue Type: Bug Components: clients - java Affects Versions: 3.5, 4.0 Reporter: Shawn Heisey Priority: Minor When using CommonsHttpSolrServer, nothing gets logged by SolrJ at the INFO level. When using StreamingUpdateSolrServer, I have seen two messages logged each time it is used: Mar 08, 2012 4:41:01 PM org.apache.solr.client.solrj.impl.StreamingUpdateSolrServer$Runner run INFO: starting runner: org.apache.solr.client.solrj.impl.StreamingUpdateSolrServer$Runner@6bf28508 Mar 08, 2012 4:41:01 PM org.apache.solr.client.solrj.impl.StreamingUpdateSolrServer$Runner run INFO: finished: org.apache.solr.client.solrj.impl.StreamingUpdateSolrServer$Runner@6bf28508 I think one of these behaviors should be considered a bug. My preference is to move the logging in SUSS out of INFO so it is silent like CHSS. If the decision is to leave it at INFO, I'll just live with it. A knob to make it configurable would be cool, but that's probably a fair amount of work. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3204) solr-commons-csv must not use the org.apache.commons.csv package
[ https://issues.apache.org/jira/browse/SOLR-3204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13224645#comment-13224645 ] Ryan McKinley commented on SOLR-3204: - +1 thanks Uwe bq. I don't think jarjar'ing every dependency Solr The only jar files in question are snapshot/unreleased code. The commons-csv problem is a non issue if we were using a released version. solr-commons-csv must not use the org.apache.commons.csv package Key: SOLR-3204 URL: https://issues.apache.org/jira/browse/SOLR-3204 Project: Solr Issue Type: Bug Components: Build Affects Versions: 3.5 Reporter: Emmanuel Bourg Priority: Blocker Fix For: 3.6 Attachments: SOLR-3204.patch, SOLR-3204.patch, SOLR-3204.patch, apache-solr-commons-csv-1.0-SNAPSHOT-r966014.jar, rule.txt, rule.txt, solr-csv.patch The solr-commons-csv artifact reused the code from the Apache Commons CSV project but the package wasn't changed to something else than org.apache.commons.csv in the process. This creates a compatibility issue as the Apache Commons team works toward an official release of Commons CSV. It prevents Commons CSV from using its own org.apache.commons.csv package, or forces the renaming of all the classes to avoid a classpath conflict. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3204) solr-commons-csv must not use the org.apache.commons.csv package
[ https://issues.apache.org/jira/browse/SOLR-3204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13224690#comment-13224690 ] Ryan McKinley commented on SOLR-3204: - bq. Wait, are you talking about the Maven issue (my private deps become publicly released to Maven), or the more general JAR hell problem? I see this entirely as as JAR hell problem. Maven just makes it easier to discover. bq. For JAR hell, I thought even released versions can cause problems too? Of course - but this is an expected side-effect of a release. This whole discussion is because the commons-csv people never agreed to support the classnames solr is using. If they request we change the name, it seems only appropriate that we do. solr-commons-csv must not use the org.apache.commons.csv package Key: SOLR-3204 URL: https://issues.apache.org/jira/browse/SOLR-3204 Project: Solr Issue Type: Bug Components: Build Affects Versions: 3.5 Reporter: Emmanuel Bourg Priority: Blocker Fix For: 3.6 Attachments: SOLR-3204.patch, SOLR-3204.patch, SOLR-3204.patch, apache-solr-commons-csv-1.0-SNAPSHOT-r966014.jar, rule.txt, rule.txt, solr-csv.patch The solr-commons-csv artifact reused the code from the Apache Commons CSV project but the package wasn't changed to something else than org.apache.commons.csv in the process. This creates a compatibility issue as the Apache Commons team works toward an official release of Commons CSV. It prevents Commons CSV from using its own org.apache.commons.csv package, or forces the renaming of all the classes to avoid a classpath conflict. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3159) Upgrade to Jetty 8
[
https://issues.apache.org/jira/browse/SOLR-3159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13224703#comment-13224703
]
Ryan McKinley commented on SOLR-3159:
-
committed to trunk in #1298108
What are thoughts on porting to 3.x? I am -0 for a few reasons:
* 3.6 is hopefully soon -- I would like to see this test for a while
* JSP complications
** requires JDK (not just JRE)
** the start.jar would need to be run with:
{code}
java -jar start.jar -OPTIONS=jsp
{code}
- - - -
Shawn, to run this with any .war file you can put the .war file in webapps
The pile of config files in etc are for the various features you can enable --
this just includes the ones I think we need
Upgrade to Jetty 8
--
Key: SOLR-3159
URL: https://issues.apache.org/jira/browse/SOLR-3159
Project: Solr
Issue Type: Task
Reporter: Ryan McKinley
Priority: Minor
Fix For: 4.0
Solr is currently tested (and bundled) with a patched jetty-6 version.
Ideally we can release and test with a standard version.
Jetty-6 (at codehaus) is just maintenance now. New development and
improvements are now hosted at eclipse. Assuming performance is equivalent,
I think we should switch to Jetty 8.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3159) Upgrade to Jetty 8
[ https://issues.apache.org/jira/browse/SOLR-3159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13224721#comment-13224721 ] Ryan McKinley commented on SOLR-3159: - weird -- I'm guessing that page is out of date... but it is not confidence inspiring! Jetty 7/8 have been around since 2009. Work has even started on Jetty 9 Upgrade to Jetty 8 -- Key: SOLR-3159 URL: https://issues.apache.org/jira/browse/SOLR-3159 Project: Solr Issue Type: Task Reporter: Ryan McKinley Priority: Minor Fix For: 4.0 Solr is currently tested (and bundled) with a patched jetty-6 version. Ideally we can release and test with a standard version. Jetty-6 (at codehaus) is just maintenance now. New development and improvements are now hosted at eclipse. Assuming performance is equivalent, I think we should switch to Jetty 8. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3159) Upgrade to Jetty 8
[ https://issues.apache.org/jira/browse/SOLR-3159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13224747#comment-13224747 ] Ryan McKinley commented on SOLR-3159: - bq. is 8.x just stable enough? I'm confident the server is stable. I am not confident we have the most appropriate settings in solr/example/etc/jetty.xml These are the same settings we had for jetty 6, but I do not know if this is still the best choice. In particular, I'm not sure about the .bio.SocketConnector vs .nio.SelectChannelConnector Uwe: to backport, we can use the same setup (jetty 8) but need to add in the JSP jar files and change docs about starting the example. Unlike the commons-csv issue, I am not concerned about the patched dependency here because if someone wants to use a different jetty release they can do it and avoid the JAR hell problems. Upgrade to Jetty 8 -- Key: SOLR-3159 URL: https://issues.apache.org/jira/browse/SOLR-3159 Project: Solr Issue Type: Task Reporter: Ryan McKinley Priority: Minor Fix For: 4.0 Solr is currently tested (and bundled) with a patched jetty-6 version. Ideally we can release and test with a standard version. Jetty-6 (at codehaus) is just maintenance now. New development and improvements are now hosted at eclipse. Assuming performance is equivalent, I think we should switch to Jetty 8. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3204) solr-commons-csv must not use the org.apache.commons.csv package
[ https://issues.apache.org/jira/browse/SOLR-3204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13223399#comment-13223399 ] Ryan McKinley commented on SOLR-3204: - How close is commons-csv to a release? solr-commons-csv must not use the org.apache.commons.csv package Key: SOLR-3204 URL: https://issues.apache.org/jira/browse/SOLR-3204 Project: Solr Issue Type: Bug Components: Build Affects Versions: 3.5 Reporter: Emmanuel Bourg Priority: Blocker Fix For: 3.6 Attachments: solr-csv.patch The solr-commons-csv artifact reused the code from the Apache Commons CSV project but the package wasn't changed to something else than org.apache.commons.csv in the process. This creates a compatibility issue as the Apache Commons team works toward an official release of Commons CSV. It prevents Commons CSV from using its own org.apache.commons.csv package, or forces the renaming of all the classes to avoid a classpath conflict. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3204) solr-commons-csv must not use the org.apache.commons.csv package
[ https://issues.apache.org/jira/browse/SOLR-3204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13223437#comment-13223437 ] Ryan McKinley commented on SOLR-3204: - Since we don't *really* deploy with maven, can we just point the maven artifact to the snapshot build? solr-commons-csv must not use the org.apache.commons.csv package Key: SOLR-3204 URL: https://issues.apache.org/jira/browse/SOLR-3204 Project: Solr Issue Type: Bug Components: Build Affects Versions: 3.5 Reporter: Emmanuel Bourg Priority: Blocker Fix For: 3.6 Attachments: solr-csv.patch The solr-commons-csv artifact reused the code from the Apache Commons CSV project but the package wasn't changed to something else than org.apache.commons.csv in the process. This creates a compatibility issue as the Apache Commons team works toward an official release of Commons CSV. It prevents Commons CSV from using its own org.apache.commons.csv package, or forces the renaming of all the classes to avoid a classpath conflict. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3204) solr-commons-csv must not use the org.apache.commons.csv package
[ https://issues.apache.org/jira/browse/SOLR-3204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13223463#comment-13223463 ] Ryan McKinley commented on SOLR-3204: - bq. But you might reference org.apache.solr:solr-commons-csv:3.5.0 in Solr 3.6 +1 solr-commons-csv must not use the org.apache.commons.csv package Key: SOLR-3204 URL: https://issues.apache.org/jira/browse/SOLR-3204 Project: Solr Issue Type: Bug Components: Build Affects Versions: 3.5 Reporter: Emmanuel Bourg Priority: Blocker Fix For: 3.6 Attachments: solr-csv.patch The solr-commons-csv artifact reused the code from the Apache Commons CSV project but the package wasn't changed to something else than org.apache.commons.csv in the process. This creates a compatibility issue as the Apache Commons team works toward an official release of Commons CSV. It prevents Commons CSV from using its own org.apache.commons.csv package, or forces the renaming of all the classes to avoid a classpath conflict. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3162) Continue work on new admin UI
[ https://issues.apache.org/jira/browse/SOLR-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13223474#comment-13223474 ] Ryan McKinley commented on SOLR-3162: - Rather then make this issue huge... could we make new issues for the outstanding tasks? It is difficult to tell what is left to do. We can use the JIRA component web gui Continue work on new admin UI - Key: SOLR-3162 URL: https://issues.apache.org/jira/browse/SOLR-3162 Project: Solr Issue Type: Improvement Components: Schema and Analysis, web gui Affects Versions: 4.0 Reporter: Erick Erickson Assignee: Erick Erickson Attachments: SOLR-3162-index.png, SOLR-3162-schema-browser.png, SOLR-3162.patch, SOLR-3162.patch, SOLR-3162.patch, SOLR-3162.patch, SOLR-3162.patch There have been more improvements to how the new UI works, but the current open bugs are getting hard to keep straight. This is the new catch-all JIRA for continued improvements. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3205) Better error reporting from Analysis UI
[
https://issues.apache.org/jira/browse/SOLR-3205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13223708#comment-13223708
]
Ryan McKinley commented on SOLR-3205:
-
I just committed SOLR-141. The response should now include an 'error' section.
Better error reporting from Analysis UI
---
Key: SOLR-3205
URL: https://issues.apache.org/jira/browse/SOLR-3205
Project: Solr
Issue Type: Bug
Components: web gui
Reporter: Ryan McKinley
Fix For: 4.0
The new analysis UI does not behave well with invalid input. To reproduce,
from /#/singlecore/analysis
* Select a number field (int)
* put in invalid text (hello)
* click Analyse Values
The UI will have a red banner, but not say anything useful. The log file
will say:
{code}
SEVERE: org.apache.solr.common.SolrException: Invalid Number: hello
at
org.apache.solr.analysis.TrieTokenizer.reset(TrieTokenizerFactory.java:113)
at
org.apache.solr.analysis.TrieTokenizer.init(TrieTokenizerFactory.java:76)
{code}
Hopefully we can get the UI to say Invalid Number: hello
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3204) solr-commons-csv must not use the org.apache.commons.csv package
[ https://issues.apache.org/jira/browse/SOLR-3204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13223881#comment-13223881 ] Ryan McKinley commented on SOLR-3204: - The real problem (regardless of ant/maven) is for users that want to use o.a.c.csv classes that are *not* the ones in the solr distribution. This can happen when people have plugins using something based on a recent CSV build -- *something* will break, either their code, or the CSVResponseWriter This is not a maven issue, it is a question of who should put classes into the org.apache.commons.csv namespace. I understand why the csv folks are pissed, and think it is fair we look for ways to fix it. I am now +1 on Emmanuel's patch to embed o.a.solr.csv in the solr core jar file -- we should have notes that it won't be supported once a real csv is released. solr-commons-csv must not use the org.apache.commons.csv package Key: SOLR-3204 URL: https://issues.apache.org/jira/browse/SOLR-3204 Project: Solr Issue Type: Bug Components: Build Affects Versions: 3.5 Reporter: Emmanuel Bourg Priority: Blocker Fix For: 3.6 Attachments: SOLR-3204.patch, solr-csv.patch The solr-commons-csv artifact reused the code from the Apache Commons CSV project but the package wasn't changed to something else than org.apache.commons.csv in the process. This creates a compatibility issue as the Apache Commons team works toward an official release of Commons CSV. It prevents Commons CSV from using its own org.apache.commons.csv package, or forces the renaming of all the classes to avoid a classpath conflict. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3204) solr-commons-csv must not use the org.apache.commons.csv package
[ https://issues.apache.org/jira/browse/SOLR-3204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13223920#comment-13223920 ] Ryan McKinley commented on SOLR-3204: - Sorry, by 'put classes', i mean that when commons-csv-1.0-SNAPSHOT-r966014.jar is in the *runtime* classpath it uses classes in the namespace org.apache.commons.csv By using this namespace, it prevents people from using other dependencies with that same package name reliably. The commons-csv folks are understandably upset that that means their jar file does not work as expected within solr. Consider the case where someone deploys the solr.war file (built by ant) with a plugin that uses the current commons-csv.jar from /trunk. *something* will break -- either the CSVRequestHandler or their plugin depending on what is first in the classpath. (I think their plugin would always fail since it is loaded second) I think we have gotten lost in the maven discussion, when the real problem is about how our CSV.jar interacts with plugins (or anything else in the *runtime* classpath) solr-commons-csv must not use the org.apache.commons.csv package Key: SOLR-3204 URL: https://issues.apache.org/jira/browse/SOLR-3204 Project: Solr Issue Type: Bug Components: Build Affects Versions: 3.5 Reporter: Emmanuel Bourg Priority: Blocker Fix For: 3.6 Attachments: SOLR-3204.patch, solr-csv.patch The solr-commons-csv artifact reused the code from the Apache Commons CSV project but the package wasn't changed to something else than org.apache.commons.csv in the process. This creates a compatibility issue as the Apache Commons team works toward an official release of Commons CSV. It prevents Commons CSV from using its own org.apache.commons.csv package, or forces the renaming of all the classes to avoid a classpath conflict. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3204) solr-commons-csv must not use the org.apache.commons.csv package
[ https://issues.apache.org/jira/browse/SOLR-3204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13223984#comment-13223984 ] Ryan McKinley commented on SOLR-3204: - I'm not trying to spin anything -- I'm trying to figure out what the real issue is. Part of it is obviously the maven release. Emmanuel can you tell us more about how this came up? solr-commons-csv must not use the org.apache.commons.csv package Key: SOLR-3204 URL: https://issues.apache.org/jira/browse/SOLR-3204 Project: Solr Issue Type: Bug Components: Build Affects Versions: 3.5 Reporter: Emmanuel Bourg Priority: Blocker Fix For: 3.6 Attachments: SOLR-3204.patch, solr-csv.patch The solr-commons-csv artifact reused the code from the Apache Commons CSV project but the package wasn't changed to something else than org.apache.commons.csv in the process. This creates a compatibility issue as the Apache Commons team works toward an official release of Commons CSV. It prevents Commons CSV from using its own org.apache.commons.csv package, or forces the renaming of all the classes to avoid a classpath conflict. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3795) Replace spatial contrib module with LSP's spatial-lucene module
[ https://issues.apache.org/jira/browse/LUCENE-3795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222578#comment-13222578 ] Ryan McKinley commented on LUCENE-3795: --- bq. Wouldn't it be nice to roll all of these fundamental concepts in to a single project like SIS? I agree -- but the elephant in the room is the LGPL library JTS. From previous discussions, I believe this was a non-starter for their compile/test environment, but I have emailed the sis-dev@ list to see if this is still their feeling. With spatial4j, we want a solid ASL solution, but also support complex polygons if people choose to use JTS in their runtime environment. Replace spatial contrib module with LSP's spatial-lucene module --- Key: LUCENE-3795 URL: https://issues.apache.org/jira/browse/LUCENE-3795 Project: Lucene - Java Issue Type: New Feature Components: modules/spatial Reporter: David Smiley Assignee: David Smiley Fix For: 4.0 I propose that Lucene's spatial contrib module be replaced with the spatial-lucene module within Lucene Spatial Playground (LSP). LSP has been in development for approximately 1 year by David Smiley, Ryan McKinley, and Chris Male and we feel it is ready. LSP is here: http://code.google.com/p/lucene-spatial-playground/ and the spatial-lucene module is intuitively in svn/trunk/spatial-lucene/. I'll add more comments to prevent the issue description from being too long. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3795) Replace spatial contrib module with LSP's spatial-lucene module
[ https://issues.apache.org/jira/browse/LUCENE-3795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222729#comment-13222729 ] Ryan McKinley commented on LUCENE-3795: --- I have confirmed with SIS that a compile/test dependency on JTS in not possible. (One of their main goals is to make an ASL version of JTS... A great goal, but they are not yet to 1st base) So, where does that leave us? Is the spatial4j.jar a blocker for anyone? I understand it is not everyone's preferred option -- but no option makes everyone happy. Replace spatial contrib module with LSP's spatial-lucene module --- Key: LUCENE-3795 URL: https://issues.apache.org/jira/browse/LUCENE-3795 Project: Lucene - Java Issue Type: New Feature Components: modules/spatial Reporter: David Smiley Assignee: David Smiley Fix For: 4.0 I propose that Lucene's spatial contrib module be replaced with the spatial-lucene module within Lucene Spatial Playground (LSP). LSP has been in development for approximately 1 year by David Smiley, Ryan McKinley, and Chris Male and we feel it is ready. LSP is here: http://code.google.com/p/lucene-spatial-playground/ and the spatial-lucene module is intuitively in svn/trunk/spatial-lucene/. I'll add more comments to prevent the issue description from being too long. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3795) Replace spatial contrib module with LSP's spatial-lucene module
[ https://issues.apache.org/jira/browse/LUCENE-3795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222781#comment-13222781 ] Ryan McKinley commented on LUCENE-3795: --- bq. PMC to create any sort of dependency upon code that is more restrictive than the Apache License. Note, the spatial4j.jar file is ASL No user ever needs to touch LGPL code or artifacts Replace spatial contrib module with LSP's spatial-lucene module --- Key: LUCENE-3795 URL: https://issues.apache.org/jira/browse/LUCENE-3795 Project: Lucene - Java Issue Type: New Feature Components: modules/spatial Reporter: David Smiley Assignee: David Smiley Fix For: 4.0 I propose that Lucene's spatial contrib module be replaced with the spatial-lucene module within Lucene Spatial Playground (LSP). LSP has been in development for approximately 1 year by David Smiley, Ryan McKinley, and Chris Male and we feel it is ready. LSP is here: http://code.google.com/p/lucene-spatial-playground/ and the spatial-lucene module is intuitively in svn/trunk/spatial-lucene/. I'll add more comments to prevent the issue description from being too long. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3204) solr-commons-csv must not use the org.apache.commons.csv package
[ https://issues.apache.org/jira/browse/SOLR-3204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222911#comment-13222911 ] Ryan McKinley commented on SOLR-3204: - Solr is using a snapshot commons CSV build (commons-csv-1.0-SNAPSHOT-r966014) -- solr does not change anything and would prefer to use a release build. Has there been class refactorings that make replacing the .jar with the dev build impossible? If so, perhaps we should just update the .jar file we are including. solr-commons-csv must not use the org.apache.commons.csv package Key: SOLR-3204 URL: https://issues.apache.org/jira/browse/SOLR-3204 Project: Solr Issue Type: Bug Affects Versions: 3.5 Reporter: Emmanuel Bourg Priority: Blocker Fix For: 3.6 The solr-commons-csv artifact reused the code from the Apache Commons CSV project but the package wasn't changed to something else than org.apache.commons.csv in the process. This creates a compatibility issue as the Apache Commons team works toward an official release of Commons CSV. It prevents Commons CSV from using its own org.apache.commons.csv package, or forces the renaming of all the classes to avoid a classpath conflict. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3204) solr-commons-csv must not use the org.apache.commons.csv package
[
https://issues.apache.org/jira/browse/SOLR-3204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13222930#comment-13222930
]
Ryan McKinley commented on SOLR-3204:
-
Emmanuel, can you confirm this is just a maven issue?
Can it be solved with adding exclusions?
{code:xml}
dependency
groupIdorg.apache.solr/groupId
artifactIdsolr-core/artifactId
version${solr.version}/version
exclusions
exclusion
groupIdorg.apache.solr/groupId
artifactIdsolr-commons-csv/artifactId
/exclusion
...
{code}
Obviously the best approach is to work with an official release... but until
that exists, what do you suggest? (Actually forking the project and changing
the package names seems pretty bad)
solr-commons-csv must not use the org.apache.commons.csv package
Key: SOLR-3204
URL: https://issues.apache.org/jira/browse/SOLR-3204
Project: Solr
Issue Type: Bug
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
Fix For: 3.6
The solr-commons-csv artifact reused the code from the Apache Commons CSV
project but the package wasn't changed to something else than
org.apache.commons.csv in the process. This creates a compatibility issue as
the Apache Commons team works toward an official release of Commons CSV. It
prevents Commons CSV from using its own org.apache.commons.csv package, or
forces the renaming of all the classes to avoid a classpath conflict.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3795) Replace spatial contrib module with LSP's spatial-lucene module
[ https://issues.apache.org/jira/browse/LUCENE-3795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13221099#comment-13221099 ] Ryan McKinley commented on LUCENE-3795: --- bq. What's the reason to have spatial4j outside of Lucene? 1. Making JTS a 1st class test object (also why SIS is not an option) 2. The spatial4j.jar is useful on its own -- it has a chance to build its own community. 3. Lucene is not a great dev community for things that are not primarily lucene focused. I understand my primary concern (JTS) is a non issue for many people here -- The trade off to have compile/test dependencies on JTS isn't an option at ASF. I like this option because it gives lucene a solid ASL solution to support most things. *If* people want to add JTS to their runtime, they then get strong polygon support. The alternative packaging structure gets pretty crazy: In ASF Lucene Reps: * modules/spatial-base (no lucene dependencies) * modules/spatial-strategies (uses base) * solr/spatial... Elsewhere * spatial-base-jts (base with JTS) * spatial-strategies-with-jts * spatial-solr-with-jts If I want to make sure the JtsSpatialContext passes all the *same* tests that the SimpleSpatialContext passes, the structure gets even crazier because we have to package the test projects too! -- bq. We all agreed modules should be treated like lucene core hymmm -- my understanding is that modules have *flexibility* to have dependencies that are appropriate. Replace spatial contrib module with LSP's spatial-lucene module --- Key: LUCENE-3795 URL: https://issues.apache.org/jira/browse/LUCENE-3795 Project: Lucene - Java Issue Type: New Feature Components: modules/spatial Reporter: David Smiley Assignee: David Smiley Fix For: 4.0 I propose that Lucene's spatial contrib module be replaced with the spatial-lucene module within Lucene Spatial Playground (LSP). LSP has been in development for approximately 1 year by David Smiley, Ryan McKinley, and Chris Male and we feel it is ready. LSP is here: http://code.google.com/p/lucene-spatial-playground/ and the spatial-lucene module is intuitively in svn/trunk/spatial-lucene/. I'll add more comments to prevent the issue description from being too long. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3174) Visualize Cluster State
[ https://issues.apache.org/jira/browse/SOLR-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13221117#comment-13221117 ] Ryan McKinley commented on SOLR-3174: - I like the JIT layout best. Would be cool to be able to switch between the tree view: http://files.mathe.is/solr-admin/cloud-state/jit/ and a radial graph view: http://thejit.org/static/v20/Jit/Examples/RGraph/example1.html Visualize Cluster State --- Key: SOLR-3174 URL: https://issues.apache.org/jira/browse/SOLR-3174 Project: Solr Issue Type: New Feature Reporter: Ryan McKinley It would be great to visualize the cluster state in the new UI. See Mark's wish: https://issues.apache.org/jira/browse/SOLR-3162?focusedCommentId=13218272page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13218272 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-599) Lightweight SolrJ client
[ https://issues.apache.org/jira/browse/SOLR-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13221131#comment-13221131 ] Ryan McKinley commented on SOLR-599: I think SimpleHttpSolrServer.java should just go in the same package/jar file, next to CommonsHttpSolrServer A client can remove the other .jar files if they don't want the HTTP dependencies Lightweight SolrJ client Key: SOLR-599 URL: https://issues.apache.org/jira/browse/SOLR-599 Project: Solr Issue Type: Improvement Components: clients - java Reporter: Shalin Shekhar Mangar Assignee: Noble Paul Priority: Minor Fix For: 3.6, 4.0 Attachments: SOLR-599-fix-for-SolrJ-on-GAE.patch, SOLR-599.patch SolrJ provides a SolrServer implementation backed by commons-httpclient which introduces many dependency jars (commons-codec, commons-io and commons-logging). Apart from that SolrJ also uses StAX API for XML parsing which introduces dependencies like stax-api, stax and stax-utils. This enhancement will add a SolrServer implementation backed by java.net.HttpUrlConnection and will use BinaryResponseParser as the default response parser. Using this basic implementation out of the box would require no dependencies on either commons-httpclient or StAX. The only dependency would be on solr-commons making this a very lightweight and distribution friendly Java client for Solr. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2719) REGRESSION ReturnFields incorrect parse fields with hyphen - breaks existing fl=my-field-name type usecases
[ https://issues.apache.org/jira/browse/SOLR-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13221234#comment-13221234 ] Ryan McKinley commented on SOLR-2719: - I added the tests with @Ignore in revision: 1296434 REGRESSION ReturnFields incorrect parse fields with hyphen - breaks existing fl=my-field-name type usecases - Key: SOLR-2719 URL: https://issues.apache.org/jira/browse/SOLR-2719 Project: Solr Issue Type: Bug Components: search Affects Versions: 4.0 Reporter: Nik V. Babichev Priority: Blocker Labels: field, fl, query, queryparser Fix For: 4.0 Attachments: SOLR-2719.patch fl=my-hyphen-field in query params parsed as my instead of my-hyphen-field. OAS.search.ReturnFields use method getId() from OAS.search.QueryParsing in which check chars if (!Character.isJavaIdentifierPart(ch) ch != '.') Hyphen is not JavaIdentifierPart and this check break when first - is found. This problem solve by passing '-' to check: if (!Character.isJavaIdentifierPart(ch) ch != '.' ch != '-') break; But I don't know how it can affect on whole project. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3795) Replace spatial contrib module with LSP's spatial-lucene module
[ https://issues.apache.org/jira/browse/LUCENE-3795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13220614#comment-13220614 ] Ryan McKinley commented on LUCENE-3795: --- OK, I think the branch is ready to go. The one thing I don't like is that the spatial4j.jar gets included twice, once in the modules 'lib' directory and again in the solr lib directory. I could not figure out how to have the solr build compile and distribute this one Replace spatial contrib module with LSP's spatial-lucene module --- Key: LUCENE-3795 URL: https://issues.apache.org/jira/browse/LUCENE-3795 Project: Lucene - Java Issue Type: New Feature Components: modules/spatial Reporter: David Smiley Assignee: David Smiley Fix For: 4.0 I propose that Lucene's spatial contrib module be replaced with the spatial-lucene module within Lucene Spatial Playground (LSP). LSP has been in development for approximately 1 year by David Smiley, Ryan McKinley, and Chris Male and we feel it is ready. LSP is here: http://code.google.com/p/lucene-spatial-playground/ and the spatial-lucene module is intuitively in svn/trunk/spatial-lucene/. I'll add more comments to prevent the issue description from being too long. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3174) Visualize Cluster State
[ https://issues.apache.org/jira/browse/SOLR-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218362#comment-13218362 ] Ryan McKinley commented on SOLR-3174: - There are a few libraries that could make this relativly straightforward and good looking: http://flare.prefuse.org/demo http://jsplumb.org/jquery/chartDemo.html http://neyric.github.com/wireit/ Visualize Cluster State --- Key: SOLR-3174 URL: https://issues.apache.org/jira/browse/SOLR-3174 Project: Solr Issue Type: New Feature Reporter: Ryan McKinley It would be great to visualize the cluster state in the new UI. See Mark's wish: https://issues.apache.org/jira/browse/SOLR-3162?focusedCommentId=13218272page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13218272 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3134) Include shard Information in response
[ https://issues.apache.org/jira/browse/SOLR-3134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218962#comment-13218962 ] Ryan McKinley commented on SOLR-3134: - Thanks Russell -- that test is very helpful! I added to trunk in revision: 1294995 I'll take a stab at merging with 3.x Include shard Information in response - Key: SOLR-3134 URL: https://issues.apache.org/jira/browse/SOLR-3134 Project: Solr Issue Type: Improvement Components: SearchComponents - other Reporter: Ryan McKinley Assignee: Ryan McKinley Fix For: 4.0 Attachments: SOLR-3134-shard-info-3_5-backport.patch, SOLR-3134-shard-info-3_x-backport.patch, SOLR-3134-shard-info-fix.patch, SOLR-3134-shard-info.patch For distributed search where each shard represents a logically different index (or physical location), it would be great to know the hit count for each shard. In addition, it would be nice to get error info for each shard rather then aborting the whole request when something fails. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3795) Replace spatial contrib module with LSP's spatial-lucene module
[ https://issues.apache.org/jira/browse/LUCENE-3795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13217399#comment-13217399 ] Ryan McKinley commented on LUCENE-3795: --- I like the idea that spatial-base would be external to lucene, and included as a .jar file. This was my original proposal when starting to discuss this long ago. As is, the spatial library is quite useful on its own; I think it has the best chance of long term success outside of lucene. Outside lucene (ASF) it can have compile/test dependencies on JTS that make it more robust but still have strong ASL only runtime. Replace spatial contrib module with LSP's spatial-lucene module --- Key: LUCENE-3795 URL: https://issues.apache.org/jira/browse/LUCENE-3795 Project: Lucene - Java Issue Type: New Feature Components: modules/spatial Reporter: David Smiley Assignee: David Smiley Fix For: 4.0 I propose that Lucene's spatial contrib module be replaced with the spatial-lucene module within Lucene Spatial Playground (LSP). LSP has been in development for approximately 1 year by David Smiley, Ryan McKinley, and Chris Male and we feel it is ready. LSP is here: http://code.google.com/p/lucene-spatial-playground/ and the spatial-lucene module is intuitively in svn/trunk/spatial-lucene/. I'll add more comments to prevent the issue description from being too long. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1233) Remove restriction that /select cannot be used for /-prefixed request handlers via qt
[ https://issues.apache.org/jira/browse/SOLR-1233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13215821#comment-13215821 ] Ryan McKinley commented on SOLR-1233: - For background, in the original RequestHandler design, we disallowed qt with leading '/' for security reasons. While solr does not internally support security, we need to make sure that it does not prevent standard path based security. +1 to put the restriction back Remove restriction that /select cannot be used for /-prefixed request handlers via qt - Key: SOLR-1233 URL: https://issues.apache.org/jira/browse/SOLR-1233 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: Erik Hatcher Assignee: Erik Hatcher Priority: Minor Fix For: 1.4 Attachments: SOLR-1233.patch Currently /select?qt=/whatever is blocked by SolrDispatchFilter. It makes life a lot easier to make general requests to any request handler (for example in SOLR-1230 where dataimport.jsp needs to request to arbitrary handler names). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3161) Use of 'qt' should be restricted to searching and should not start with a '/'
[ https://issues.apache.org/jira/browse/SOLR-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13215830#comment-13215830 ] Ryan McKinley commented on SOLR-3161: - +1 then we can get rid of the handleSelect logic in RequestDispatcher (this was added when we converted from Servlet to Filter and allowed path based handlers) Use of 'qt' should be restricted to searching and should not start with a '/' - Key: SOLR-3161 URL: https://issues.apache.org/jira/browse/SOLR-3161 Project: Solr Issue Type: Improvement Components: search, web gui Reporter: David Smiley Assignee: David Smiley Fix For: 3.6, 4.0 I haven't yet looked at the code involved for suggestions here; I'm speaking based on how I think things should work and not work, based on intuitiveness and security. In general I feel it is best practice to use '/' leading request handler names and not use qt, but I don't hate it enough when used in limited (search-only) circumstances to propose its demise. But if someone proposes its deprecation that then I am +1 for that. Here is my proposal: Solr should error if the parameter qt is supplied with a leading '/'. (trunk only) Solr should only honor qt if the target request handler extends solr.SearchHandler. The new admin UI should only use 'qt' when it has to. For the query screen, it could present a little pop-up menu of handlers to choose from, including /select?qt=mycustom for handlers that aren't named with a leading '/'. This choice should be positioned at the top. And before I forget, me or someone should investigate if there are any similar security problems with the shards.qt parameter. Perhaps shards.qt can abide by the same rules outlined above. Does anyone foresee any problems with this proposal? On a related subject, I think the notion of a default request handler is bad - the default=true thing. Honestly I'm not sure what it does, since I noticed Solr trunk redirects '/solr/' to the new admin UI at '/solr/#/'. Assuming it doesn't do anything useful anymore, I think it would be clearer to use requestHandler name=/select class=solr.SearchHandler instead of what's there now. The delta is to put the leading '/' on this request handler name, and remove the default attribute. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1143) Return partial results when a connection to a shard is refused
[ https://issues.apache.org/jira/browse/SOLR-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13215891#comment-13215891 ] Ryan McKinley commented on SOLR-1143: - I have not looked at this patch... but check if SOLR-3134 does what you need (that is included in trunk) If you add: shards.tolerant=true to the request, it will not abort on errors (timeout or other) Return partial results when a connection to a shard is refused -- Key: SOLR-1143 URL: https://issues.apache.org/jira/browse/SOLR-1143 Project: Solr Issue Type: Improvement Components: search Reporter: Nicolas Dessaigne Fix For: 3.6, 4.0 Attachments: SOLR-1143-2.patch, SOLR-1143-3.patch, SOLR-1143.patch If any shard is down in a distributed search, a ConnectException it thrown. Here's a little patch that change this behaviour: if we can't connect to a shard (ConnectException), we get partial results from the active shards. As for TimeOut parameter (https://issues.apache.org/jira/browse/SOLR-502), we set the parameter partialResults at true. This patch also adresses a problem expressed in the mailing list about a year ago (http://www.nabble.com/partialResults,-distributed-search---SOLR-502-td19002610.html) We have a use case that needs this behaviour and we would like to know your thougths about such a behaviour? Should it be the default behaviour for distributed search? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3161) Use of 'qt' should be restricted to searching and should not start with a '/'
[ https://issues.apache.org/jira/browse/SOLR-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13216000#comment-13216000 ] Ryan McKinley commented on SOLR-3161: - bq. And I guess Yonik's right about keeping the old name, even though it's a bad one. I don't think its fair to call it a bad one -- it is just no longer the most appropriate name. qt came from before RequestHandlers existed. Old names is the tradeoff we have with strong back-compatibility Use of 'qt' should be restricted to searching and should not start with a '/' - Key: SOLR-3161 URL: https://issues.apache.org/jira/browse/SOLR-3161 Project: Solr Issue Type: Improvement Components: search, web gui Reporter: David Smiley Assignee: David Smiley Fix For: 3.6, 4.0 I haven't yet looked at the code involved for suggestions here; I'm speaking based on how I think things should work and not work, based on intuitiveness and security. In general I feel it is best practice to use '/' leading request handler names and not use qt, but I don't hate it enough when used in limited (search-only) circumstances to propose its demise. But if someone proposes its deprecation that then I am +1 for that. Here is my proposal: Solr should error if the parameter qt is supplied with a leading '/'. (trunk only) Solr should only honor qt if the target request handler extends solr.SearchHandler. The new admin UI should only use 'qt' when it has to. For the query screen, it could present a little pop-up menu of handlers to choose from, including /select?qt=mycustom for handlers that aren't named with a leading '/'. This choice should be positioned at the top. And before I forget, me or someone should investigate if there are any similar security problems with the shards.qt parameter. Perhaps shards.qt can abide by the same rules outlined above. Does anyone foresee any problems with this proposal? On a related subject, I think the notion of a default request handler is bad - the default=true thing. Honestly I'm not sure what it does, since I noticed Solr trunk redirects '/solr/' to the new admin UI at '/solr/#/'. Assuming it doesn't do anything useful anymore, I think it would be clearer to use requestHandler name=/select class=solr.SearchHandler instead of what's there now. The delta is to put the leading '/' on this request handler name, and remove the default attribute. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3360) Move FieldCache to IndexReader
[
https://issues.apache.org/jira/browse/LUCENE-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214451#comment-13214451
]
Ryan McKinley commented on LUCENE-3360:
---
wow, lots has changed since the last patch! I *think* all the reader/cache
refactoring has settled down, so this would be good to get sorted soon.
I ran it through the LUCENE-3753.patch.hack.pl but there are enough changes,
that it is significant work to resurrect from the patch; it may be more
effective to refactor the code.
Martijn, you interested in picking this up again? If no, i may give it a try.
Move FieldCache to IndexReader
--
Key: LUCENE-3360
URL: https://issues.apache.org/jira/browse/LUCENE-3360
Project: Lucene - Java
Issue Type: Improvement
Reporter: Martijn van Groningen
Fix For: 3.6, 4.0
Attachments: LUCENE-3360-3x.patch, LUCENE-3360-3x.patch,
LUCENE-3360-3x.patch, LUCENE-3360.patch, LUCENE-3360.patch,
LUCENE-3360.patch, LUCENE-3360.patch, LUCENE-3360.patch, LUCENE-3360.patch,
LUCENE-3360.patch
Move the static FieldCache.DEFAULT field instance to atomic IndexReaders, so
that FieldCache insanity caused by the WeakHashMap no longer occurs.
* Add a new method to IndexReader that by default throws an UOE:
{code}public FieldCache getFieldCache(){code}
* The SegmentReader implements this method and returns its own internal
FieldCache implementation. This implementation just uses a
HashMapEntryT,Object to store entries.
* The SlowMultiReaderWrapper implements this method as well and basically
behaves the same as the current FieldCacheImpl.
This issue won't solve the insanity that comes from inconsistent usage of a
single field (for example retrieve both int[] and DocTermIndex for the same
field).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2667) Finish Solr Admin UI
[ https://issues.apache.org/jira/browse/SOLR-2667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214876#comment-13214876 ] Ryan McKinley commented on SOLR-2667: - Stefan -- this looks much better! Finish Solr Admin UI Key: SOLR-2667 URL: https://issues.apache.org/jira/browse/SOLR-2667 Project: Solr Issue Type: Improvement Reporter: Ryan McKinley Assignee: Ryan McKinley Fix For: 4.0 Attachments: SOLR-2667-110722.patch In SOLR-2399, we added a new admin UI. The issue has gotten too long to follow, so this is a new issue to track remaining tasks. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3116) new Admin UI does not allow drill-down into ZooKeeper
[ https://issues.apache.org/jira/browse/SOLR-3116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214921#comment-13214921 ] Ryan McKinley commented on SOLR-3116: - +1 Stefan -- its great to see you back from the great yonder! new Admin UI does not allow drill-down into ZooKeeper - Key: SOLR-3116 URL: https://issues.apache.org/jira/browse/SOLR-3116 Project: Solr Issue Type: Bug Affects Versions: 4.0 Environment: All Reporter: Erick Erickson Priority: Minor Attachments: SOLR-3116-file-content.png One thing missing from the old UI for the ZooKeeper view - you can no longer see the data at each node (or at least I have not figured out how) - just the node listing. (Mark Miller, broken out from SOLR-2667) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2667) Finish Solr Admin UI
[ https://issues.apache.org/jira/browse/SOLR-2667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13215005#comment-13215005 ] Ryan McKinley commented on SOLR-2667: - on the r.js stuff... what is the advantage? Is it just optimize the load times? For the admin UI, I think we should optimize readability/maintainability over load time. Finish Solr Admin UI Key: SOLR-2667 URL: https://issues.apache.org/jira/browse/SOLR-2667 Project: Solr Issue Type: Improvement Reporter: Ryan McKinley Assignee: Ryan McKinley Fix For: 4.0 Attachments: SOLR-2667-110722.patch, SOLR-2667-120223-ant-target.patch, SOLR-2667-120223-file-structure.patch In SOLR-2399, we added a new admin UI. The issue has gotten too long to follow, so this is a new issue to track remaining tasks. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3795) Replace spatial contrib module with LSP's spatial-lucene module
[ https://issues.apache.org/jira/browse/LUCENE-3795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13215124#comment-13215124 ] Ryan McKinley commented on LUCENE-3795: --- bq. What is the advantage of two spatial modules? Can I run spatial queries with just base by itself? The real advantage is that client code (solrj etc) can know about Shapes/Operations without needing to include lucene. From spatial-base, you can *build* queries and understand the results; but can't run the query. I need my client code to use a real API rather then needing to build the correct String query representations and parsing results. Replace spatial contrib module with LSP's spatial-lucene module --- Key: LUCENE-3795 URL: https://issues.apache.org/jira/browse/LUCENE-3795 Project: Lucene - Java Issue Type: New Feature Components: modules/spatial Reporter: David Smiley Assignee: David Smiley Fix For: 4.0 I propose that Lucene's spatial contrib module be replaced with the spatial-lucene module within Lucene Spatial Playground (LSP). LSP has been in development for approximately 1 year by David Smiley, Ryan McKinley, and Chris Male and we feel it is ready. LSP is here: http://code.google.com/p/lucene-spatial-playground/ and the spatial-lucene module is intuitively in svn/trunk/spatial-lucene/. I'll add more comments to prevent the issue description from being too long. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3795) Replace spatial contrib module with LSP's spatial-lucene module
[ https://issues.apache.org/jira/browse/LUCENE-3795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13215253#comment-13215253 ] Ryan McKinley commented on LUCENE-3795: --- I guess I don't see the problem with having multiple .jar files (aside from the ant setup effort) I'm fine with one .jar if we guarantee that the 'base' classes don't have compile time access to lucene classes. I'm sure there is some ant crazieness to compile half the project with different classpaths then bundle them together, but that seems more complex (and less clear) then two .jar files Replace spatial contrib module with LSP's spatial-lucene module --- Key: LUCENE-3795 URL: https://issues.apache.org/jira/browse/LUCENE-3795 Project: Lucene - Java Issue Type: New Feature Components: modules/spatial Reporter: David Smiley Assignee: David Smiley Fix For: 4.0 I propose that Lucene's spatial contrib module be replaced with the spatial-lucene module within Lucene Spatial Playground (LSP). LSP has been in development for approximately 1 year by David Smiley, Ryan McKinley, and Chris Male and we feel it is ready. LSP is here: http://code.google.com/p/lucene-spatial-playground/ and the spatial-lucene module is intuitively in svn/trunk/spatial-lucene/. I'll add more comments to prevent the issue description from being too long. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3159) Upgrade to Jetty 8
[ https://issues.apache.org/jira/browse/SOLR-3159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13215304#comment-13215304 ] Ryan McKinley commented on SOLR-3159: - I will make a branch for this so that it is easy to compare the two options. One kicker is that JSP in Jetty 7 or 8 requires a JDK, not just the JRE. But with progress on the new UI, I think we can drop JSP entirely (good riddance!) Upgrade to Jetty 8 -- Key: SOLR-3159 URL: https://issues.apache.org/jira/browse/SOLR-3159 Project: Solr Issue Type: Task Reporter: Ryan McKinley Priority: Minor Fix For: 4.0 Solr is currently tested (and bundled) with a patched jetty-6 version. Ideally we can release and test with a standard version. Jetty-6 (at codehaus) is just maintenance now. New development and improvements are now hosted at eclipse. Assuming performance is equivalent, I think we should switch to Jetty 8. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
