[Lucene.Net] Official stance on API changes between major versions

2012-02-24 Thread Christopher Currens 
A bit of background about what I've been doing lately on the project.
 Because we've now confirmed that the .NET 3.0.3 branch is a completed port
of Java 3.0.3 version, I've been spending time trying to work on some of
the bugs and improvements that are assigned to this version.  There wasn't
any real discussion about the actual features, I just created some (based
on mailing list discussions) and assigned them to the 3.0.3 release.  The
improvements I've been working on lately are ones that have bugged me
specifically since I've started using Lucene.NET.

I've worked on https://issues.apache.org/jira/browse/LUCENENET-468 and
https://issues.apache.org/jira/browse/LUCENENET-470 so far.

LUCENENET-740 is pretty much completed, all of the classes that implemented
Closeable() now implement IDisposable, having a public void Dispose()
and/or protected virtual void Dispose(bool disposing), depending if the
class is sealed or not.  What is left to do on that issue would be to make
sure that all of the tests are a) overriding the protected dispose method
as needed and b) are actually calling Dispose or are in a using statement.

I've done quite a bit of work on LUCENENET-468, as well, though it is going
far slower than 470, because there's a lot more that needs to be done and a
bit more carefully, if I don't want to break anyone's code when they move
to 3.0.  I'm not doing them in any particular order, I'm really just
running VS2010 code analysis (Rule CA1024 only, actually) and changing the
ones suggested and ones I happen across to use Properties.  I've also spent
some time trying to wrap public fields in public properties.  However, this
one in particular has been posing some problems for me, and really brings
me to the point of this email.

Due to the way most class members are named (there's a lot of redundancy),
I'm finding it difficult to move forward with some of these refactoring
without breaking backwards compatibility or adding more things to change in
regards to LUCENE-446 and CLS compliance.  For classes that are
specifically marked internal, this of course, hasn't been a problem, I just
make the breaking change and fix it other places in the library.  This is,
of course, a problem with class that are public, including classes that
*should not* be marked public but are anyway.  It's a little off topic, but
we stray far sometimes from the access modifiers defined on the java
classes.  I've found that nearly all cases were because they were needed
for the NUnit tests.  That problem no longer exists in 3.0.3, as the Test
library can now access those types in the core assembly.  I personally feel
that whenever we find an difference in access modifiers, we change it to
match java, however, if customers are using that, well, now they can't.
 That's issue number one that I wanted to discuss with the group.

Going back to the difficulties in .NET-ifying the API, often times if I
want to convert a Get[name]()/Set[name]() group or individual method to a
property, the resulting property name will conflict with an already
existing public field, another method with the exact same name, or the name
of the enclosing type itself.  The latter can't easily be solved, so I'm
not fretting too much about it.  The first two are easier to solve, but not
without breaking backwards compatibility for some users.

Now, the API between 2.x and 3.x differs greatly, so some customers *may*
have to make changes anyway.  However, that's not a good rule, since most,
if not all, of the breaking changes made to Lucene.NET were first obsoleted
for a period of time, and thus they were given plenty of warning to change
their code.  Unfortunately, with these changes, we haven't given them the
same notice.  So far, I've been trying my best to make sure that all
changes that have been made, have been done in a way that won't break any
compatibility.  All of the classes that now implement Dispose() still have
a Close() method that's now obsoleted (see the PS).  For properties, I've
been keeping the Get/Set methods, moving the code to the property, and
marking them obsoleted.  I figure that this is the workflow we want, but
I'm finding it's not always possible, so I'd like to see what the group has
to say about it.  How strict will we be?


Thanks,
Christopher

P.S. So in regards to classes implementing Dispose() and backwards
compatibility.  Yes, they still have a Close() method that is obsoleted.
 However, with some classes, for me to make the change, I had to add
IDisposable to an abstract class or interface.  In some cases, it was
breaking.  If Close() before was abstract, I made the new protected void
Dispose(bool) method abstract, removed virtual from Close() and had it call
Dispose().  This is a breaking change since and class that inherited from
that class will now have multiple build errors, one for trying to override
a non-virtual member (Close()) and another for not implementing the
protected dispose method.  So, perhaps that needs

RE: [Lucene.Net] Official stance on API changes between major versions

2012-02-24 Thread Prescott Nasser 
Im not against breaking compatibility when changing the version number to a new 
major 2 - 3. Im not sure how others feel. Matching Java access modifiers seems 
like the right move.

That said, what if we mark obsolete in 3.0.3 and when we make the jump to 4.0 
wipe them out? In my head we shouldn't spend too much time cleaning up 3.0.3 
aside from bug fixes if were just going to swap it for 4.0 in the near future.

There has to be a break at some point, making it with a major release is the 
best place to make it.

Sent from my Windows Phone

From: Christopher Currens
Sent: 2/24/2012 2:45 PM
To: lucene-net-dev@lucene.apache.org
Subject: [Lucene.Net] Official stance on API changes between major versions

A bit of background about what I've been doing lately on the project.
 Because we've now confirmed that the .NET 3.0.3 branch is a completed port
of Java 3.0.3 version, I've been spending time trying to work on some of
the bugs and improvements that are assigned to this version.  There wasn't
any real discussion about the actual features, I just created some (based
on mailing list discussions) and assigned them to the 3.0.3 release.  The
improvements I've been working on lately are ones that have bugged me
specifically since I've started using Lucene.NET.

I've worked on https://issues.apache.org/jira/browse/LUCENENET-468 and
https://issues.apache.org/jira/browse/LUCENENET-470 so far.

LUCENENET-740 is pretty much completed, all of the classes that implemented
Closeable() now implement IDisposable, having a public void Dispose()
and/or protected virtual void Dispose(bool disposing), depending if the
class is sealed or not.  What is left to do on that issue would be to make
sure that all of the tests are a) overriding the protected dispose method
as needed and b) are actually calling Dispose or are in a using statement.

I've done quite a bit of work on LUCENENET-468, as well, though it is going
far slower than 470, because there's a lot more that needs to be done and a
bit more carefully, if I don't want to break anyone's code when they move
to 3.0.  I'm not doing them in any particular order, I'm really just
running VS2010 code analysis (Rule CA1024 only, actually) and changing the
ones suggested and ones I happen across to use Properties.  I've also spent
some time trying to wrap public fields in public properties.  However, this
one in particular has been posing some problems for me, and really brings
me to the point of this email.

Due to the way most class members are named (there's a lot of redundancy),
I'm finding it difficult to move forward with some of these refactoring
without breaking backwards compatibility or adding more things to change in
regards to LUCENE-446 and CLS compliance.  For classes that are
specifically marked internal, this of course, hasn't been a problem, I just
make the breaking change and fix it other places in the library.  This is,
of course, a problem with class that are public, including classes that
*should not* be marked public but are anyway.  It's a little off topic, but
we stray far sometimes from the access modifiers defined on the java
classes.  I've found that nearly all cases were because they were needed
for the NUnit tests.  That problem no longer exists in 3.0.3, as the Test
library can now access those types in the core assembly.  I personally feel
that whenever we find an difference in access modifiers, we change it to
match java, however, if customers are using that, well, now they can't.
 That's issue number one that I wanted to discuss with the group.

Going back to the difficulties in .NET-ifying the API, often times if I
want to convert a Get[name]()/Set[name]() group or individual method to a
property, the resulting property name will conflict with an already
existing public field, another method with the exact same name, or the name
of the enclosing type itself.  The latter can't easily be solved, so I'm
not fretting too much about it.  The first two are easier to solve, but not
without breaking backwards compatibility for some users.

Now, the API between 2.x and 3.x differs greatly, so some customers *may*
have to make changes anyway.  However, that's not a good rule, since most,
if not all, of the breaking changes made to Lucene.NET were first obsoleted
for a period of time, and thus they were given plenty of warning to change
their code.  Unfortunately, with these changes, we haven't given them the
same notice.  So far, I've been trying my best to make sure that all
changes that have been made, have been done in a way that won't break any
compatibility.  All of the classes that now implement Dispose() still have
a Close() method that's now obsoleted (see the PS).  For properties, I've
been keeping the Get/Set methods, moving the code to the property, and
marking them obsoleted.  I figure that this is the workflow we want, but
I'm finding it's not always possible, so I'd like to see what the group has
to say about

Tika language API (since Solr3.5.0) integrated into Solr3.3.0?

2012-02-24 Thread bing 
Hi, all,

I have been deploying Solr3.5.0 and using
org.apache.solr.update.processor.TikaLanguageIdentifierUpdateProcessorFactory
and LangDetectLanguageIdentifierUpdateProcessorFactory to do language
detection, and they are cool. They are both active since Solr3.5.0. 
 
An issue: if I deploy Solr3.3.0, is it possible to the factories in
Solr3.5.0 be integrated into Solr3.3.0?

Why I stick on Solr3.3.0? The reason is, I am working on Dspace (discovery)
to invoke solr index/query, and for now the highest version of Solr can be
upgraded to is 3.3.0.

Does any one happen to know certain way to solve this? Or any relevant
branches going on? 

Thank you. 

Best Regards,
Bing 

--
View this message in context: 
http://lucene.472066.n3.nabble.com/Tika-language-API-since-Solr3-5-0-integrated-into-Solr3-3-0-tp3772011p3772011.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: FieldCache future?

2012-02-24 Thread Martijn v Groningen 
 Grouping etc could work solely on a docvalues api and maybe they have
 a special ctor to take a SortedBytes impl (and fieldcache implements
 the docvalues api or some other backwards mechanism).
 This would remove the redundant implementations (both fieldcache and
 DV implementations) in stuff like grouping, join, sort, etc
+1 That is great, b/c there already are docvalues based grouping
implementations.

We don't need to have a special SortedBytes ctor, right? The grouping
ctors do take a DocValues.Type (joining, faceting etc can do the
same). In the setNextReader method IR.docValues(groupField) is
invoked.

I'll also close LUCENE-3360 since it only couples the FC with IR.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-3160) Division by zero in StatsComponent with date field always missing

2012-02-24 Thread Luca Cavanna (Created) (JIRA) 
Division by zero in StatsComponent with date field always missing
-

 Key: SOLR-3160
 URL: https://issues.apache.org/jira/browse/SOLR-3160
 Project: Solr
  Issue Type: Bug
Affects Versions: 3.5
Reporter: Luca Cavanna
Assignee: Luca Cavanna
Priority: Minor
 Fix For: 3.6, 4.0


Using the StatsComponent with a date field that never has a value you'll get 
{code}
java.lang.ArithmeticException: / by zero at 
org.apache.solr.handler.component.DateStatsValues.addTypeSpecificStats 
(StatsValuesFactory.java:384)
{code}

The problem is in this line of DateStatsValues:
{code}
res.add(mean, new Date(sum / count));
{code}

If count is 0 the division throws ArithmeticException because sum is long here. 
This doesn't happen with NumericStatsValues because sum is double there and the 
division result is Nan.
By the way, the result of those divisions is not even included in the output 
when count is 0 because of this condition in SimpleStats#getStatsFields:
{code}
if (isShard == true || (Long) stv.get(count)  0) {
res.add(f, stv);
} else {
res.add(f, null);
}
{code}

Therefore, it should never throw an exception!

--
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-3156) Check for locks on startup

2012-02-24 Thread Martijn van Groningen (Commented) (JIRA) 

[ 
https://issues.apache.org/jira/browse/SOLR-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13215538#comment-13215538
 ] 

Martijn van Groningen commented on SOLR-3156:
-

I also prefer to know that the index is locked at startup than when the first 
document is added!
Opening and then closing a SolrIndexReader seems like the most easy way to 
check this in the SolrCore#initIndex method.

 Check for locks on startup
 --

 Key: SOLR-3156
 URL: https://issues.apache.org/jira/browse/SOLR-3156
 Project: Solr
  Issue Type: Improvement
Reporter: Luca Cavanna

 When using simple or native lockType and the application server is not 
 shutdown properly (kill -9), you don't notice problems until someone tries to 
 add or delete a document. In fact, you get errors every time Solr opens a new 
 IndexWriter on the locked index. I'm aware of the unlockOnStartup option, 
 but I'd prefer to know and act properly when there's a lock, and I think it 
 would be better to know on startup, since Solr is not going to work properly.

--
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] [Issue Comment Edited] (SOLR-3156) Check for locks on startup

2012-02-24 Thread Martijn van Groningen (Issue Comment Edited) (JIRA) 

[ 
https://issues.apache.org/jira/browse/SOLR-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13215538#comment-13215538
 ] 

Martijn van Groningen edited comment on SOLR-3156 at 2/24/12 10:46 AM:
---

I also prefer to know that the index is locked at startup than when the first 
document is added!
Opening and then closing a SolrIndexWriter seems like the most easy way to 
check this in the SolrCore#initIndex method.

  was (Author: martijn.v.groningen):
I also prefer to know that the index is locked at startup than when the 
first document is added!
Opening and then closing a SolrIndexReader seems like the most easy way to 
check this in the SolrCore#initIndex method.
  
 Check for locks on startup
 --

 Key: SOLR-3156
 URL: https://issues.apache.org/jira/browse/SOLR-3156
 Project: Solr
  Issue Type: Improvement
Reporter: Luca Cavanna

 When using simple or native lockType and the application server is not 
 shutdown properly (kill -9), you don't notice problems until someone tries to 
 add or delete a document. In fact, you get errors every time Solr opens a new 
 IndexWriter on the locked index. I'm aware of the unlockOnStartup option, 
 but I'd prefer to know and act properly when there's a lock, and I think it 
 would be better to know on startup, since Solr is not going to work properly.

--
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] [Updated] (SOLR-3160) Division by zero in StatsComponent with date field always missing

2012-02-24 Thread Luca Cavanna (Updated) (JIRA) 

 [ 
https://issues.apache.org/jira/browse/SOLR-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Luca Cavanna updated SOLR-3160:
---

Attachment: SOLR-3160.patch

Attached patch containing some new test methods and a fix within 
DateStatsvalues.
StatsComponentTest tests now the same situation (count=0) for string, date and 
numeric field, and the result is the same.


 Division by zero in StatsComponent with date field always missing
 -

 Key: SOLR-3160
 URL: https://issues.apache.org/jira/browse/SOLR-3160
 Project: Solr
  Issue Type: Bug
Affects Versions: 3.5
Reporter: Luca Cavanna
Assignee: Luca Cavanna
Priority: Minor
 Fix For: 3.6, 4.0

 Attachments: SOLR-3160.patch


 Using the StatsComponent with a date field that never has a value you'll get 
 {code}
 java.lang.ArithmeticException: / by zero at 
 org.apache.solr.handler.component.DateStatsValues.addTypeSpecificStats 
 (StatsValuesFactory.java:384)
 {code}
 The problem is in this line of DateStatsValues:
 {code}
 res.add(mean, new Date(sum / count));
 {code}
 If count is 0 the division throws ArithmeticException because sum is long 
 here. This doesn't happen with NumericStatsValues because sum is double there 
 and the division result is Nan.
 By the way, the result of those divisions is not even included in the output 
 when count is 0 because of this condition in SimpleStats#getStatsFields:
 {code}
 if (isShard == true || (Long) stv.get(count)  0) {
 res.add(f, stv);
 } else {
 res.add(f, null);
 }
 {code}
 Therefore, it should never throw an exception!

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

Re: [jira] [Issue Comment Edited] (SOLR-2202) Money FieldType

2012-02-24 Thread Erick Erickson 
Go for CurrencyType IMO. Although I think either is reasonalble

On Fri, Feb 24, 2012 at 2:47 AM, Jan Høydahl (Issue Comment Edited)
(JIRA) j...@apache.org wrote:

    [ 
 https://issues.apache.org/jira/browse/SOLR-2202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13210893#comment-13210893
  ]

 Jan Høydahl edited comment on SOLR-2202 at 2/24/12 7:46 AM:
 

 Had no chance to get back to this yet. Afraid I won't have time next week 
 either :(

 In the mean time, perhaps other committers could chime in with their views on 
 preferred naming?
 a) MoneyType
 b) MoneyField
 c) CurrencyType
 d) CurrencyField

 As for range facets, I'll open a new issue once the basics for this is 
 committed.

      was (Author: janhoy):
    Had no chance to get back to this yet. Afraid I won't have time next week 
 either :(

 In the mean time, perhaps other committers could chime in with their views on 
 preferred naming and range faceting?

 Money FieldType
 ---

                 Key: SOLR-2202
                 URL: https://issues.apache.org/jira/browse/SOLR-2202
             Project: Solr
          Issue Type: New Feature
          Components: Schema and Analysis
    Affects Versions: 1.5
            Reporter: Greg Fodor
            Assignee: Jan Høydahl
             Fix For: 3.6, 4.0

         Attachments: SOLR-2022-solr-3.patch, SOLR-2202-lucene-1.patch, 
 SOLR-2202-solr-1.patch, SOLR-2202-solr-2.patch, SOLR-2202-solr-4.patch, 
 SOLR-2202-solr-5.patch, SOLR-2202-solr-6.patch, SOLR-2202-solr-7.patch, 
 SOLR-2202-solr-8.patch, SOLR-2202-solr-9.patch, SOLR-2202.patch, 
 SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch


 Provides support for monetary values to Solr/Lucene with query-time currency 
 conversion. The following features are supported:
 - Point queries
 - Range quries
 - Sorting
 - Currency parsing by either currency code or symbol.
 - Symmetric  Asymmetric exchange rates. (Asymmetric exchange rates are 
 useful if there are fees associated with exchanging the currency.)
 At indexing time, money fields can be indexed in a native currency. For 
 example, if a product on an e-commerce site is listed in Euros, indexing the 
 price field as 1000,EUR will index it appropriately. By altering the 
 currency.xml file, the sorting and querying against Solr can take into 
 account fluctuations in currency exchange rates without having to re-index 
 the documents.
 The new money field type is a polyfield which indexes two fields, one 
 which contains the amount of the value and another which contains the 
 currency code or symbol. The currency metadata (names, symbols, codes, and 
 exchange rates) are expected to be in an xml file which is pointed to by the 
 field type declaration in the schema.xml.
 The current patch is factored such that Money utility functions and 
 configuration metadata lie in Lucene (see MoneyUtil and CurrencyConfig), 
 while the MoneyType and MoneyValueSource lie in Solr. This was meant to 
 mirror the work being done on the spacial field types.
 This patch will be getting used to power the international search 
 capabilities of the search engine at Etsy.
 Also see WIKI page: http://wiki.apache.org/solr/MoneyFieldType

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


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-3116) new Admin UI does not allow drill-down into ZooKeeper

2012-02-24 Thread Stefan Matheis (steffkes) (Updated) (JIRA) 

 [ 
https://issues.apache.org/jira/browse/SOLR-3116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Matheis (steffkes) updated SOLR-3116:


Attachment: SOLR-3116-120224-crop-tree-area.patch

Quick Patch, that the (left) Tree Area is cropped if the File-Details are 
displayed

 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-120224-crop-tree-area.patch, 
 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] [Assigned] (SOLR-3160) Division by zero in StatsComponent with date field always missing

2012-02-24 Thread Erick Erickson (Assigned) (JIRA) 

 [ 
https://issues.apache.org/jira/browse/SOLR-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erick Erickson reassigned SOLR-3160:


Assignee: Erick Erickson  (was: Luca Cavanna)

 Division by zero in StatsComponent with date field always missing
 -

 Key: SOLR-3160
 URL: https://issues.apache.org/jira/browse/SOLR-3160
 Project: Solr
  Issue Type: Bug
Affects Versions: 3.5
Reporter: Luca Cavanna
Assignee: Erick Erickson
Priority: Minor
 Fix For: 3.6, 4.0

 Attachments: SOLR-3160.patch


 Using the StatsComponent with a date field that never has a value you'll get 
 {code}
 java.lang.ArithmeticException: / by zero at 
 org.apache.solr.handler.component.DateStatsValues.addTypeSpecificStats 
 (StatsValuesFactory.java:384)
 {code}
 The problem is in this line of DateStatsValues:
 {code}
 res.add(mean, new Date(sum / count));
 {code}
 If count is 0 the division throws ArithmeticException because sum is long 
 here. This doesn't happen with NumericStatsValues because sum is double there 
 and the division result is Nan.
 By the way, the result of those divisions is not even included in the output 
 when count is 0 because of this condition in SimpleStats#getStatsFields:
 {code}
 if (isShard == true || (Long) stv.get(count)  0) {
 res.add(f, stv);
 } else {
 res.add(f, null);
 }
 {code}
 Therefore, it should never throw an exception!

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

2012-02-24 Thread Erick Erickson (Commented) (JIRA) 

[ 
https://issues.apache.org/jira/browse/SOLR-3116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13215587#comment-13215587
 ] 

Erick Erickson commented on SOLR-3116:
--

Stefan (and Ryan and Bill too!)

I think we're at a good checkpoint here. I propose that I'll apply this new 
patch, give it a brief once-over and commit it if all goes well, probably this 
afternoon.

Then I'll close this JIRA, SOLR-2667 and SOLR-3155 and we can open new JIRAs 
for new issues.

Thoughts?

 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-120224-crop-tree-area.patch, 
 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-3160) Division by zero in StatsComponent with date field always missing

2012-02-24 Thread Luca Cavanna (Commented) (JIRA) 

[ 
https://issues.apache.org/jira/browse/SOLR-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13215589#comment-13215589
 ] 

Luca Cavanna commented on SOLR-3160:


Thanks Erick! 
Catch is not mine, it comes from this [StackOverflow 
question|http://stackoverflow.com/q/9368926/633239], I just reported the error 
and worked on the patch.

 Division by zero in StatsComponent with date field always missing
 -

 Key: SOLR-3160
 URL: https://issues.apache.org/jira/browse/SOLR-3160
 Project: Solr
  Issue Type: Bug
Affects Versions: 3.5
Reporter: Luca Cavanna
Assignee: Erick Erickson
Priority: Minor
 Fix For: 3.6, 4.0

 Attachments: SOLR-3160.patch


 Using the StatsComponent with a date field that never has a value you'll get 
 {code}
 java.lang.ArithmeticException: / by zero at 
 org.apache.solr.handler.component.DateStatsValues.addTypeSpecificStats 
 (StatsValuesFactory.java:384)
 {code}
 The problem is in this line of DateStatsValues:
 {code}
 res.add(mean, new Date(sum / count));
 {code}
 If count is 0 the division throws ArithmeticException because sum is long 
 here. This doesn't happen with NumericStatsValues because sum is double there 
 and the division result is Nan.
 By the way, the result of those divisions is not even included in the output 
 when count is 0 because of this condition in SimpleStats#getStatsFields:
 {code}
 if (isShard == true || (Long) stv.get(count)  0) {
 res.add(f, stv);
 } else {
 res.add(f, null);
 }
 {code}
 Therefore, it should never throw an exception!

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

2012-02-24 Thread Stefan Matheis (steffkes) (Commented) (JIRA) 

[ 
https://issues.apache.org/jira/browse/SOLR-3116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13215604#comment-13215604
 ] 

Stefan Matheis (steffkes) commented on SOLR-3116:
-

Erick: SOLR-3155 is fine, i have about eight open todos on SOLR-2667 (mainly 
related to the Schema-Browser), but we could close this and continue in another 
ticket, if you'd like to.

 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-120224-crop-tree-area.patch, 
 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-2202) Money FieldType

2012-02-24 Thread Erik Hatcher (Commented) (JIRA) 

[ 
https://issues.apache.org/jira/browse/SOLR-2202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13215607#comment-13215607
 ] 

Erik Hatcher commented on SOLR-2202:


d) CurrencyField - that's more consistent with the likes of TextField, 
StrField, etc.  We have some new field types that suffix with Type, but 
they're the exception rather than the norm.  I prefer the term Currency over 
the less formal Money.

 Money FieldType
 ---

 Key: SOLR-2202
 URL: https://issues.apache.org/jira/browse/SOLR-2202
 Project: Solr
  Issue Type: New Feature
  Components: Schema and Analysis
Affects Versions: 1.5
Reporter: Greg Fodor
Assignee: Jan Høydahl
 Fix For: 3.6, 4.0

 Attachments: SOLR-2022-solr-3.patch, SOLR-2202-lucene-1.patch, 
 SOLR-2202-solr-1.patch, SOLR-2202-solr-2.patch, SOLR-2202-solr-4.patch, 
 SOLR-2202-solr-5.patch, SOLR-2202-solr-6.patch, SOLR-2202-solr-7.patch, 
 SOLR-2202-solr-8.patch, SOLR-2202-solr-9.patch, SOLR-2202.patch, 
 SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch


 Provides support for monetary values to Solr/Lucene with query-time currency 
 conversion. The following features are supported:
 - Point queries
 - Range quries
 - Sorting
 - Currency parsing by either currency code or symbol.
 - Symmetric  Asymmetric exchange rates. (Asymmetric exchange rates are 
 useful if there are fees associated with exchanging the currency.)
 At indexing time, money fields can be indexed in a native currency. For 
 example, if a product on an e-commerce site is listed in Euros, indexing the 
 price field as 1000,EUR will index it appropriately. By altering the 
 currency.xml file, the sorting and querying against Solr can take into 
 account fluctuations in currency exchange rates without having to re-index 
 the documents.
 The new money field type is a polyfield which indexes two fields, one which 
 contains the amount of the value and another which contains the currency code 
 or symbol. The currency metadata (names, symbols, codes, and exchange rates) 
 are expected to be in an xml file which is pointed to by the field type 
 declaration in the schema.xml.
 The current patch is factored such that Money utility functions and 
 configuration metadata lie in Lucene (see MoneyUtil and CurrencyConfig), 
 while the MoneyType and MoneyValueSource lie in Solr. This was meant to 
 mirror the work being done on the spacial field types.
 This patch will be getting used to power the international search 
 capabilities of the search engine at Etsy.
 Also see WIKI page: http://wiki.apache.org/solr/MoneyFieldType

--
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] [Updated] (SOLR-3149) Update obsolete schema.xml in example-DIH

2012-02-24 Thread Yusuke Yanbe (Updated) (JIRA) 

 [ 
https://issues.apache.org/jira/browse/SOLR-3149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yusuke Yanbe updated SOLR-3149:
---

Affects Version/s: 4.0

 Update obsolete schema.xml in example-DIH
 -

 Key: SOLR-3149
 URL: https://issues.apache.org/jira/browse/SOLR-3149
 Project: Solr
  Issue Type: Improvement
  Components: Schema and Analysis
Affects Versions: 3.5, 4.0
Reporter: Yusuke Yanbe
Priority: Minor
  Labels: dataimportHandler, documentaion, newbie
   Original Estimate: 3h
  Remaining Estimate: 3h

 The version of example/example-DIH/solr/db/conf/schema.xml is 1.1 (too old) 
 where example/solr/conf/schema.xml is 1.4. I believe that it is important to 
 keep all schema.xml up to date for newbies.
 The example/example-DIH/solr/db/conf/schema.xml will be referred as primary 
 hints for newbies because most of them may want to try import some data from 
 their preexisting DB or something first, referring [1]. Even 
 DataImportHandler tutorial itself can be done without problem, obsolete 
 schema.xml may confusing for them. 
 Typical difference of new and old schema.xml is existence of explanation of 
 *TrieField. Because old one's default types are solr.IntField or 
 solr.DateField and no mention of this. Consequently, when they try range 
 queries or boosting query based on old schema.xml, they may face unintended 
 slow response or error.
 [1] http://wiki.apache.org/solr/DataImportHandler#Full_Import_Example

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

[JENKINS-MAVEN] Lucene-Solr-Maven-trunk #400: POMs out of sync

2012-02-24 Thread Apache Jenkins Server 
Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/400/

1 tests failed.
REGRESSION:  org.apache.solr.cloud.BasicZkTest.testBasic

Error Message:
null

Stack Trace:
org.apache.solr.common.SolrException
at org.apache.solr.util.TestHarness.update(TestHarness.java:257)
at 
org.apache.solr.util.TestHarness.checkUpdateStatus(TestHarness.java:301)
at org.apache.solr.util.TestHarness.validateUpdate(TestHarness.java:271)
at org.apache.solr.SolrTestCaseJ4.checkUpdateU(SolrTestCaseJ4.java:387)
at org.apache.solr.SolrTestCaseJ4.assertU(SolrTestCaseJ4.java:366)
at org.apache.solr.cloud.BasicZkTest.testBasic(BasicZkTest.java:66)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at 
org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:707)
at 
org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:606)
at 
org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:511)
at 
org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:569)
at org.junit.rules.RunRules.evaluate(RunRules.java:18)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:165)
at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at 
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at 
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
at 
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
at 
org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175)
at 
org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68)
Caused by: java.lang.RuntimeException: No registered leader was found, 
collection:collection1 slice:shard2
at 
org.apache.solr.common.cloud.ZkStateReader.getLeaderProps(ZkStateReader.java:408)
at 
org.apache.solr.common.cloud.ZkStateReader.getLeaderProps(ZkStateReader.java:393)
at 
org.apache.solr.update.processor.DistributedUpdateProcessor.setupRequest(DistributedUpdateProcessor.java:156)
at 
org.apache.solr.update.processor.DistributedUpdateProcessor.processDelete(DistributedUpdateProcessor.java:470)
at org.apache.solr.handler.XMLLoader.processDelete(XMLLoader.java:235)
at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:166)
at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:79)
at

[jira] [Resolved] (SOLR-3160) Division by zero in StatsComponent with date field always missing

2012-02-24 Thread Erick Erickson (Resolved) (JIRA) 

 [ 
https://issues.apache.org/jira/browse/SOLR-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erick Erickson resolved SOLR-3160.
--

Resolution: Fixed

Trunk: r1293270
3x:1293272

Thanks Luca!

 Division by zero in StatsComponent with date field always missing
 -

 Key: SOLR-3160
 URL: https://issues.apache.org/jira/browse/SOLR-3160
 Project: Solr
  Issue Type: Bug
Affects Versions: 3.5
Reporter: Luca Cavanna
Assignee: Erick Erickson
Priority: Minor
 Fix For: 3.6, 4.0

 Attachments: SOLR-3160.patch


 Using the StatsComponent with a date field that never has a value you'll get 
 {code}
 java.lang.ArithmeticException: / by zero at 
 org.apache.solr.handler.component.DateStatsValues.addTypeSpecificStats 
 (StatsValuesFactory.java:384)
 {code}
 The problem is in this line of DateStatsValues:
 {code}
 res.add(mean, new Date(sum / count));
 {code}
 If count is 0 the division throws ArithmeticException because sum is long 
 here. This doesn't happen with NumericStatsValues because sum is double there 
 and the division result is Nan.
 By the way, the result of those divisions is not even included in the output 
 when count is 0 because of this condition in SimpleStats#getStatsFields:
 {code}
 if (isShard == true || (Long) stv.get(count)  0) {
 res.add(f, stv);
 } else {
 res.add(f, null);
 }
 {code}
 Therefore, it should never throw an exception!

--
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] [Updated] (SOLR-3156) Check for locks on startup

2012-02-24 Thread Luca Cavanna (Updated) (JIRA) 

 [ 
https://issues.apache.org/jira/browse/SOLR-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Luca Cavanna updated SOLR-3156:
---

Attachment: SOLR-3156.patch

Attached the first draft patch with a new test class. I've changed my mind a 
little bit and put the check together with the unlockOnStartup code. There we 
already know if the index is locked (IndexWriter#isLocked). If unlockOnStartup 
is enabled we remove the lock, otherwise we throw a LockObtainFailedException, 
the same exception we would have seen at the first document submission. What do 
you think guys? is this the right direction?

 Check for locks on startup
 --

 Key: SOLR-3156
 URL: https://issues.apache.org/jira/browse/SOLR-3156
 Project: Solr
  Issue Type: Improvement
Reporter: Luca Cavanna
 Attachments: SOLR-3156.patch


 When using simple or native lockType and the application server is not 
 shutdown properly (kill -9), you don't notice problems until someone tries to 
 add or delete a document. In fact, you get errors every time Solr opens a new 
 IndexWriter on the locked index. I'm aware of the unlockOnStartup option, 
 but I'd prefer to know and act properly when there's a lock, and I think it 
 would be better to know on startup, since Solr is not going to work properly.

--
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-3818) TestIndexWriterNRTIsCurrent failure

2012-02-24 Thread Michael McCandless (Commented) (JIRA) 

[ 
https://issues.apache.org/jira/browse/LUCENE-3818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13215665#comment-13215665
 ] 

Michael McCandless commented on LUCENE-3818:


+1

 TestIndexWriterNRTIsCurrent failure
 ---

 Key: LUCENE-3818
 URL: https://issues.apache.org/jira/browse/LUCENE-3818
 Project: Lucene - Java
  Issue Type: Bug
Reporter: Robert Muir
 Fix For: 4.0

 Attachments: LUCENE-3818.patch


 found by jenkins: 
 https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12492/
 make your computer busy (e.g. run tests in another checkout) then,
 ant test-core -Dtests.iter=100 -Dtestcase=TestIndexWriterNRTIsCurrent 
 -Dtestmethod=testIsCurrentWithThreads 
 -Dtests.seed=-78f6fa16b849cf27:382126da79c1e146:-d2cdec79e86e1b3 
 -Dtests.multiplier=3 -Dargs=-Dfile.encoding=ISO8859-1
 takes a few tries till it pops...
 {noformat}
 junit-sequential:
 [junit] Testsuite: org.apache.lucene.index.TestIndexWriterNRTIsCurrent
 [junit] Tests run: 100, Failures: 1, Errors: 1, Time elapsed: 277.818 sec
 [junit] 
 [junit] - Standard Output ---
 [junit] WARNING: you are using -Dtests.iter=n where n  1, not all tests 
 support this option.
 [junit] Some may crash or fail: this is not a bug.
 [junit] -  ---
 [junit] - Standard Error -
 [junit] NOTE: reproduce with: ant test 
 -Dtestcase=TestIndexWriterNRTIsCurrent -Dtestmethod=testIsCurrentWithThreads 
 -Dtests.seed=-78f6fa16b849cf27:382126da79c1e146:-d2cdec79e86e1b3 
 -Dtests.multiplier=3 -Dargs=-Dfile.encoding=ISO8859-1
 [junit] The following exceptions were thrown by threads:
 [junit] *** Thread: Lucene Merge Thread #17 ***
 [junit] org.apache.lucene.index.MergePolicy$MergeException: 
 java.lang.AssertionError
 [junit]   at 
 org.apache.lucene.index.ConcurrentMergeScheduler.handleMergeException(ConcurrentMergeScheduler.java:520)
 [junit]   at 
 org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:480)
 [junit] Caused by: java.lang.AssertionError
 [junit]   at 
 org.apache.lucene.index.IndexWriter$ReadersAndLiveDocs.initWritableLiveDocs(IndexWriter.java:580)
 [junit]   at 
 org.apache.lucene.index.IndexWriter.commitMergedDeletes(IndexWriter.java:3061)
 [junit]   at 
 org.apache.lucene.index.IndexWriter.commitMerge(IndexWriter.java:3137)
 [junit]   at 
 org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:3718)
 [junit]   at 
 org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3257)
 [junit]   at 
 org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:382)
 [junit]   at 
 org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:451)
 [junit] NOTE: reproduce with: ant test 
 -Dtestcase=TestIndexWriterNRTIsCurrent -Dtestmethod=testIsCurrentWithThreads 
 -Dtests.seed=-78f6fa16b849cf27:382126da79c1e146:-d2cdec79e86e1b3 
 -Dtests.multiplier=3 -Dargs=-Dfile.encoding=ISO8859-1
 [junit] NOTE: reproduce with: ant test 
 -Dtestcase=TestIndexWriterNRTIsCurrent -Dtestmethod=testIsCurrentWithThreads 
 -Dtests.seed=-78f6fa16b849cf27:382126da79c1e146:-d2cdec79e86e1b3 
 -Dtests.multiplier=3 -Dargs=-Dfile.encoding=ISO8859-1
 [junit] NOTE: test params are: codec=Lucene40: 
 {id=MockFixedIntBlock(blockSize=525)}, sim=DefaultSimilarity, locale=es_PY, 
 timezone=Africa/Luanda
 [junit] NOTE: all tests run in this JVM:
 [junit] [TestIndexWriterNRTIsCurrent]
 [junit] NOTE: Linux 3.0.0-14-generic amd64/Sun Microsystems Inc. 1.6.0_24 
 (64-bit)/cpus=8,threads=1,free=74907448,total=255787008
 [junit] -  ---
 [junit] Testcase: 
 testIsCurrentWithThreads(org.apache.lucene.index.TestIndexWriterNRTIsCurrent):
   FAILED
 [junit] info=_qx(4.0):C1/1 isn't live
 [junit] junit.framework.AssertionFailedError: info=_qx(4.0):C1/1 isn't 
 live
 [junit]   at 
 org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:165)
 [junit]   at 
 org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
 [junit]   at 
 org.apache.lucene.index.IndexWriter$ReaderPool.infoIsLive(IndexWriter.java:663)
 [junit]   at 
 org.apache.lucene.index.IndexWriter$ReaderPool.dropAll(IndexWriter.java:717)
 [junit]   at 
 org.apache.lucene.index.IndexWriter.closeInternal(IndexWriter.java:1136)
 [junit]   at 
 org.apache.lucene.index.IndexWriter.close(IndexWriter.java:1069)
 [junit]   at 
 org.apache.lucene.index.IndexWriter.close(IndexWriter.java:1033)
 [junit]   at

[jira] [Commented] (LUCENE-3818) TestIndexWriterNRTIsCurrent failure

2012-02-24 Thread Robert Muir (Commented) (JIRA) 

[ 
https://issues.apache.org/jira/browse/LUCENE-3818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13215667#comment-13215667
 ] 

Robert Muir commented on LUCENE-3818:
-

OK I'll commit Simon's patch. Thanks Simon, and thanks Mike for taking a look!

 TestIndexWriterNRTIsCurrent failure
 ---

 Key: LUCENE-3818
 URL: https://issues.apache.org/jira/browse/LUCENE-3818
 Project: Lucene - Java
  Issue Type: Bug
Reporter: Robert Muir
 Fix For: 4.0

 Attachments: LUCENE-3818.patch


 found by jenkins: 
 https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12492/
 make your computer busy (e.g. run tests in another checkout) then,
 ant test-core -Dtests.iter=100 -Dtestcase=TestIndexWriterNRTIsCurrent 
 -Dtestmethod=testIsCurrentWithThreads 
 -Dtests.seed=-78f6fa16b849cf27:382126da79c1e146:-d2cdec79e86e1b3 
 -Dtests.multiplier=3 -Dargs=-Dfile.encoding=ISO8859-1
 takes a few tries till it pops...
 {noformat}
 junit-sequential:
 [junit] Testsuite: org.apache.lucene.index.TestIndexWriterNRTIsCurrent
 [junit] Tests run: 100, Failures: 1, Errors: 1, Time elapsed: 277.818 sec
 [junit] 
 [junit] - Standard Output ---
 [junit] WARNING: you are using -Dtests.iter=n where n  1, not all tests 
 support this option.
 [junit] Some may crash or fail: this is not a bug.
 [junit] -  ---
 [junit] - Standard Error -
 [junit] NOTE: reproduce with: ant test 
 -Dtestcase=TestIndexWriterNRTIsCurrent -Dtestmethod=testIsCurrentWithThreads 
 -Dtests.seed=-78f6fa16b849cf27:382126da79c1e146:-d2cdec79e86e1b3 
 -Dtests.multiplier=3 -Dargs=-Dfile.encoding=ISO8859-1
 [junit] The following exceptions were thrown by threads:
 [junit] *** Thread: Lucene Merge Thread #17 ***
 [junit] org.apache.lucene.index.MergePolicy$MergeException: 
 java.lang.AssertionError
 [junit]   at 
 org.apache.lucene.index.ConcurrentMergeScheduler.handleMergeException(ConcurrentMergeScheduler.java:520)
 [junit]   at 
 org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:480)
 [junit] Caused by: java.lang.AssertionError
 [junit]   at 
 org.apache.lucene.index.IndexWriter$ReadersAndLiveDocs.initWritableLiveDocs(IndexWriter.java:580)
 [junit]   at 
 org.apache.lucene.index.IndexWriter.commitMergedDeletes(IndexWriter.java:3061)
 [junit]   at 
 org.apache.lucene.index.IndexWriter.commitMerge(IndexWriter.java:3137)
 [junit]   at 
 org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:3718)
 [junit]   at 
 org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3257)
 [junit]   at 
 org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:382)
 [junit]   at 
 org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:451)
 [junit] NOTE: reproduce with: ant test 
 -Dtestcase=TestIndexWriterNRTIsCurrent -Dtestmethod=testIsCurrentWithThreads 
 -Dtests.seed=-78f6fa16b849cf27:382126da79c1e146:-d2cdec79e86e1b3 
 -Dtests.multiplier=3 -Dargs=-Dfile.encoding=ISO8859-1
 [junit] NOTE: reproduce with: ant test 
 -Dtestcase=TestIndexWriterNRTIsCurrent -Dtestmethod=testIsCurrentWithThreads 
 -Dtests.seed=-78f6fa16b849cf27:382126da79c1e146:-d2cdec79e86e1b3 
 -Dtests.multiplier=3 -Dargs=-Dfile.encoding=ISO8859-1
 [junit] NOTE: test params are: codec=Lucene40: 
 {id=MockFixedIntBlock(blockSize=525)}, sim=DefaultSimilarity, locale=es_PY, 
 timezone=Africa/Luanda
 [junit] NOTE: all tests run in this JVM:
 [junit] [TestIndexWriterNRTIsCurrent]
 [junit] NOTE: Linux 3.0.0-14-generic amd64/Sun Microsystems Inc. 1.6.0_24 
 (64-bit)/cpus=8,threads=1,free=74907448,total=255787008
 [junit] -  ---
 [junit] Testcase: 
 testIsCurrentWithThreads(org.apache.lucene.index.TestIndexWriterNRTIsCurrent):
   FAILED
 [junit] info=_qx(4.0):C1/1 isn't live
 [junit] junit.framework.AssertionFailedError: info=_qx(4.0):C1/1 isn't 
 live
 [junit]   at 
 org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:165)
 [junit]   at 
 org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
 [junit]   at 
 org.apache.lucene.index.IndexWriter$ReaderPool.infoIsLive(IndexWriter.java:663)
 [junit]   at 
 org.apache.lucene.index.IndexWriter$ReaderPool.dropAll(IndexWriter.java:717)
 [junit]   at 
 org.apache.lucene.index.IndexWriter.closeInternal(IndexWriter.java:1136)
 [junit]   at 
 org.apache.lucene.index.IndexWriter.close(IndexWriter.java:1069)
 [junit]   at 
 org.apache.lucene.index.IndexWriter.close(IndexWriter.java:1033)
 [junit]   at

[jira] [Resolved] (LUCENE-3818) TestIndexWriterNRTIsCurrent failure

2012-02-24 Thread Robert Muir (Resolved) (JIRA) 

 [ 
https://issues.apache.org/jira/browse/LUCENE-3818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Muir resolved LUCENE-3818.
-

Resolution: Fixed

 TestIndexWriterNRTIsCurrent failure
 ---

 Key: LUCENE-3818
 URL: https://issues.apache.org/jira/browse/LUCENE-3818
 Project: Lucene - Java
  Issue Type: Bug
Reporter: Robert Muir
 Fix For: 4.0

 Attachments: LUCENE-3818.patch


 found by jenkins: 
 https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12492/
 make your computer busy (e.g. run tests in another checkout) then,
 ant test-core -Dtests.iter=100 -Dtestcase=TestIndexWriterNRTIsCurrent 
 -Dtestmethod=testIsCurrentWithThreads 
 -Dtests.seed=-78f6fa16b849cf27:382126da79c1e146:-d2cdec79e86e1b3 
 -Dtests.multiplier=3 -Dargs=-Dfile.encoding=ISO8859-1
 takes a few tries till it pops...
 {noformat}
 junit-sequential:
 [junit] Testsuite: org.apache.lucene.index.TestIndexWriterNRTIsCurrent
 [junit] Tests run: 100, Failures: 1, Errors: 1, Time elapsed: 277.818 sec
 [junit] 
 [junit] - Standard Output ---
 [junit] WARNING: you are using -Dtests.iter=n where n  1, not all tests 
 support this option.
 [junit] Some may crash or fail: this is not a bug.
 [junit] -  ---
 [junit] - Standard Error -
 [junit] NOTE: reproduce with: ant test 
 -Dtestcase=TestIndexWriterNRTIsCurrent -Dtestmethod=testIsCurrentWithThreads 
 -Dtests.seed=-78f6fa16b849cf27:382126da79c1e146:-d2cdec79e86e1b3 
 -Dtests.multiplier=3 -Dargs=-Dfile.encoding=ISO8859-1
 [junit] The following exceptions were thrown by threads:
 [junit] *** Thread: Lucene Merge Thread #17 ***
 [junit] org.apache.lucene.index.MergePolicy$MergeException: 
 java.lang.AssertionError
 [junit]   at 
 org.apache.lucene.index.ConcurrentMergeScheduler.handleMergeException(ConcurrentMergeScheduler.java:520)
 [junit]   at 
 org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:480)
 [junit] Caused by: java.lang.AssertionError
 [junit]   at 
 org.apache.lucene.index.IndexWriter$ReadersAndLiveDocs.initWritableLiveDocs(IndexWriter.java:580)
 [junit]   at 
 org.apache.lucene.index.IndexWriter.commitMergedDeletes(IndexWriter.java:3061)
 [junit]   at 
 org.apache.lucene.index.IndexWriter.commitMerge(IndexWriter.java:3137)
 [junit]   at 
 org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:3718)
 [junit]   at 
 org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3257)
 [junit]   at 
 org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:382)
 [junit]   at 
 org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:451)
 [junit] NOTE: reproduce with: ant test 
 -Dtestcase=TestIndexWriterNRTIsCurrent -Dtestmethod=testIsCurrentWithThreads 
 -Dtests.seed=-78f6fa16b849cf27:382126da79c1e146:-d2cdec79e86e1b3 
 -Dtests.multiplier=3 -Dargs=-Dfile.encoding=ISO8859-1
 [junit] NOTE: reproduce with: ant test 
 -Dtestcase=TestIndexWriterNRTIsCurrent -Dtestmethod=testIsCurrentWithThreads 
 -Dtests.seed=-78f6fa16b849cf27:382126da79c1e146:-d2cdec79e86e1b3 
 -Dtests.multiplier=3 -Dargs=-Dfile.encoding=ISO8859-1
 [junit] NOTE: test params are: codec=Lucene40: 
 {id=MockFixedIntBlock(blockSize=525)}, sim=DefaultSimilarity, locale=es_PY, 
 timezone=Africa/Luanda
 [junit] NOTE: all tests run in this JVM:
 [junit] [TestIndexWriterNRTIsCurrent]
 [junit] NOTE: Linux 3.0.0-14-generic amd64/Sun Microsystems Inc. 1.6.0_24 
 (64-bit)/cpus=8,threads=1,free=74907448,total=255787008
 [junit] -  ---
 [junit] Testcase: 
 testIsCurrentWithThreads(org.apache.lucene.index.TestIndexWriterNRTIsCurrent):
   FAILED
 [junit] info=_qx(4.0):C1/1 isn't live
 [junit] junit.framework.AssertionFailedError: info=_qx(4.0):C1/1 isn't 
 live
 [junit]   at 
 org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:165)
 [junit]   at 
 org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
 [junit]   at 
 org.apache.lucene.index.IndexWriter$ReaderPool.infoIsLive(IndexWriter.java:663)
 [junit]   at 
 org.apache.lucene.index.IndexWriter$ReaderPool.dropAll(IndexWriter.java:717)
 [junit]   at 
 org.apache.lucene.index.IndexWriter.closeInternal(IndexWriter.java:1136)
 [junit]   at 
 org.apache.lucene.index.IndexWriter.close(IndexWriter.java:1069)
 [junit]   at 
 org.apache.lucene.index.IndexWriter.close(IndexWriter.java:1033)
 [junit]   at 
 org.apache.lucene.index.TestIndexWriterNRTIsCurrent.testIsCurrentWithThreads(TestIndexWriterNRTIsCurrent.java:68)
 [junit]   at

[jira] [Reopened] (SOLR-2901) Upgrade Solr to Tika 1.0

2012-02-24 Thread Reopened 

 [ 
https://issues.apache.org/jira/browse/SOLR-2901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Høydahl reopened SOLR-2901:
---


Re-opening, as the {{jdom-1.0.jar}} must also be included, as a dependency for 
{{Rome}} used by {{FeedParser}}

 Upgrade Solr to Tika 1.0
 

 Key: SOLR-2901
 URL: https://issues.apache.org/jira/browse/SOLR-2901
 Project: Solr
  Issue Type: Improvement
  Components: contrib - LangId, contrib - Solr Cell (Tika extraction)
Reporter: Jan Høydahl
Assignee: Jan Høydahl
 Fix For: 3.6, 4.0

 Attachments: SOLR-2901.patch, SOLR-2901.patch, SOLR-2901.patch, 
 SOLR-2901.patch, SOLR-2901.patch, SOLR-2901.patch


 Tika 1.0 was released November 7th and includes a number of improvements: 
 http://tika.apache.org/1.0/

--
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] [Updated] (SOLR-2202) Money FieldType

2012-02-24 Thread Andrew Morrison (Updated) (JIRA) 

 [ 
https://issues.apache.org/jira/browse/SOLR-2202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Morrison updated SOLR-2202:
--

Attachment: SOLR-2202-solr-10.patch

Hello Jan.

I've attached a patch against 
https://svn.apache.org/repos/asf/lucene/dev/trunk@1220795 that adds the ability 
to do range faceting. I'd be happy to move this to another ticket and clean it 
up.

 Money FieldType
 ---

 Key: SOLR-2202
 URL: https://issues.apache.org/jira/browse/SOLR-2202
 Project: Solr
  Issue Type: New Feature
  Components: Schema and Analysis
Affects Versions: 1.5
Reporter: Greg Fodor
Assignee: Jan Høydahl
 Fix For: 3.6, 4.0

 Attachments: SOLR-2022-solr-3.patch, SOLR-2202-lucene-1.patch, 
 SOLR-2202-solr-1.patch, SOLR-2202-solr-10.patch, SOLR-2202-solr-2.patch, 
 SOLR-2202-solr-4.patch, SOLR-2202-solr-5.patch, SOLR-2202-solr-6.patch, 
 SOLR-2202-solr-7.patch, SOLR-2202-solr-8.patch, SOLR-2202-solr-9.patch, 
 SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch


 Provides support for monetary values to Solr/Lucene with query-time currency 
 conversion. The following features are supported:
 - Point queries
 - Range quries
 - Sorting
 - Currency parsing by either currency code or symbol.
 - Symmetric  Asymmetric exchange rates. (Asymmetric exchange rates are 
 useful if there are fees associated with exchanging the currency.)
 At indexing time, money fields can be indexed in a native currency. For 
 example, if a product on an e-commerce site is listed in Euros, indexing the 
 price field as 1000,EUR will index it appropriately. By altering the 
 currency.xml file, the sorting and querying against Solr can take into 
 account fluctuations in currency exchange rates without having to re-index 
 the documents.
 The new money field type is a polyfield which indexes two fields, one which 
 contains the amount of the value and another which contains the currency code 
 or symbol. The currency metadata (names, symbols, codes, and exchange rates) 
 are expected to be in an xml file which is pointed to by the field type 
 declaration in the schema.xml.
 The current patch is factored such that Money utility functions and 
 configuration metadata lie in Lucene (see MoneyUtil and CurrencyConfig), 
 while the MoneyType and MoneyValueSource lie in Solr. This was meant to 
 mirror the work being done on the spacial field types.
 This patch will be getting used to power the international search 
 capabilities of the search engine at Etsy.
 Also see WIKI page: http://wiki.apache.org/solr/MoneyFieldType

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

customization for SolrRequestParsers

2012-02-24 Thread Mikhail Khludnev 
Hello,

I see that some sort of customization was expected for SolrRequestParsers.
http://svn.apache.org/viewvc/lucene/dev/trunk/solr/core/src/java/org/apache/solr/servlet/SolrRequestParsers.java?view=markup

line
 97 // I don't see a need to have this publicly configured just yet
and
 111 // TODO -- in the future, we could pick a different parser based on
the request

I need to plug some code which will parse request and add additional stuff
iinto req.context. I'd be happy to contribute it, but want to know what was
an intention.

Thanks in advance

-- 
Sincerely yours
Mikhail Khludnev
Lucid Certified
Apache Lucene/Solr Developer
Grid Dynamics

http://www.griddynamics.com
 mkhlud...@griddynamics.com

[jira] [Resolved] (SOLR-2901) Upgrade Solr to Tika 1.0

2012-02-24 Thread Resolved 

 [ 
https://issues.apache.org/jira/browse/SOLR-2901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Høydahl resolved SOLR-2901.
---

Resolution: Fixed

Checked in jdom-1.0.jar with LICENSE and NOTICE files in both 3.x and trunk.

 Upgrade Solr to Tika 1.0
 

 Key: SOLR-2901
 URL: https://issues.apache.org/jira/browse/SOLR-2901
 Project: Solr
  Issue Type: Improvement
  Components: contrib - LangId, contrib - Solr Cell (Tika extraction)
Reporter: Jan Høydahl
Assignee: Jan Høydahl
 Fix For: 3.6, 4.0

 Attachments: SOLR-2901.patch, SOLR-2901.patch, SOLR-2901.patch, 
 SOLR-2901.patch, SOLR-2901.patch, SOLR-2901.patch


 Tika 1.0 was released November 7th and includes a number of improvements: 
 http://tika.apache.org/1.0/

--
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-3767) Explore streaming Viterbi search in Kuromoji

2012-02-24 Thread Michael McCandless (Commented) (JIRA) 

[ 
https://issues.apache.org/jira/browse/LUCENE-3767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13215713#comment-13215713
 ] 

Michael McCandless commented on LUCENE-3767:


{quote}
bq. I left the default mode as Mode.SEARCH... maybe if we can somehow run some 
relevance tests we can make the default SEARCH_WITH_COMPOUNDS. But it'd also be 
tricky at query time...

Mike, could you share some details on any query-time trickiness here? Are you 
thinking about composing a query with both the compound and its 
parts/decompounds? Thanks.
{quote}

Sorry, I was wrong about this!  Apparently QueryParser works fine if
the analyzer produces a graph (it just creates a
somewhat-scary-yet-works MultiPhraseQuery).

So I think we have no issue at query time... and I guess we should
default to SEARCH_WITH_COMPOUNDS.

I agree we can explore better tweaking the decompounding in a new
issue.


 Explore streaming Viterbi search in Kuromoji
 

 Key: LUCENE-3767
 URL: https://issues.apache.org/jira/browse/LUCENE-3767
 Project: Lucene - Java
  Issue Type: Improvement
  Components: modules/analysis
Reporter: Michael McCandless
Assignee: Michael McCandless
 Fix For: 3.6, 4.0

 Attachments: LUCENE-3767.patch, LUCENE-3767.patch, LUCENE-3767.patch, 
 compound_diffs.txt


 I've been playing with the idea of changing the Kuromoji viterbi
 search to be 2 passes (intersect, backtrace) instead of 4 passes
 (break into sentences, intersect, score, backtrace)... this is very
 much a work in progress, so I'm just getting my current state up.
 It's got tons of nocommits, doesn't properly handle the user dict nor
 extended modes yet, etc.
 One thing I'm playing with is to add a double backtrace for the long
 compound tokens, ie, instead of penalizing these tokens so that
 shorter tokens are picked, leave the scores unchanged but on backtrace
 take that penalty and use it as a threshold for a 2nd best
 segmentation...

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

Re: svn commit: r1293309 - in /lucene/dev/trunk/solr/contrib/extraction/lib: jdom-1.0-LICENSE-ASL_LIKE.txt jdom-1.0-NOTICE.txt jdom-1.0.jar

2012-02-24 Thread Sami Siren 
trunk ant clean test currently fails when run from /solr because of:

validate:
 [echo] License check under:
/data3/jenkins_home/jobs/lucene-solr_core/workspace/solr
 [licenses] MISSING LICENSE for the following file:
 [licenses]   
/data3/jenkins_home/jobs/lucene-solr_core/workspace/solr/contrib/extraction/lib/jdom-1.0.jar

--
 Sami Siren

On Fri, Feb 24, 2012 at 6:00 PM,  jan...@apache.org wrote:
 Author: janhoy
 Date: Fri Feb 24 16:00:14 2012
 New Revision: 1293309

 URL: http://svn.apache.org/viewvc?rev=1293309view=rev
 Log:
 SOLR-2901: Added jdom-1.0.jar

 Added:
    lucene/dev/trunk/solr/contrib/extraction/lib/jdom-1.0-LICENSE-ASL_LIKE.txt 
   (with props)
    lucene/dev/trunk/solr/contrib/extraction/lib/jdom-1.0-NOTICE.txt   (with 
 props)
    lucene/dev/trunk/solr/contrib/extraction/lib/jdom-1.0.jar   (with props)

 Added: 
 lucene/dev/trunk/solr/contrib/extraction/lib/jdom-1.0-LICENSE-ASL_LIKE.txt
 URL: 
 http://svn.apache.org/viewvc/lucene/dev/trunk/solr/contrib/extraction/lib/jdom-1.0-LICENSE-ASL_LIKE.txt?rev=1293309view=auto
 ==
 --- 
 lucene/dev/trunk/solr/contrib/extraction/lib/jdom-1.0-LICENSE-ASL_LIKE.txt 
 (added)
 +++ 
 lucene/dev/trunk/solr/contrib/extraction/lib/jdom-1.0-LICENSE-ASL_LIKE.txt 
 Fri Feb 24 16:00:14 2012
 @@ -0,0 +1,56 @@
 +/*--
 +
 + $Id: LICENSE.txt,v 1.11 2004/02/06 09:32:57 jhunter Exp $
 +
 + Copyright (C) 2000-2004 Jason Hunter  Brett McLaughlin.
 + All rights reserved.
 +
 + Redistribution and use in source and binary forms, with or without
 + modification, are permitted provided that the following conditions
 + are met:
 +
 + 1. Redistributions of source code must retain the above copyright
 +    notice, this list of conditions, and the following disclaimer.
 +
 + 2. Redistributions in binary form must reproduce the above copyright
 +    notice, this list of conditions, and the disclaimer that follows
 +    these conditions in the documentation and/or other materials
 +    provided with the distribution.
 +
 + 3. The name JDOM must not be used to endorse or promote products
 +    derived from this software without prior written permission.  For
 +    written permission, please contact request_AT_jdom_DOT_org.
 +
 + 4. Products derived from this software may not be called JDOM, nor
 +    may JDOM appear in their name, without prior written permission
 +    from the JDOM Project Management request_AT_jdom_DOT_org.
 +
 + In addition, we request (but do not require) that you include in the
 + end-user documentation provided with the redistribution and/or in the
 + software itself an acknowledgement equivalent to the following:
 +     This product includes software developed by the
 +      JDOM Project (http://www.jdom.org/).
 + Alternatively, the acknowledgment may be graphical using the logos
 + available at http://www.jdom.org/images/logos.
 +
 + THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
 + WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
 + OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
 + DISCLAIMED.  IN NO EVENT SHALL THE JDOM AUTHORS OR THE PROJECT
 + CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
 + SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
 + LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
 + USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
 + ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
 + OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
 + OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 + SUCH DAMAGE.
 +
 + This software consists of voluntary contributions made by many
 + individuals on behalf of the JDOM Project and was originally
 + created by Jason Hunter jhunter_AT_jdom_DOT_org and
 + Brett McLaughlin brett_AT_jdom_DOT_org.  For more information
 + on the JDOM Project, please see http://www.jdom.org/.
 +
 + */
 +

 Added: lucene/dev/trunk/solr/contrib/extraction/lib/jdom-1.0-NOTICE.txt
 URL: 
 http://svn.apache.org/viewvc/lucene/dev/trunk/solr/contrib/extraction/lib/jdom-1.0-NOTICE.txt?rev=1293309view=auto
 ==
 --- lucene/dev/trunk/solr/contrib/extraction/lib/jdom-1.0-NOTICE.txt (added)
 +++ lucene/dev/trunk/solr/contrib/extraction/lib/jdom-1.0-NOTICE.txt Fri Feb 
 24 16:00:14 2012
 @@ -0,0 +1,6 @@
 +Copyright (C) 2000-2004 Jason Hunter  Brett McLaughlin.
 +All rights reserved.
 +
 +JDOM is available under an Apache-style open source license, with the 
 acknowledgment clause removed.
 +This license is among the least restrictive license available, enabling 
 developers to use JDOM in
 +creating new products without requiring them to release their own products 
 as open source.
 \ No newline at end of file

 Added: lucene/dev/trunk/solr/contrib/extraction/lib/jdom-1.0.jar
 URL:

[JENKINS] Lucene-Solr-tests-only-3.x-java7 - Build # 1827 - Failure

2012-02-24 Thread Apache Jenkins Server 
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x-java7/1827/

All tests passed

Build Log (for compile errors):
[...truncated 13996 lines...]



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Solr-trunk - Build # 1771 - Still Failing

2012-02-24 Thread Apache Jenkins Server 
Build: https://builds.apache.org/job/Solr-trunk/1771/

No tests ran.

Build Log (for compile errors):
[...truncated 6982 lines...]



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-tests-only-trunk - Build # 12506 - Failure

2012-02-24 Thread Apache Jenkins Server 
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12506/

No tests ran.

Build Log (for compile errors):
[...truncated 632 lines...]



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: svn commit: r1293309 - in /lucene/dev/trunk/solr/contrib/extraction/lib: jdom-1.0-LICENSE-ASL_LIKE.txt jdom-1.0-NOTICE.txt jdom-1.0.jar

2012-02-24 Thread Mark Miller 
It's because ASL_LIKE is not a valid license type. Looking at the license, this 
is not the right type IMO anyway.

On Feb 24, 2012, at 11:29 AM, Sami Siren wrote:

 trunk ant clean test currently fails when run from /solr because of:
 
 validate:
 [echo] License check under:
 /data3/jenkins_home/jobs/lucene-solr_core/workspace/solr
 [licenses] MISSING LICENSE for the following file:
 [licenses]   
 /data3/jenkins_home/jobs/lucene-solr_core/workspace/solr/contrib/extraction/lib/jdom-1.0.jar
 
 --
 Sami Siren
 
 On Fri, Feb 24, 2012 at 6:00 PM,  jan...@apache.org wrote:
 Author: janhoy
 Date: Fri Feb 24 16:00:14 2012
 New Revision: 1293309
 
 URL: http://svn.apache.org/viewvc?rev=1293309view=rev
 Log:
 SOLR-2901: Added jdom-1.0.jar
 
 Added:

 lucene/dev/trunk/solr/contrib/extraction/lib/jdom-1.0-LICENSE-ASL_LIKE.txt   
 (with props)
lucene/dev/trunk/solr/contrib/extraction/lib/jdom-1.0-NOTICE.txt   (with 
 props)
lucene/dev/trunk/solr/contrib/extraction/lib/jdom-1.0.jar   (with props)
 
 Added: 
 lucene/dev/trunk/solr/contrib/extraction/lib/jdom-1.0-LICENSE-ASL_LIKE.txt
 URL: 
 http://svn.apache.org/viewvc/lucene/dev/trunk/solr/contrib/extraction/lib/jdom-1.0-LICENSE-ASL_LIKE.txt?rev=1293309view=auto
 ==
 --- 
 lucene/dev/trunk/solr/contrib/extraction/lib/jdom-1.0-LICENSE-ASL_LIKE.txt 
 (added)
 +++ 
 lucene/dev/trunk/solr/contrib/extraction/lib/jdom-1.0-LICENSE-ASL_LIKE.txt 
 Fri Feb 24 16:00:14 2012
 @@ -0,0 +1,56 @@
 +/*--
 +
 + $Id: LICENSE.txt,v 1.11 2004/02/06 09:32:57 jhunter Exp $
 +
 + Copyright (C) 2000-2004 Jason Hunter  Brett McLaughlin.
 + All rights reserved.
 +
 + Redistribution and use in source and binary forms, with or without
 + modification, are permitted provided that the following conditions
 + are met:
 +
 + 1. Redistributions of source code must retain the above copyright
 +notice, this list of conditions, and the following disclaimer.
 +
 + 2. Redistributions in binary form must reproduce the above copyright
 +notice, this list of conditions, and the disclaimer that follows
 +these conditions in the documentation and/or other materials
 +provided with the distribution.
 +
 + 3. The name JDOM must not be used to endorse or promote products
 +derived from this software without prior written permission.  For
 +written permission, please contact request_AT_jdom_DOT_org.
 +
 + 4. Products derived from this software may not be called JDOM, nor
 +may JDOM appear in their name, without prior written permission
 +from the JDOM Project Management request_AT_jdom_DOT_org.
 +
 + In addition, we request (but do not require) that you include in the
 + end-user documentation provided with the redistribution and/or in the
 + software itself an acknowledgement equivalent to the following:
 + This product includes software developed by the
 +  JDOM Project (http://www.jdom.org/).
 + Alternatively, the acknowledgment may be graphical using the logos
 + available at http://www.jdom.org/images/logos.
 +
 + THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
 + WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
 + OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
 + DISCLAIMED.  IN NO EVENT SHALL THE JDOM AUTHORS OR THE PROJECT
 + CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
 + SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
 + LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
 + USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
 + ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
 + OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
 + OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 + SUCH DAMAGE.
 +
 + This software consists of voluntary contributions made by many
 + individuals on behalf of the JDOM Project and was originally
 + created by Jason Hunter jhunter_AT_jdom_DOT_org and
 + Brett McLaughlin brett_AT_jdom_DOT_org.  For more information
 + on the JDOM Project, please see http://www.jdom.org/.
 +
 + */
 +
 
 Added: lucene/dev/trunk/solr/contrib/extraction/lib/jdom-1.0-NOTICE.txt
 URL: 
 http://svn.apache.org/viewvc/lucene/dev/trunk/solr/contrib/extraction/lib/jdom-1.0-NOTICE.txt?rev=1293309view=auto
 ==
 --- lucene/dev/trunk/solr/contrib/extraction/lib/jdom-1.0-NOTICE.txt (added)
 +++ lucene/dev/trunk/solr/contrib/extraction/lib/jdom-1.0-NOTICE.txt Fri Feb 
 24 16:00:14 2012
 @@ -0,0 +1,6 @@
 +Copyright (C) 2000-2004 Jason Hunter  Brett McLaughlin.
 +All rights reserved.
 +
 +JDOM is available under an Apache-style open source license, with the 
 acknowledgment clause removed.
 +This license is among the least restrictive license available, enabling 
 developers to use JDOM in
 +creating new products without requiring them to release

[jira] [Updated] (SOLR-3080) We should consider removing shard info from Zk when you explicitly unload a SolrCore.

2012-02-24 Thread Yonik Seeley (Updated) (JIRA) 

 [ 
https://issues.apache.org/jira/browse/SOLR-3080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yonik Seeley updated SOLR-3080:
---

Attachment: SOLR-3080_smaller_sync.patch

We currently synchronize on coreStates when we publish the info to zookeeper.  
This would also block any reads or other changes in the meantime.

Here's the first approach that came to mind to handle not blocking 
reads/updates while publishing.  Anyone have an easier way?

 We should consider removing shard info from Zk when you explicitly unload a 
 SolrCore.
 -

 Key: SOLR-3080
 URL: https://issues.apache.org/jira/browse/SOLR-3080
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Mark Miller
Assignee: Sami Siren
Priority: Minor
 Fix For: 4.0

 Attachments: SOLR-3080.patch, SOLR-3080.patch, 
 SOLR-3080_smaller_sync.patch




--
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-3080) We should consider removing shard info from Zk when you explicitly unload a SolrCore.

2012-02-24 Thread Sami Siren (Commented) (JIRA) 

[ 
https://issues.apache.org/jira/browse/SOLR-3080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13215760#comment-13215760
 ] 

Sami Siren commented on SOLR-3080:
--

+1, nice!

 We should consider removing shard info from Zk when you explicitly unload a 
 SolrCore.
 -

 Key: SOLR-3080
 URL: https://issues.apache.org/jira/browse/SOLR-3080
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Mark Miller
Assignee: Sami Siren
Priority: Minor
 Fix For: 4.0

 Attachments: SOLR-3080.patch, SOLR-3080.patch, 
 SOLR-3080_smaller_sync.patch




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

[JENKINS] Lucene-Solr-tests-only-3.x - Build # 12517 - Failure

2012-02-24 Thread Apache Jenkins Server 
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x/12517/

All tests passed

Build Log (for compile errors):
[...truncated 13975 lines...]



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Spawning an additional thread in Solr custom SearchComponent - best practice?

2012-02-24 Thread cwalls 
Hi,

I've been developing a custom SearchComponent for Solr, which essentially is
making a REST call to an internal service we have to get a list of Ids to
use to build a FieldCacheTermsFilter. I'm making the call asynchronously
during the prepare call, then getting the result during the process call, to
try and keep the overall response time down. I've got it working
functionally, but I'm not sure of the best practice for making the call in a
separate thread. As it stands I'm implementing Runnable, but should I be
looking at using a thread pool instead? Specifically, is there an
ExecutorService already in use by Solr/Lucene (or Tomcat?) I can use to
execute a FutureTask or similar?

Apologies if this is quite a basic question, I'm not too familiar with Java,
I had a search around and couldn't find anything specific to this, and I
think the solution may or may not be Solr specific. Any help is much
appreciated.

Thanks,
Connor

--
View this message in context: 
http://lucene.472066.n3.nabble.com/Spawning-an-additional-thread-in-Solr-custom-SearchComponent-best-practice-tp3773277p3773277.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-tests-only-3.x - Build # 12518 - Still Failing

2012-02-24 Thread Apache Jenkins Server 
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x/12518/

All tests passed

Build Log (for compile errors):
[...truncated 13951 lines...]



-
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

2012-02-24 Thread David Smiley (Commented) (JIRA) 

[ 
https://issues.apache.org/jira/browse/SOLR-1233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13215810#comment-13215810
 ] 

David Smiley commented on SOLR-1233:


I'm very surprised that I am the only one commenting on this issue. FWIW, in 
other private communication channels, I know there is support for what I want 
here among at least some committers.

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.

 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

[JENKINS] Lucene-Solr-tests-only-3.x-java7 - Build # 1828 - Still Failing

2012-02-24 Thread Apache Jenkins Server 
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x-java7/1828/

All tests passed

Build Log (for compile errors):
[...truncated 13947 lines...]



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-3161) Use of 'qt' should be restricted to searching and should not start with a '/'

2012-02-24 Thread David Smiley (Created) (JIRA) 
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-1233) Remove restriction that /select cannot be used for /-prefixed request handlers via qt

2012-02-24 Thread Ryan McKinley (Commented) (JIRA) 

[ 
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-1233) Remove restriction that /select cannot be used for /-prefixed request handlers via qt

2012-02-24 Thread David Smiley (Commented) (JIRA) 

[ 
https://issues.apache.org/jira/browse/SOLR-1233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13215820#comment-13215820
 ] 

David Smiley commented on SOLR-1233:


I decided to move this discussion to a new issue: SOLR-3161
Please comment there, not here.

 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 '/'

2012-02-24 Thread David Smiley (Commented) (JIRA) 

[ 
https://issues.apache.org/jira/browse/SOLR-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13215823#comment-13215823
 ] 

David Smiley commented on SOLR-3161:


For some context on the security ramifications, see my comment on the linked 
issue: 
https://issues.apache.org/jira/browse/SOLR-1233?focusedCommentId=13169425page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13169425

 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

Re: customization for SolrRequestParsers

2012-02-24 Thread Ryan McKinley 
I don't know exactly what you are trying to do... but you *may* be able to
do it by overriding SolrDispatchFilter#execute(...)

In my app, we add authentication tokens to the request context there.



On Fri, Feb 24, 2012 at 7:49 AM, Mikhail Khludnev 
mkhlud...@griddynamics.com wrote:

 Hello,

 I see that some sort of customization was expected for SolrRequestParsers.
 http://svn.apache.org/viewvc/lucene/dev/trunk/solr/core/src/java/org/apache/solr/servlet/SolrRequestParsers.java?view=markup

 line
  97 // I don't see a need to have this publicly configured just yet
 and
  111 // TODO -- in the future, we could pick a different parser based on
 the request

 I need to plug some code which will parse request and add additional stuff
 iinto req.context. I'd be happy to contribute it, but want to know what was
 an intention.

 Thanks in advance

 --
 Sincerely yours
 Mikhail Khludnev
 Lucid Certified
 Apache Lucene/Solr Developer
 Grid Dynamics

 http://www.griddynamics.com
  mkhlud...@griddynamics.com

[JENKINS] Lucene-Solr-tests-only-trunk - Build # 12508 - Failure

2012-02-24 Thread Apache Jenkins Server 
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12508/

1 tests failed.
REGRESSION:  org.apache.solr.cloud.OverseerTest.testShardLeaderChange

Error Message:
Unexpected shard leader coll:collection1 shard:shard1 expected:core[4] but 
was:core[1]

Stack Trace:
at 
org.apache.solr.cloud.OverseerTest.verifyShardLeader(OverseerTest.java:549)
at 
org.apache.solr.cloud.OverseerTest.testShardLeaderChange(OverseerTest.java:711)
at 
org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:707)
at 
org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:606)
at 
org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:511)
at 
org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:569)
at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:165)
at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)




Build Log (for compile errors):
[...truncated 7776 lines...]



-
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 '/'

2012-02-24 Thread Erik Hatcher (Commented) (JIRA) 

[ 
https://issues.apache.org/jira/browse/SOLR-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13215827#comment-13215827
 ] 

Erik Hatcher commented on SOLR-3161:


How about we just get rid of qt altogether and make everything be path-based? 
  Internally, request handlers can be defined with a rh_name and but it'll 
implicitly be the path.  (and if it is prefixed with a / then we'll just leave 
it as it works now as a path, of course).  In other words, we can be flexible 
about whether the name itself has a / in front or not, but same effect either 
way. Is there a need to continue to support qt at all?  Why?   And in the 
example configuration we can simply register a select request handler (that 
would be mapped to /select).

I concur, no need to have a default setting... /select can be defined and used, 
otherwise only the request handlers defined can be used.

 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-3161) Use of 'qt' should be restricted to searching and should not start with a '/'

2012-02-24 Thread Ryan McKinley (Commented) (JIRA) 

[ 
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] [Issue Comment Edited] (SOLR-3161) Use of 'qt' should be restricted to searching and should not start with a '/'

2012-02-24 Thread Erik Hatcher (Issue Comment Edited) (JIRA) 

[ 
https://issues.apache.org/jira/browse/SOLR-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13215827#comment-13215827
 ] 

Erik Hatcher edited comment on SOLR-3161 at 2/24/12 7:18 PM:
-

How about we just get rid of qt altogether and make everything be path-based? 
  Internally, request handlers can be defined with a rh_name  but it'll 
implicitly be the path.  (and if it is prefixed with a / then we'll just leave 
it as it works now as a path, of course).  In other words, we can be flexible 
about whether the name itself has a / in front or not, but same effect either 
way. Is there a need to continue to support qt at all?  Why?   And in the 
example configuration we can simply register a select request handler (that 
would be mapped to /select).

I concur, no need to have a default setting... /select can be defined and used, 
otherwise only the request handlers defined can be used.

  was (Author: ehatcher):
How about we just get rid of qt altogether and make everything be 
path-based?   Internally, request handlers can be defined with a rh_name and 
but it'll implicitly be the path.  (and if it is prefixed with a / then we'll 
just leave it as it works now as a path, of course).  In other words, we can be 
flexible about whether the name itself has a / in front or not, but same effect 
either way. Is there a need to continue to support qt at all?  Why?   And in 
the example configuration we can simply register a select request handler 
(that would be mapped to /select).

I concur, no need to have a default setting... /select can be defined and used, 
otherwise only the request handlers defined can be used.
  
 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

[JENKINS] Lucene-Solr-tests-only-3.x - Build # 12519 - Still Failing

2012-02-24 Thread Apache Jenkins Server 
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x/12519/

All tests passed

Build Log (for compile errors):
[...truncated 13947 lines...]



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-3162) Continue work on new admin UI

2012-02-24 Thread Erick Erickson (Created) (JIRA) 
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
Affects Versions: 4.0
Reporter: Erick Erickson


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] [Resolved] (SOLR-3116) new Admin UI does not allow drill-down into ZooKeeper

2012-02-24 Thread Erick Erickson (Resolved) (JIRA) 

 [ 
https://issues.apache.org/jira/browse/SOLR-3116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erick Erickson resolved SOLR-3116.
--

   Resolution: Fixed
Fix Version/s: 4.0

Committed crop patch to trunk, r: 1293394

Moving the rest of the new UI development to SOLR-3162

 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
 Fix For: 4.0

 Attachments: SOLR-3116-120224-crop-tree-area.patch, 
 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] [Resolved] (SOLR-2667) Finish Solr Admin UI

2012-02-24 Thread Erick Erickson (Resolved) (JIRA) 

 [ 
https://issues.apache.org/jira/browse/SOLR-2667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erick Erickson resolved SOLR-2667.
--

Resolution: Fixed

Moving the rest of the new UI development to SOLR-3162

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

Re: svn commit: r1293309 - in /lucene/dev/trunk/solr/contrib/extraction/lib: jdom-1.0-LICENSE-ASL_LIKE.txt jdom-1.0-NOTICE.txt jdom-1.0.jar

2012-02-24 Thread Simon Willnauer 
it seems the license is ok (just from looking at it...) my question is does
this come with tika? Do they distribute the jar?

simon

On Fri, Feb 24, 2012 at 6:07 PM, Mark Miller markrmil...@gmail.com wrote:

 It's because ASL_LIKE is not a valid license type. Looking at the license,
 this is not the right type IMO anyway.

 On Feb 24, 2012, at 11:29 AM, Sami Siren wrote:

  trunk ant clean test currently fails when run from /solr because of:
 
  validate:
  [echo] License check under:
  /data3/jenkins_home/jobs/lucene-solr_core/workspace/solr
  [licenses] MISSING LICENSE for the following file:
  [licenses]
 /data3/jenkins_home/jobs/lucene-solr_core/workspace/solr/contrib/extraction/lib/jdom-1.0.jar
 
  --
  Sami Siren
 
  On Fri, Feb 24, 2012 at 6:00 PM,  jan...@apache.org wrote:
  Author: janhoy
  Date: Fri Feb 24 16:00:14 2012
  New Revision: 1293309
 
  URL: http://svn.apache.org/viewvc?rev=1293309view=rev
  Log:
  SOLR-2901: Added jdom-1.0.jar
 
  Added:
 
  lucene/dev/trunk/solr/contrib/extraction/lib/jdom-1.0-LICENSE-ASL_LIKE.txt
   (with props)
 lucene/dev/trunk/solr/contrib/extraction/lib/jdom-1.0-NOTICE.txt
 (with props)
 lucene/dev/trunk/solr/contrib/extraction/lib/jdom-1.0.jar   (with
 props)
 
  Added:
 lucene/dev/trunk/solr/contrib/extraction/lib/jdom-1.0-LICENSE-ASL_LIKE.txt
  URL:
 http://svn.apache.org/viewvc/lucene/dev/trunk/solr/contrib/extraction/lib/jdom-1.0-LICENSE-ASL_LIKE.txt?rev=1293309view=auto
 
 ==
  ---
 lucene/dev/trunk/solr/contrib/extraction/lib/jdom-1.0-LICENSE-ASL_LIKE.txt
 (added)
  +++
 lucene/dev/trunk/solr/contrib/extraction/lib/jdom-1.0-LICENSE-ASL_LIKE.txt
 Fri Feb 24 16:00:14 2012
  @@ -0,0 +1,56 @@
  +/*--
  +
  + $Id: LICENSE.txt,v 1.11 2004/02/06 09:32:57 jhunter Exp $
  +
  + Copyright (C) 2000-2004 Jason Hunter  Brett McLaughlin.
  + All rights reserved.
  +
  + Redistribution and use in source and binary forms, with or without
  + modification, are permitted provided that the following conditions
  + are met:
  +
  + 1. Redistributions of source code must retain the above copyright
  +notice, this list of conditions, and the following disclaimer.
  +
  + 2. Redistributions in binary form must reproduce the above copyright
  +notice, this list of conditions, and the disclaimer that follows
  +these conditions in the documentation and/or other materials
  +provided with the distribution.
  +
  + 3. The name JDOM must not be used to endorse or promote products
  +derived from this software without prior written permission.  For
  +written permission, please contact request_AT_jdom_DOT_org.
  +
  + 4. Products derived from this software may not be called JDOM, nor
  +may JDOM appear in their name, without prior written permission
  +from the JDOM Project Management request_AT_jdom_DOT_org.
  +
  + In addition, we request (but do not require) that you include in the
  + end-user documentation provided with the redistribution and/or in the
  + software itself an acknowledgement equivalent to the following:
  + This product includes software developed by the
  +  JDOM Project (http://www.jdom.org/).
  + Alternatively, the acknowledgment may be graphical using the logos
  + available at http://www.jdom.org/images/logos.
  +
  + THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
  + WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
  + OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
  + DISCLAIMED.  IN NO EVENT SHALL THE JDOM AUTHORS OR THE PROJECT
  + CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
  + SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
  + LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
  + USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
  + ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
  + OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
  + OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
  + SUCH DAMAGE.
  +
  + This software consists of voluntary contributions made by many
  + individuals on behalf of the JDOM Project and was originally
  + created by Jason Hunter jhunter_AT_jdom_DOT_org and
  + Brett McLaughlin brett_AT_jdom_DOT_org.  For more information
  + on the JDOM Project, please see http://www.jdom.org/.
  +
  + */
  +
 
  Added: lucene/dev/trunk/solr/contrib/extraction/lib/jdom-1.0-NOTICE.txt
  URL:
 http://svn.apache.org/viewvc/lucene/dev/trunk/solr/contrib/extraction/lib/jdom-1.0-NOTICE.txt?rev=1293309view=auto
 
 ==
  --- lucene/dev/trunk/solr/contrib/extraction/lib/jdom-1.0-NOTICE.txt
 (added)
  +++ lucene/dev/trunk/solr/contrib/extraction/lib/jdom-1.0-NOTICE.txt
 Fri Feb 24 16:00:14 2012
  @@ -0,0 +1,6 @@
  +Copyright (C) 2000-2004 Jason Hunter  Brett McLaughlin.
  +All

[jira] [Commented] (SOLR-1143) Return partial results when a connection to a shard is refused

2012-02-24 Thread Russell Black (Commented) (JIRA) 

[ 
https://issues.apache.org/jira/browse/SOLR-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13215875#comment-13215875
 ] 

Russell Black commented on SOLR-1143:
-

It's been over two years since this patch was submitted.  What's the status?  I 
would like to see this in the next release.  

 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 '/'

2012-02-24 Thread David Smiley (Commented) (JIRA) 

[ 
https://issues.apache.org/jira/browse/SOLR-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13215878#comment-13215878
 ] 

David Smiley commented on SOLR-3161:


Well that's a total reversal of opinion Erik (being the one behind SOLR-1233), 
and I'm glad!

+1 for getting rid of qt altogether.

But that may be difficult:
* The PingRequestHandler uses 'qt' as is clear in the solrconfig.xml.
* firstSearcher  newSearcher configured in solrconfig.xml can't pick a request 
handler then.  It would be nice if they could, they really should IMO.

Perhaps the solution to the above is qt becomes an internal-only feature that 
doesn't work from the dispatching servlet filter -- the filter would throw an 
error if present.  And heck, why don't we rename this thing to requestHandler 
while we're at it?



 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-3161) Use of 'qt' should be restricted to searching and should not start with a '/'

2012-02-24 Thread Erik Hatcher (Commented) (JIRA) 

[ 
https://issues.apache.org/jira/browse/SOLR-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13215889#comment-13215889
 ] 

Erik Hatcher commented on SOLR-3161:


bq. Well that's a total reversal of opinion Erik (being the one behind 
SOLR-1233), and I'm glad!

Not quite a reversal - but rather a cleaning up.  If we're going to support qt, 
then it should support _any_ request handler, IMO.  But qt is 1) not an 
intuitive name at all, and 2) silly given that we should use paths instead for 
so many reasons.

bq. why don't we rename this thing to requestHandler while we're at it?

I'd be ok with just rh  

bq. PingRequestHandler and firstSearcher/newSearcher

I see the argument for an internal only rh parameter, but still seems it 
shouldn't be necessary to even have that, such that we could dispatch to a 
request handler internally directly without having to specify 
qt/rh/requestHandler as a query parameter.  How we do that, I'm not sure yet 
though.



 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] [Reopened] (SOLR-3137) When solr.xml is persisted, you lose all system property substitution that was used.

2012-02-24 Thread Mark Miller (Reopened) (JIRA) 

 [ 
https://issues.apache.org/jira/browse/SOLR-3137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Miller reopened SOLR-3137:
---


There is a bug here where you might lose some core attribs.

 When solr.xml is persisted, you lose all system property substitution that 
 was used. 
 -

 Key: SOLR-3137
 URL: https://issues.apache.org/jira/browse/SOLR-3137
 Project: Solr
  Issue Type: Bug
Reporter: Mark Miller
Assignee: Mark Miller
 Fix For: 4.0

 Attachments: SOLR-3137.patch, SOLR-3137.patch


 A lesser issue is that we also write out properties that where not originally 
 in the file with the defaults they picked up.

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

2012-02-24 Thread Ryan McKinley (Commented) (JIRA) 

[ 
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 '/'

2012-02-24 Thread Yonik Seeley (Commented) (JIRA) 

[ 
https://issues.apache.org/jira/browse/SOLR-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13215897#comment-13215897
 ] 

Yonik Seeley commented on SOLR-3161:


Eh... if we keep qt in any capacity, it should still be named qt.

 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

Re: svn commit: r1293309 - in /lucene/dev/trunk/solr/contrib/extraction/lib: jdom-1.0-LICENSE-ASL_LIKE.txt jdom-1.0-NOTICE.txt jdom-1.0.jar

2012-02-24 Thread Mark Miller 

On Feb 24, 2012, at 3:10 PM, Simon Willnauer wrote:

 it seems the license is ok 

The problem is not that the license is not okay, it's just not Apache_LIKE (a 
type we don't currently have in our checker either).

It's already been used elsewhere as BSD_LIKE anyhow - which not only makes more 
sense, but is a type we have support for.

Anyhow, I fixed this a while ago.

- Mark Miller
lucidimagination.com












-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Adding offsets to Spans and TermSpans

2012-02-24 Thread Alan Woodward 
Hello,

Following on from https://issues.apache.org/jira/browse/LUCENE-3684, does it 
make sense to expose the startOffset and endOffset from DocsAndPositionsEnum in 
Spans and TermSpans?  I'm writing some highlighter-like code that needs to emit 
exact offsets for complex boolean queries, and Spans.getSpans seems like the 
natural place to get them.  The relevant patch is pretty tiny.

I also have a patch to add offsets to MemoryIndex, from the same bit of 
development.

Thanks,
Alan Woodward

Re: undeleteAll() and delete(int) in trunk?

2012-02-24 Thread Andrzej Bialecki 

On 24/02/2012 21:03, Andrzej Bialecki wrote:

Hi,

What are the equivalents of the 3.x IndexReader.undeleteAll() and
IR.delete(int) in trunk? I guess with the read-only readers this should
be a function of IndexWriter now, but I can't figure out how this is
supposed to work ... or is this functionality no longer available?


.. and how to modify norms, while we're at it...


--
Best regards,
Andrzej Bialecki 
 ___. ___ ___ ___ _ _   __
[__ || __|__/|__||\/|  Information Retrieval, Semantic Web
___|||__||  \|  ||  |  Embedded Unix, System Integration
http://www.sigram.com  Contact: info at sigram dot com


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: undeleteAll() and delete(int) in trunk?

2012-02-24 Thread Simon Willnauer 
IndexReader is ReadOnly now. you can't undelete / delete by DocID anymore.
The norms hell is gone too and should be implemented via DocValues and IW.
there are thoughts and issues open which I don't recall from the top of my
head.

hope that give some clarification

simon

On Fri, Feb 24, 2012 at 10:05 PM, Andrzej Bialecki a...@getopt.org wrote:

 On 24/02/2012 21:03, Andrzej Bialecki wrote:

 Hi,

 What are the equivalents of the 3.x IndexReader.undeleteAll() and
 IR.delete(int) in trunk? I guess with the read-only readers this should
 be a function of IndexWriter now, but I can't figure out how this is
 supposed to work ... or is this functionality no longer available?


 .. and how to modify norms, while we're at it...



 --
 Best regards,
 Andrzej Bialecki 
  ___. ___ ___ ___ _ _   __**
 [__ || __|__/|__||\/|  Information Retrieval, Semantic Web
 ___|||__||  \|  ||  |  Embedded Unix, System Integration
 http://www.sigram.com  Contact: info at sigram dot com


 --**--**-
 To unsubscribe, e-mail: 
 dev-unsubscribe@lucene.apache.**orgdev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-3134) Include shard Information in response

2012-02-24 Thread Russell Black (Commented) (JIRA) 

[ 
https://issues.apache.org/jira/browse/SOLR-3134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13215917#comment-13215917
 ] 

Russell Black commented on SOLR-3134:
-

Nice work! I may try to backport this to 3.5.  

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

Re: customization for SolrRequestParsers

2012-02-24 Thread Ryan McKinley 
I don't recall exactly... but I think it was just an open suggestion that
we *could* use a different parser.

Since that comment was added (5 years ago?) i don't think it has come up...
 but if there is a good use case (and a patch) it may still be a good idea


On Fri, Feb 24, 2012 at 12:03 PM, Mikhail Khludnev 
mkhlud...@griddynamics.com wrote:

 Ryan,

 I did it too, but just for curious, what was the idea of pick a different
 parser based on request?


 On Fri, Feb 24, 2012 at 11:06 PM, Ryan McKinley ryan...@gmail.com wrote:

 I don't know exactly what you are trying to do... but you *may* be able
 to do it by overriding SolrDispatchFilter#execute(...)

 In my app, we add authentication tokens to the request context there.



 On Fri, Feb 24, 2012 at 7:49 AM, Mikhail Khludnev 
 mkhlud...@griddynamics.com wrote:

 Hello,

 I see that some sort of customization was expected
 for SolrRequestParsers.
 http://svn.apache.org/viewvc/lucene/dev/trunk/solr/core/src/java/org/apache/solr/servlet/SolrRequestParsers.java?view=markup

 line
  97 // I don't see a need to have this publicly configured just yet
 and
  111 // TODO -- in the future, we could pick a different parser based
 on the request

 I need to plug some code which will parse request and add additional
 stuff iinto req.context. I'd be happy to contribute it, but want to know
 what was an intention.

 Thanks in advance

 --
 Sincerely yours
 Mikhail Khludnev
 Lucid Certified
 Apache Lucene/Solr Developer
 Grid Dynamics

  http://www.griddynamics.com
  mkhlud...@griddynamics.com





 --
 Sincerely yours
 Mikhail Khludnev
 Lucid Certified
 Apache Lucene/Solr Developer
 Grid Dynamics

 http://www.griddynamics.com
  mkhlud...@griddynamics.com

[jira] [Resolved] (SOLR-1143) Return partial results when a connection to a shard is refused

2012-02-24 Thread Ryan McKinley (Resolved) (JIRA) 

 [ 
https://issues.apache.org/jira/browse/SOLR-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan McKinley resolved SOLR-1143.
-

   Resolution: Duplicate
Fix Version/s: (was: 3.6)
   (was: 4.0)

This can be solved with SOLR-3134

 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
 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 '/'

2012-02-24 Thread David Smiley (Commented) (JIRA) 

[ 
https://issues.apache.org/jira/browse/SOLR-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13215982#comment-13215982
 ] 

David Smiley commented on SOLR-3161:


bq. I see the argument for an internal only rh parameter, but still seems it 
shouldn't be necessary to even have that, such that we could dispatch to a 
request handler internally directly without having to specify 
qt/rh/requestHandler as a query parameter. How we do that, I'm not sure yet 
though.

It seems unavoidable that an internal request handler parameter name be used 
for the config file in these couple places.  I don't think that's a big deal 
and I think it can be retained in a way that still brings some overall code 
clarity, security, and even lines-of-code reduction.  And I guess Yonik's right 
about keeping the old name, even though it's a bad one.

 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-3161) Use of 'qt' should be restricted to searching and should not start with a '/'

2012-02-24 Thread Ryan McKinley (Commented) (JIRA) 

[ 
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

Re: undeleteAll() and delete(int) in trunk?

2012-02-24 Thread Andrzej Bialecki 

On 24/02/2012 22:15, Simon Willnauer wrote:

IndexReader is ReadOnly now. you can't undelete / delete by DocID
anymore. The norms hell is gone too and should be implemented via
DocValues and IW. there are thoughts and issues open which I don't
recall from the top of my head.

hope that give some clarification


Not really. I get the first part about readers being read-only, that's 
fine. But it's still not clear to me how to use IndexWriter (or some 
other api) to undeleteAll, delete by docId, or modify norms without 
updating a document - all of which was possible in 3.x and had real use 
cases.



--
Best regards,
Andrzej Bialecki 
 ___. ___ ___ ___ _ _   __
[__ || __|__/|__||\/|  Information Retrieval, Semantic Web
___|||__||  \|  ||  |  Embedded Unix, System Integration
http://www.sigram.com  Contact: info at sigram dot com


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: svn commit: r806190 - in /websites: production/lucene/content/ production/lucene/content/core/ production/lucene/content/solr/ staging/lucene/trunk/content/ staging/lucene/trunk/content/core/ stag

2012-02-24 Thread Mark Miller 

buildbot is evil :)

AFAICT he auto pubs portions of the site (I assume for svn, twitter, etc) from 
staging. This makes staging less than useful, and if you have done a big 
update, it can auto pub only part of it on you.

Probably we should take out svn, twitter, etc and ask buildbot to leave us 
alone.

On Feb 24, 2012, at 6:21 PM, build...@apache.org wrote:

 Author: buildbot
 Date: Fri Feb 24 23:21:04 2012
 New Revision: 806190
 
 Log:
 Dynamic update by buildbot for lucene
 
 Modified:
websites/production/lucene/content/core/index.html
websites/production/lucene/content/index.html
websites/production/lucene/content/solr/index.html
websites/staging/lucene/trunk/content/core/index.html
websites/staging/lucene/trunk/content/index.html
websites/staging/lucene/trunk/content/solr/index.html
 
 Modified: websites/production/lucene/content/core/index.html
 ==
 --- websites/production/lucene/content/core/index.html (original)
 +++ websites/production/lucene/content/core/index.html Fri Feb 24 23:21:04 
 2012
 @@ -305,6 +305,12 @@
   div class=status-item
 
   div class=section-content
 +a class=svn 
 href=http://svn.apache.org/viewvc?revision=1293460;view=revision;r1293460/a
 +allow the zk server data dir to be overridden by sys prop (a 
 href=http://lucene.apache.org/;lucene/a) mdash;
 +a 
 href=http://people.apache.org/committer-index.html#markrmiller;markrmiller/a
 +  /div
 +
 +  div class=section-content
 a class=svn 
 href=http://svn.apache.org/viewvc?revision=1293415;view=revision;r1293415/a
 a 
 href=https://issues.apache.org/jira/browse/SOLR-3137;SOLR-3137/a: 
 test+fix (a href=http://lucene.apache.org/;lucene/a) mdash;
 a 
 href=http://people.apache.org/committer-index.html#markrmiller;markrmiller/a
 @@ -327,12 +333,6 @@
 take care of small bug around NRT and replication (a 
 href=http://lucene.apache.org/;lucene/a) mdash;
 a 
 href=http://people.apache.org/committer-index.html#markrmiller;markrmiller/a
   /div
 -
 -  div class=section-content
 -a class=svn 
 href=http://svn.apache.org/viewvc?revision=1293346;view=revision;r1293346/a
 -add a retry (a href=http://lucene.apache.org/;lucene/a) mdash;
 -a 
 href=http://people.apache.org/committer-index.html#markrmiller;markrmiller/a
 -  /div
 /div/div
 
 
 
 Modified: websites/production/lucene/content/index.html
 ==
(empty)
 
 Modified: websites/production/lucene/content/solr/index.html
 ==
 --- websites/production/lucene/content/solr/index.html (original)
 +++ websites/production/lucene/content/solr/index.html Fri Feb 24 23:21:04 
 2012
 @@ -400,6 +400,12 @@ numeric fields or query relevancy scores
 div class=status-item
 
   div class=section-content
 +a class=svn 
 href=http://svn.apache.org/viewvc?revision=1293460;view=revision;r1293460/a
 +allow the zk server data dir to be overridden by sys prop (a 
 href=http://lucene.apache.org/;lucene/a) mdash;
 +a 
 href=http://people.apache.org/committer-index.html#markrmiller;markrmiller/a
 +  /div
 +  
 +  div class=section-content
 a class=svn 
 href=http://svn.apache.org/viewvc?revision=1293415;view=revision;r1293415/a
 a 
 href=https://issues.apache.org/jira/browse/SOLR-3137;SOLR-3137/a: 
 test+fix (a href=http://lucene.apache.org/;lucene/a) mdash;
 a 
 href=http://people.apache.org/committer-index.html#markrmiller;markrmiller/a
 @@ -423,12 +429,6 @@ numeric fields or query relevancy scores
 a 
 href=http://people.apache.org/committer-index.html#markrmiller;markrmiller/a
   /div
 
 -  div class=section-content
 -a class=svn 
 href=http://svn.apache.org/viewvc?revision=1293346;view=revision;r1293346/a
 -add a retry (a href=http://lucene.apache.org/;lucene/a) 
 mdash;
 -a 
 href=http://people.apache.org/committer-index.html#markrmiller;markrmiller/a
 -  /div
 -  
 /div
 
   /div
 @@ -438,15 +438,15 @@ numeric fields or query relevancy scores
 
 div class=status-item
   div class=section-content
 - a 
 href=http://twitter.com/itsmeritesh/statuses/173130563241250816;@/aRT a 
 href=http://twitter.com/rbramley;@rbramley/a: Published new blog post: 
 Using Lucene in Grails covers 3 plugins: searchable a 
 href=http://twitter.com/search?q=%23solr;#solr/a a 
 href=http://twitter.com/search?q=%23elasticsearch;#elasticsearch/a : a 
 href=http://t.co/eQmc7rf9;http://t.co/eQmc7rf9/a
 + a 
 href=http://twitter.com/haqen/statuses/173183473824174080;@/aLucene 
 Revolution 2012 a

Re: svn commit: r806190 - in /websites: production/lucene/content/ production/lucene/content/core/ production/lucene/content/solr/ staging/lucene/trunk/content/ staging/lucene/trunk/content/core/ stag

2012-02-24 Thread Yonik Seeley 
On Fri, Feb 24, 2012 at 6:27 PM, Mark Miller markrmil...@gmail.com wrote:

 buildbot is evil :)

 AFAICT he auto pubs portions of the site (I assume for svn, twitter, etc) 
 from staging. This makes staging less than useful, and if you have done a big 
 update, it can auto pub only part of it on you.

 Probably we should take out svn, twitter, etc and ask buildbot to leave us 
 alone.

+1

-Yonik
lucenerevolution.com - Lucene/Solr Open Source Search Conference.
Boston May 7-10

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-3080) We should consider removing shard info from Zk when you explicitly unload a SolrCore.

2012-02-24 Thread Yonik Seeley (Commented) (JIRA) 

[ 
https://issues.apache.org/jira/browse/SOLR-3080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13216244#comment-13216244
 ] 

Yonik Seeley commented on SOLR-3080:


FYI, sometimes the core name and sometimes the zk node name was used to key 
coreStates (leading to duplicate entries on a restart).  I've changed it to 
just key off of core name, along with some other minor improvements like 
creating the map up front so we have a single object to consistently 
synchronize on (prob didn't matter now, but may in the future w/ continued 
development).

 We should consider removing shard info from Zk when you explicitly unload a 
 SolrCore.
 -

 Key: SOLR-3080
 URL: https://issues.apache.org/jira/browse/SOLR-3080
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Mark Miller
Assignee: Sami Siren
Priority: Minor
 Fix For: 4.0

 Attachments: SOLR-3080.patch, SOLR-3080.patch, 
 SOLR-3080_smaller_sync.patch




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

2012-02-24 Thread Mark Miller (Commented) (JIRA) 

[ 
https://issues.apache.org/jira/browse/SOLR-2667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13216274#comment-13216274
 ] 

Mark Miller commented on SOLR-2667:
---

There are actually shell scripts in solr/cloud-dev that will auto start a small 
cluster. 

 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-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] (SOLR-3116) new Admin UI does not allow drill-down into ZooKeeper

2012-02-24 Thread Mark Miller (Commented) (JIRA) 

[ 
https://issues.apache.org/jira/browse/SOLR-3116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13216281#comment-13216281
 ] 

Mark Miller commented on SOLR-3116:
---

This is great, thanks Stefan! Now I just have to con you into turning that raw 
output into another cluster state graphical view :)

I noticed that all quotes have a \ in front of them that should not be there 
(and the problem does not appear to be the /zookeper servlet output) - other 
than that, looks fantastic!

 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
 Fix For: 4.0

 Attachments: SOLR-3116-120224-crop-tree-area.patch, 
 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-3116) new Admin UI does not allow drill-down into ZooKeeper

2012-02-24 Thread Mark Miller (Commented) (JIRA) 

[ 
https://issues.apache.org/jira/browse/SOLR-3116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13216291#comment-13216291
 ] 

Mark Miller commented on SOLR-3116:
---

Also, just as a minor semi related note: it would be great to start the cloud 
view with the first lone node expanded rather than closed.

 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
 Fix For: 4.0

 Attachments: SOLR-3116-120224-crop-tree-area.patch, 
 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