[jira] [Commented] (SOLR-4580) Support for protecting content in ZK
[ https://issues.apache.org/jira/browse/SOLR-4580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13691338#comment-13691338 ] Mark Miller commented on SOLR-4580: --- Looks good, patch still applies and applies to trunk. I'll commit this soon unless someone has further comments. > Support for protecting content in ZK > > > Key: SOLR-4580 > URL: https://issues.apache.org/jira/browse/SOLR-4580 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Affects Versions: 4.2 >Reporter: Per Steffensen >Assignee: Mark Miller > Labels: security, solr, zookeeper > Attachments: SOLR-4580_branch_4x_r1482255.patch > > > We want to protect content in zookeeper. > In order to run a CloudSolrServer in "client-space" you will have to open for > access to zookeeper from client-space. > If you do not trust persons or systems in client-space you want to protect > zookeeper against evilness from client-space - e.g. > * Changing configuration > * Trying to mess up system by manipulating clusterstate > * Add a delete-collection job to be carried out by the Overseer > * etc > Even if you do not open for zookeeper access to someone outside your "secure > zone" you might want to protect zookeeper content from being manipulated by > e.g. > * Malware that found its way into secure zone > * Other systems also using zookeeper > * etc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4580) Support for protecting content in ZK
[ https://issues.apache.org/jira/browse/SOLR-4580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13691301#comment-13691301 ] Mark Miller commented on SOLR-4580: --- I'll review this issue. > Support for protecting content in ZK > > > Key: SOLR-4580 > URL: https://issues.apache.org/jira/browse/SOLR-4580 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Affects Versions: 4.2 >Reporter: Per Steffensen >Assignee: Mark Miller > Labels: security, solr, zookeeper > Attachments: SOLR-4580_branch_4x_r1482255.patch > > > We want to protect content in zookeeper. > In order to run a CloudSolrServer in "client-space" you will have to open for > access to zookeeper from client-space. > If you do not trust persons or systems in client-space you want to protect > zookeeper against evilness from client-space - e.g. > * Changing configuration > * Trying to mess up system by manipulating clusterstate > * Add a delete-collection job to be carried out by the Overseer > * etc > Even if you do not open for zookeeper access to someone outside your "secure > zone" you might want to protect zookeeper content from being manipulated by > e.g. > * Malware that found its way into secure zone > * Other systems also using zookeeper > * etc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4580) Support for protecting content in ZK
[ https://issues.apache.org/jira/browse/SOLR-4580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller reassigned SOLR-4580: - Assignee: Mark Miller (was: Per Steffensen) > Support for protecting content in ZK > > > Key: SOLR-4580 > URL: https://issues.apache.org/jira/browse/SOLR-4580 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Affects Versions: 4.2 >Reporter: Per Steffensen >Assignee: Mark Miller > Labels: security, solr, zookeeper > Attachments: SOLR-4580_branch_4x_r1482255.patch > > > We want to protect content in zookeeper. > In order to run a CloudSolrServer in "client-space" you will have to open for > access to zookeeper from client-space. > If you do not trust persons or systems in client-space you want to protect > zookeeper against evilness from client-space - e.g. > * Changing configuration > * Trying to mess up system by manipulating clusterstate > * Add a delete-collection job to be carried out by the Overseer > * etc > Even if you do not open for zookeeper access to someone outside your "secure > zone" you might want to protect zookeeper content from being manipulated by > e.g. > * Malware that found its way into secure zone > * Other systems also using zookeeper > * etc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Comment Edited] (LUCENE-5072) Add Oracle's JavaDocsUpdater to build for fixing javadocs if generated with Java 6 (and Java 7 prior u25)
[
https://issues.apache.org/jira/browse/LUCENE-5072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13691285#comment-13691285
]
Steve Rowe edited comment on LUCENE-5072 at 6/22/13 11:38 PM:
--
bq. About License: The Javscript code in this patch is also autogenerated by
Oracle's own tool, so its license should not matter (because Oracle's tool
prints it in every file we distribute - we just emulate what Oracle's tool
does).
+1, I agree with this.
I patched trunk ran {{ant generate-maven-artifacts}} using Oracle 1.7.0_21 JDK
on OS X - I saw lines like the following in Ant's output, so the macro is doing
its job:
{noformat}
[patch-javadoc] Replaced 1 occurrences in 1 files.
{noformat}
I then unpacked all the {{*-javadoc.jar}} files under {{dist/}}, then ran the
following, which printed nothing, which I judge as success:
{noformat}
grep -L 'function validURL(url) {' $(grep -l 'function loadFrames() {' $(find .
-name index.htm -o -name index.html -o -name toc.htm -o -name toc.html))
{noformat}
Then I ran {{ant clean documentation}} and the following script also printed
nothing, again success:
{noformat}
grep -L 'function validURL(url) {' $(grep -l 'function loadFrames() {' $(find
{lucene,solr}/build/docs -name index.html -o -name index.htm -o -name toc.htm
-o -name toc.html))
{noformat}
+1 for the patch
was (Author: steve_rowe):
bq. About License: The Javscript code in this patch is also autogenerated
by Oracle's own tool, so its license should not matter (because Oracle's tool
prints it in every file we distribute - we just emulate what Oracle's tool
does).
+1, I agree with this.
I patched trunk ran {{ant generate-maven-artifacts}} using Oracle 1.7.0_21 JDK
on OS X - I saw lines like the following in Ant's output, so the macro is doing
it's job:
{noformat}
[patch-javadoc] Replaced 1 occurrences in 1 files.
{noformat}
I then unpacked all the {{*-javadoc.jar}} files under {{dist/}}, then ran the
following, which printed nothing, which I judge as success:
{noformat}
grep -L 'function validURL(url) {' $(grep -l 'function loadFrames() {' $(find .
-name index.htm -o -name index.html -o -name toc.htm -o -name toc.html))
{noformat}
Then I ran {{ant clean documentation}} and the following script also printed
nothing, again success:
{noformat}
grep -L 'function validURL(url) {' $(grep -l 'function loadFrames() {' $(find
{lucene,solr}/build/docs -name index.html -o -name index.htm -o -name toc.htm
-o -name toc.html))
{noformat}
> Add Oracle's JavaDocsUpdater to build for fixing javadocs if generated with
> Java 6 (and Java 7 prior u25)
> -
>
> Key: LUCENE-5072
> URL: https://issues.apache.org/jira/browse/LUCENE-5072
> Project: Lucene - Core
> Issue Type: Bug
> Components: general/build
>Affects Versions: 4.3.1
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: 5.0, 4.4
>
> Attachments: LUCENE-5072.patch, LUCENE-5072.patch
>
>
> The Apache Infra / Security team posted to all committers:
> {quote}
> Hi All,
> Oracle has announced [1], [2] a frame injection vulnerability in Javadoc
> generated by Java 5, Java 6 and Java 7 before update 22.
> [...]
> Please take the necessary steps to fix any currently published Javadoc and to
> ensure that any future Javadoc published by your project does not contain the
> vulnerability. The announcement by Oracle includes a link to a tool that can
> be used to fix Javadoc without regeneration.
> The infrastructure team is investigating options for preventing the
> publication of vulnerable Javadoc.
> The issue is public and may be discussed freely on your project's dev list.
> Thanks,
> Mark (ASF Infra)
> {quote}
> I fixed all published Javadocs on http://lucene.apache.org (for all historic
> releases where we have public available Javadocs on the web page).
> The mail also notes that we should not publish javadocs with this javadocs
> problem in the future. Unfortunately the release manager has to use the
> latest Java 7u25 version (released 2 days) ago. This would be fine for Lucene
> trunk (which is Java 7 only).
> But when we generate Javadocs JARs for Lucene 3 and 4, we cannot use Java 7
> (to build the official release) because the javadocs would contain e.g.
> AutoCloaseable interface unless we use a JDK 6 or 5 bootclasspath (like we do
> for web pages).
> We also want the lucene/solr-*-javadoc.jar files to be correct, but those are
> built with Java 5 (3.x) or Java 6 (4.x).
> Unfortunately Oracle does not relaese a newer JDK 5 or JDK 6, so its
> impossible to do a release.
> But Oracle publishes the binary and source code of a "fix tool", that can be
> run on
[jira] [Commented] (LUCENE-5072) Add Oracle's JavaDocsUpdater to build for fixing javadocs if generated with Java 6 (and Java 7 prior u25)
[
https://issues.apache.org/jira/browse/LUCENE-5072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13691287#comment-13691287
]
Uwe Schindler commented on LUCENE-5072:
---
I also checked:
- I used 1.6.0_32 to build documentation
- After building I rand the official Oracle tool in check mode: {{java -jar
JavadocUpdaterTool.jar -R -C .}} and it reported no vulnerability.
The Javadocs still work (swithcing on/off frames).
> Add Oracle's JavaDocsUpdater to build for fixing javadocs if generated with
> Java 6 (and Java 7 prior u25)
> -
>
> Key: LUCENE-5072
> URL: https://issues.apache.org/jira/browse/LUCENE-5072
> Project: Lucene - Core
> Issue Type: Bug
> Components: general/build
>Affects Versions: 4.3.1
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: 5.0, 4.4
>
> Attachments: LUCENE-5072.patch, LUCENE-5072.patch
>
>
> The Apache Infra / Security team posted to all committers:
> {quote}
> Hi All,
> Oracle has announced [1], [2] a frame injection vulnerability in Javadoc
> generated by Java 5, Java 6 and Java 7 before update 22.
> [...]
> Please take the necessary steps to fix any currently published Javadoc and to
> ensure that any future Javadoc published by your project does not contain the
> vulnerability. The announcement by Oracle includes a link to a tool that can
> be used to fix Javadoc without regeneration.
> The infrastructure team is investigating options for preventing the
> publication of vulnerable Javadoc.
> The issue is public and may be discussed freely on your project's dev list.
> Thanks,
> Mark (ASF Infra)
> {quote}
> I fixed all published Javadocs on http://lucene.apache.org (for all historic
> releases where we have public available Javadocs on the web page).
> The mail also notes that we should not publish javadocs with this javadocs
> problem in the future. Unfortunately the release manager has to use the
> latest Java 7u25 version (released 2 days) ago. This would be fine for Lucene
> trunk (which is Java 7 only).
> But when we generate Javadocs JARs for Lucene 3 and 4, we cannot use Java 7
> (to build the official release) because the javadocs would contain e.g.
> AutoCloaseable interface unless we use a JDK 6 or 5 bootclasspath (like we do
> for web pages).
> We also want the lucene/solr-*-javadoc.jar files to be correct, but those are
> built with Java 5 (3.x) or Java 6 (4.x).
> Unfortunately Oracle does not relaese a newer JDK 5 or JDK 6, so its
> impossible to do a release.
> But Oracle publishes the binary and source code of a "fix tool", that can be
> run on top of a tree of HTML files, patching all broken files (and only
> those). You can run it theoretically on the root folder of your harddisk - I
> did this on the whole lucene.apache.org web site.
> Robert Muir and I were looking for a IVY-compatible solution (the original
> Oracle tool cannot be automatically downloaded by IVY, as Oracle's website
> sets cookies and requests license confirmations). We found the following
> GITHUB project by olamy/karianna:
> https://github.com/AdoptOpenJDK/JavadocUpdaterTool
> As soon as they release the JAR file officially on Maven, we can download it
> with IVY and use it. This is a Maven Plugin, but it still contains the
> original source code of Oracle's tool, so we can execute it as ANT task after
> loading the JAR with IVY's coordinates: {{}}
> In the GITHUB project description they note that you need JDK7 to use the
> tool, but this is no longer true, the -source/-target is Java 5 now, so we
> can run it easily.
> I will add the required tasks in common-build.xml's javadoc macro so it
> post-processes all javadocs and patches vulnerable files. If you build
> javadocs with a recent JDK, it would do nothing.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] (LUCENE-5072) Add Oracle's JavaDocsUpdater to build for fixing javadocs if generated with Java 6 (and Java 7 prior u25)
[
https://issues.apache.org/jira/browse/LUCENE-5072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-5072:
--
Attachment: LUCENE-5072.patch
Minimal update (added expandProperties="false" to replacement text).
> Add Oracle's JavaDocsUpdater to build for fixing javadocs if generated with
> Java 6 (and Java 7 prior u25)
> -
>
> Key: LUCENE-5072
> URL: https://issues.apache.org/jira/browse/LUCENE-5072
> Project: Lucene - Core
> Issue Type: Bug
> Components: general/build
>Affects Versions: 4.3.1
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: 5.0, 4.4
>
> Attachments: LUCENE-5072.patch, LUCENE-5072.patch
>
>
> The Apache Infra / Security team posted to all committers:
> {quote}
> Hi All,
> Oracle has announced [1], [2] a frame injection vulnerability in Javadoc
> generated by Java 5, Java 6 and Java 7 before update 22.
> [...]
> Please take the necessary steps to fix any currently published Javadoc and to
> ensure that any future Javadoc published by your project does not contain the
> vulnerability. The announcement by Oracle includes a link to a tool that can
> be used to fix Javadoc without regeneration.
> The infrastructure team is investigating options for preventing the
> publication of vulnerable Javadoc.
> The issue is public and may be discussed freely on your project's dev list.
> Thanks,
> Mark (ASF Infra)
> {quote}
> I fixed all published Javadocs on http://lucene.apache.org (for all historic
> releases where we have public available Javadocs on the web page).
> The mail also notes that we should not publish javadocs with this javadocs
> problem in the future. Unfortunately the release manager has to use the
> latest Java 7u25 version (released 2 days) ago. This would be fine for Lucene
> trunk (which is Java 7 only).
> But when we generate Javadocs JARs for Lucene 3 and 4, we cannot use Java 7
> (to build the official release) because the javadocs would contain e.g.
> AutoCloaseable interface unless we use a JDK 6 or 5 bootclasspath (like we do
> for web pages).
> We also want the lucene/solr-*-javadoc.jar files to be correct, but those are
> built with Java 5 (3.x) or Java 6 (4.x).
> Unfortunately Oracle does not relaese a newer JDK 5 or JDK 6, so its
> impossible to do a release.
> But Oracle publishes the binary and source code of a "fix tool", that can be
> run on top of a tree of HTML files, patching all broken files (and only
> those). You can run it theoretically on the root folder of your harddisk - I
> did this on the whole lucene.apache.org web site.
> Robert Muir and I were looking for a IVY-compatible solution (the original
> Oracle tool cannot be automatically downloaded by IVY, as Oracle's website
> sets cookies and requests license confirmations). We found the following
> GITHUB project by olamy/karianna:
> https://github.com/AdoptOpenJDK/JavadocUpdaterTool
> As soon as they release the JAR file officially on Maven, we can download it
> with IVY and use it. This is a Maven Plugin, but it still contains the
> original source code of Oracle's tool, so we can execute it as ANT task after
> loading the JAR with IVY's coordinates: {{}}
> In the GITHUB project description they note that you need JDK7 to use the
> tool, but this is no longer true, the -source/-target is Java 5 now, so we
> can run it easily.
> I will add the required tasks in common-build.xml's javadoc macro so it
> post-processes all javadocs and patches vulnerable files. If you build
> javadocs with a recent JDK, it would do nothing.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] [Comment Edited] (LUCENE-5072) Add Oracle's JavaDocsUpdater to build for fixing javadocs if generated with Java 6 (and Java 7 prior u25)
[
https://issues.apache.org/jira/browse/LUCENE-5072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13691285#comment-13691285
]
Steve Rowe edited comment on LUCENE-5072 at 6/22/13 11:34 PM:
--
bq. About License: The Javscript code in this patch is also autogenerated by
Oracle's own tool, so its license should not matter (because Oracle's tool
prints it in every file we distribute - we just emulate what Oracle's tool
does).
+1, I agree with this.
I patched trunk ran {{ant generate-maven-artifacts}} using Oracle 1.7.0_21 JDK
on OS X - I saw lines like the following in Ant's output, so the macro is doing
it's job:
{noformat}
[patch-javadoc] Replaced 1 occurrences in 1 files.
{noformat}
I then unpacked all the {{*-javadoc.jar}} files under {{dist/}}, then ran the
following, which printed nothing, which I judge as success:
{noformat}
grep -L 'function validURL(url) {' $(grep -l 'function loadFrames() {' $(find .
-name index.htm -o -name index.html -o -name toc.htm -o -name toc.html))
{noformat}
Then I ran {{ant clean documentation}} and the following script also printed
nothing, again success:
{noformat}
grep -L 'function validURL(url) {' $(grep -l 'function loadFrames() {' $(find
{lucene,solr}/build/docs -name index.html -o -name index.htm -o -name toc.htm
-o -name toc.html))
{noformat}
was (Author: steve_rowe):
bq. About License: The Javscript code in this patch is also autogenerated
by Oracle's own tool, so its license should not matter (because Oracle's tool
prints it in every file we distribute - we just emulate what Oracle's tool
does).
+1, I agree with this.
I patched trunk ran {{ant generate-maven-artifacts}} using Oracle 1.7.0_21 JDK
on OS X - I saw lines like the following in Ant's output, so the macro is doing
it's job:
{noformat}
{noformat}
I then unpacked all the {{*-javadoc.jar}} files under {{dist/}}, then ran the
following, which printed nothing, which I judge as success:
{noformat}
grep -L 'function validURL(url) {' $(grep -l 'function loadFrames() {' $(find .
-name index.htm -o -name index.html -o -name toc.htm -o -name toc.html))
{noformat}
Then I ran {{ant clean documentation}} and the following script also printed
nothing, again success:
{noformat}
grep -L 'function validURL(url) {' $(grep -l 'function loadFrames() {' $(find
{lucene,solr}/build/docs -name index.html -o -name index.htm -o -name toc.htm
-o -name toc.html))
{noformat}
> Add Oracle's JavaDocsUpdater to build for fixing javadocs if generated with
> Java 6 (and Java 7 prior u25)
> -
>
> Key: LUCENE-5072
> URL: https://issues.apache.org/jira/browse/LUCENE-5072
> Project: Lucene - Core
> Issue Type: Bug
> Components: general/build
>Affects Versions: 4.3.1
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: 5.0, 4.4
>
> Attachments: LUCENE-5072.patch, LUCENE-5072.patch
>
>
> The Apache Infra / Security team posted to all committers:
> {quote}
> Hi All,
> Oracle has announced [1], [2] a frame injection vulnerability in Javadoc
> generated by Java 5, Java 6 and Java 7 before update 22.
> [...]
> Please take the necessary steps to fix any currently published Javadoc and to
> ensure that any future Javadoc published by your project does not contain the
> vulnerability. The announcement by Oracle includes a link to a tool that can
> be used to fix Javadoc without regeneration.
> The infrastructure team is investigating options for preventing the
> publication of vulnerable Javadoc.
> The issue is public and may be discussed freely on your project's dev list.
> Thanks,
> Mark (ASF Infra)
> {quote}
> I fixed all published Javadocs on http://lucene.apache.org (for all historic
> releases where we have public available Javadocs on the web page).
> The mail also notes that we should not publish javadocs with this javadocs
> problem in the future. Unfortunately the release manager has to use the
> latest Java 7u25 version (released 2 days) ago. This would be fine for Lucene
> trunk (which is Java 7 only).
> But when we generate Javadocs JARs for Lucene 3 and 4, we cannot use Java 7
> (to build the official release) because the javadocs would contain e.g.
> AutoCloaseable interface unless we use a JDK 6 or 5 bootclasspath (like we do
> for web pages).
> We also want the lucene/solr-*-javadoc.jar files to be correct, but those are
> built with Java 5 (3.x) or Java 6 (4.x).
> Unfortunately Oracle does not relaese a newer JDK 5 or JDK 6, so its
> impossible to do a release.
> But Oracle publishes the binary and source code of a "fix tool", that can be
> run on top of a tree of HTML files, patching all broken files (and only
>
[jira] [Commented] (LUCENE-5072) Add Oracle's JavaDocsUpdater to build for fixing javadocs if generated with Java 6 (and Java 7 prior u25)
[
https://issues.apache.org/jira/browse/LUCENE-5072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13691285#comment-13691285
]
Steve Rowe commented on LUCENE-5072:
bq. About License: The Javscript code in this patch is also autogenerated by
Oracle's own tool, so its license should not matter (because Oracle's tool
prints it in every file we distribute - we just emulate what Oracle's tool
does).
+1, I agree with this.
I patched trunk ran {{ant generate-maven-artifacts}} using Oracle 1.7.0_21 JDK
on OS X - I saw lines like the following in Ant's output, so the macro is doing
it's job:
{noformat}
{noformat}
I then unpacked all the {{*-javadoc.jar}} files under {{dist/}}, then ran the
following, which printed nothing, which I judge as success:
{noformat}
grep -L 'function validURL(url) {' $(grep -l 'function loadFrames() {' $(find .
-name index.htm -o -name index.html -o -name toc.htm -o -name toc.html))
{noformat}
Then I ran {{ant clean documentation}} and the following script also printed
nothing, again success:
{noformat}
grep -L 'function validURL(url) {' $(grep -l 'function loadFrames() {' $(find
{lucene,solr}/build/docs -name index.html -o -name index.htm -o -name toc.htm
-o -name toc.html))
{noformat}
> Add Oracle's JavaDocsUpdater to build for fixing javadocs if generated with
> Java 6 (and Java 7 prior u25)
> -
>
> Key: LUCENE-5072
> URL: https://issues.apache.org/jira/browse/LUCENE-5072
> Project: Lucene - Core
> Issue Type: Bug
> Components: general/build
>Affects Versions: 4.3.1
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: 5.0, 4.4
>
> Attachments: LUCENE-5072.patch
>
>
> The Apache Infra / Security team posted to all committers:
> {quote}
> Hi All,
> Oracle has announced [1], [2] a frame injection vulnerability in Javadoc
> generated by Java 5, Java 6 and Java 7 before update 22.
> [...]
> Please take the necessary steps to fix any currently published Javadoc and to
> ensure that any future Javadoc published by your project does not contain the
> vulnerability. The announcement by Oracle includes a link to a tool that can
> be used to fix Javadoc without regeneration.
> The infrastructure team is investigating options for preventing the
> publication of vulnerable Javadoc.
> The issue is public and may be discussed freely on your project's dev list.
> Thanks,
> Mark (ASF Infra)
> {quote}
> I fixed all published Javadocs on http://lucene.apache.org (for all historic
> releases where we have public available Javadocs on the web page).
> The mail also notes that we should not publish javadocs with this javadocs
> problem in the future. Unfortunately the release manager has to use the
> latest Java 7u25 version (released 2 days) ago. This would be fine for Lucene
> trunk (which is Java 7 only).
> But when we generate Javadocs JARs for Lucene 3 and 4, we cannot use Java 7
> (to build the official release) because the javadocs would contain e.g.
> AutoCloaseable interface unless we use a JDK 6 or 5 bootclasspath (like we do
> for web pages).
> We also want the lucene/solr-*-javadoc.jar files to be correct, but those are
> built with Java 5 (3.x) or Java 6 (4.x).
> Unfortunately Oracle does not relaese a newer JDK 5 or JDK 6, so its
> impossible to do a release.
> But Oracle publishes the binary and source code of a "fix tool", that can be
> run on top of a tree of HTML files, patching all broken files (and only
> those). You can run it theoretically on the root folder of your harddisk - I
> did this on the whole lucene.apache.org web site.
> Robert Muir and I were looking for a IVY-compatible solution (the original
> Oracle tool cannot be automatically downloaded by IVY, as Oracle's website
> sets cookies and requests license confirmations). We found the following
> GITHUB project by olamy/karianna:
> https://github.com/AdoptOpenJDK/JavadocUpdaterTool
> As soon as they release the JAR file officially on Maven, we can download it
> with IVY and use it. This is a Maven Plugin, but it still contains the
> original source code of Oracle's tool, so we can execute it as ANT task after
> loading the JAR with IVY's coordinates: {{}}
> In the GITHUB project description they note that you need JDK7 to use the
> tool, but this is no longer true, the -source/-target is Java 5 now, so we
> can run it easily.
> I will add the required tasks in common-build.xml's javadoc macro so it
> post-processes all javadocs and patches vulnerable files. If you build
> javadocs with a recent JDK, it would do nothing.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more inf
[jira] [Comment Edited] (LUCENE-5072) Add Oracle's JavaDocsUpdater to build for fixing javadocs if generated with Java 6 (and Java 7 prior u25)
[
https://issues.apache.org/jira/browse/LUCENE-5072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13691269#comment-13691269
]
Uwe Schindler edited comment on LUCENE-5072 at 6/22/13 11:09 PM:
-
Attached is a patch that works without Oracle's proprietary license. The
patching is done completely with ANT and its own search/replace logic:
- Use a fileset on the vulnerable filename pattern
{{\*\*/index.htm*,\*\*/toc.htm*}}, with restriction to all files that do *not*
contain the "validURL(url)" pattern (which appears after u25)
- replace the vulnerable call by the javascript code from Oracle's patch
About License: The Javscript code in this patch is also autogenerated by
Oracle's own tool, so its license should not matter (because Oracle's tool
prints it in every file we distribute - we just emulate what Oracle's tool
does).
What do you think?
was (Author: thetaphi):
Attached is a patch that works without Oracle's proprietary license. The
patching is done completely with ANT and its own search/replace logic:
- Use a fileset on the vulnerable filename pattern **/index.htm*,**/toc.htm*,
with restriction to all files that do *not* contain the "validURL(url)" pattern
(which appears after u25)
- replace the vulnerable call by the javascript code from Oracle's patch
About License: The Javscript code in this patch is also autogenerated by
Oracle's own tool, so its license should not matter (because Oracle's tool
prints it in every file we distribute - we just emulate what Oracle's tool
does).
What do you think?
> Add Oracle's JavaDocsUpdater to build for fixing javadocs if generated with
> Java 6 (and Java 7 prior u25)
> -
>
> Key: LUCENE-5072
> URL: https://issues.apache.org/jira/browse/LUCENE-5072
> Project: Lucene - Core
> Issue Type: Bug
> Components: general/build
>Affects Versions: 4.3.1
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: 5.0, 4.4
>
> Attachments: LUCENE-5072.patch
>
>
> The Apache Infra / Security team posted to all committers:
> {quote}
> Hi All,
> Oracle has announced [1], [2] a frame injection vulnerability in Javadoc
> generated by Java 5, Java 6 and Java 7 before update 22.
> [...]
> Please take the necessary steps to fix any currently published Javadoc and to
> ensure that any future Javadoc published by your project does not contain the
> vulnerability. The announcement by Oracle includes a link to a tool that can
> be used to fix Javadoc without regeneration.
> The infrastructure team is investigating options for preventing the
> publication of vulnerable Javadoc.
> The issue is public and may be discussed freely on your project's dev list.
> Thanks,
> Mark (ASF Infra)
> {quote}
> I fixed all published Javadocs on http://lucene.apache.org (for all historic
> releases where we have public available Javadocs on the web page).
> The mail also notes that we should not publish javadocs with this javadocs
> problem in the future. Unfortunately the release manager has to use the
> latest Java 7u25 version (released 2 days) ago. This would be fine for Lucene
> trunk (which is Java 7 only).
> But when we generate Javadocs JARs for Lucene 3 and 4, we cannot use Java 7
> (to build the official release) because the javadocs would contain e.g.
> AutoCloaseable interface unless we use a JDK 6 or 5 bootclasspath (like we do
> for web pages).
> We also want the lucene/solr-*-javadoc.jar files to be correct, but those are
> built with Java 5 (3.x) or Java 6 (4.x).
> Unfortunately Oracle does not relaese a newer JDK 5 or JDK 6, so its
> impossible to do a release.
> But Oracle publishes the binary and source code of a "fix tool", that can be
> run on top of a tree of HTML files, patching all broken files (and only
> those). You can run it theoretically on the root folder of your harddisk - I
> did this on the whole lucene.apache.org web site.
> Robert Muir and I were looking for a IVY-compatible solution (the original
> Oracle tool cannot be automatically downloaded by IVY, as Oracle's website
> sets cookies and requests license confirmations). We found the following
> GITHUB project by olamy/karianna:
> https://github.com/AdoptOpenJDK/JavadocUpdaterTool
> As soon as they release the JAR file officially on Maven, we can download it
> with IVY and use it. This is a Maven Plugin, but it still contains the
> original source code of Oracle's tool, so we can execute it as ANT task after
> loading the JAR with IVY's coordinates: {{}}
> In the GITHUB project description they note that you need JDK7 to use the
> tool, but this is no longer true, the -source/-target is Java 5 now, so we
> can
[jira] [Updated] (LUCENE-5072) Add Oracle's JavaDocsUpdater to build for fixing javadocs if generated with Java 6 (and Java 7 prior u25)
[
https://issues.apache.org/jira/browse/LUCENE-5072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-5072:
--
Attachment: (was: LUCENE-5072.patch)
> Add Oracle's JavaDocsUpdater to build for fixing javadocs if generated with
> Java 6 (and Java 7 prior u25)
> -
>
> Key: LUCENE-5072
> URL: https://issues.apache.org/jira/browse/LUCENE-5072
> Project: Lucene - Core
> Issue Type: Bug
> Components: general/build
>Affects Versions: 4.3.1
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: 5.0, 4.4
>
> Attachments: LUCENE-5072.patch
>
>
> The Apache Infra / Security team posted to all committers:
> {quote}
> Hi All,
> Oracle has announced [1], [2] a frame injection vulnerability in Javadoc
> generated by Java 5, Java 6 and Java 7 before update 22.
> [...]
> Please take the necessary steps to fix any currently published Javadoc and to
> ensure that any future Javadoc published by your project does not contain the
> vulnerability. The announcement by Oracle includes a link to a tool that can
> be used to fix Javadoc without regeneration.
> The infrastructure team is investigating options for preventing the
> publication of vulnerable Javadoc.
> The issue is public and may be discussed freely on your project's dev list.
> Thanks,
> Mark (ASF Infra)
> {quote}
> I fixed all published Javadocs on http://lucene.apache.org (for all historic
> releases where we have public available Javadocs on the web page).
> The mail also notes that we should not publish javadocs with this javadocs
> problem in the future. Unfortunately the release manager has to use the
> latest Java 7u25 version (released 2 days) ago. This would be fine for Lucene
> trunk (which is Java 7 only).
> But when we generate Javadocs JARs for Lucene 3 and 4, we cannot use Java 7
> (to build the official release) because the javadocs would contain e.g.
> AutoCloaseable interface unless we use a JDK 6 or 5 bootclasspath (like we do
> for web pages).
> We also want the lucene/solr-*-javadoc.jar files to be correct, but those are
> built with Java 5 (3.x) or Java 6 (4.x).
> Unfortunately Oracle does not relaese a newer JDK 5 or JDK 6, so its
> impossible to do a release.
> But Oracle publishes the binary and source code of a "fix tool", that can be
> run on top of a tree of HTML files, patching all broken files (and only
> those). You can run it theoretically on the root folder of your harddisk - I
> did this on the whole lucene.apache.org web site.
> Robert Muir and I were looking for a IVY-compatible solution (the original
> Oracle tool cannot be automatically downloaded by IVY, as Oracle's website
> sets cookies and requests license confirmations). We found the following
> GITHUB project by olamy/karianna:
> https://github.com/AdoptOpenJDK/JavadocUpdaterTool
> As soon as they release the JAR file officially on Maven, we can download it
> with IVY and use it. This is a Maven Plugin, but it still contains the
> original source code of Oracle's tool, so we can execute it as ANT task after
> loading the JAR with IVY's coordinates: {{}}
> In the GITHUB project description they note that you need JDK7 to use the
> tool, but this is no longer true, the -source/-target is Java 5 now, so we
> can run it easily.
> I will add the required tasks in common-build.xml's javadoc macro so it
> post-processes all javadocs and patches vulnerable files. If you build
> javadocs with a recent JDK, it would do nothing.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] (LUCENE-5072) Add Oracle's JavaDocsUpdater to build for fixing javadocs if generated with Java 6 (and Java 7 prior u25)
[
https://issues.apache.org/jira/browse/LUCENE-5072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-5072:
--
Attachment: LUCENE-5072.patch
Previous patch had a bug in fileset and includes...
> Add Oracle's JavaDocsUpdater to build for fixing javadocs if generated with
> Java 6 (and Java 7 prior u25)
> -
>
> Key: LUCENE-5072
> URL: https://issues.apache.org/jira/browse/LUCENE-5072
> Project: Lucene - Core
> Issue Type: Bug
> Components: general/build
>Affects Versions: 4.3.1
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: 5.0, 4.4
>
> Attachments: LUCENE-5072.patch
>
>
> The Apache Infra / Security team posted to all committers:
> {quote}
> Hi All,
> Oracle has announced [1], [2] a frame injection vulnerability in Javadoc
> generated by Java 5, Java 6 and Java 7 before update 22.
> [...]
> Please take the necessary steps to fix any currently published Javadoc and to
> ensure that any future Javadoc published by your project does not contain the
> vulnerability. The announcement by Oracle includes a link to a tool that can
> be used to fix Javadoc without regeneration.
> The infrastructure team is investigating options for preventing the
> publication of vulnerable Javadoc.
> The issue is public and may be discussed freely on your project's dev list.
> Thanks,
> Mark (ASF Infra)
> {quote}
> I fixed all published Javadocs on http://lucene.apache.org (for all historic
> releases where we have public available Javadocs on the web page).
> The mail also notes that we should not publish javadocs with this javadocs
> problem in the future. Unfortunately the release manager has to use the
> latest Java 7u25 version (released 2 days) ago. This would be fine for Lucene
> trunk (which is Java 7 only).
> But when we generate Javadocs JARs for Lucene 3 and 4, we cannot use Java 7
> (to build the official release) because the javadocs would contain e.g.
> AutoCloaseable interface unless we use a JDK 6 or 5 bootclasspath (like we do
> for web pages).
> We also want the lucene/solr-*-javadoc.jar files to be correct, but those are
> built with Java 5 (3.x) or Java 6 (4.x).
> Unfortunately Oracle does not relaese a newer JDK 5 or JDK 6, so its
> impossible to do a release.
> But Oracle publishes the binary and source code of a "fix tool", that can be
> run on top of a tree of HTML files, patching all broken files (and only
> those). You can run it theoretically on the root folder of your harddisk - I
> did this on the whole lucene.apache.org web site.
> Robert Muir and I were looking for a IVY-compatible solution (the original
> Oracle tool cannot be automatically downloaded by IVY, as Oracle's website
> sets cookies and requests license confirmations). We found the following
> GITHUB project by olamy/karianna:
> https://github.com/AdoptOpenJDK/JavadocUpdaterTool
> As soon as they release the JAR file officially on Maven, we can download it
> with IVY and use it. This is a Maven Plugin, but it still contains the
> original source code of Oracle's tool, so we can execute it as ANT task after
> loading the JAR with IVY's coordinates: {{}}
> In the GITHUB project description they note that you need JDK7 to use the
> tool, but this is no longer true, the -source/-target is Java 5 now, so we
> can run it easily.
> I will add the required tasks in common-build.xml's javadoc macro so it
> post-processes all javadocs and patches vulnerable files. If you build
> javadocs with a recent JDK, it would do nothing.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] (LUCENE-5072) Add Oracle's JavaDocsUpdater to build for fixing javadocs if generated with Java 6 (and Java 7 prior u25)
[
https://issues.apache.org/jira/browse/LUCENE-5072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-5072:
--
Attachment: LUCENE-5072.patch
Attached is a patch that works without Oracle's proprietary license. The
patching is done completely with ANT and its own search/replace logic:
- Use a fileset on the vulnerable filename pattern **/index.htm*,**/toc.htm*,
with restriction to all files that do *not* contain the "validURL(url)" pattern
(which appears after u25)
- replace the vulnerable call by the javascript code from Oracle's patch
About License: The Javscript code in this patch is also autogenerated by
Oracle's own tool, so its license should not matter (because Oracle's tool
prints it in every file we distribute - we just emulate what Oracle's tool
does).
What do you think?
> Add Oracle's JavaDocsUpdater to build for fixing javadocs if generated with
> Java 6 (and Java 7 prior u25)
> -
>
> Key: LUCENE-5072
> URL: https://issues.apache.org/jira/browse/LUCENE-5072
> Project: Lucene - Core
> Issue Type: Bug
> Components: general/build
>Affects Versions: 4.3.1
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: 5.0, 4.4
>
> Attachments: LUCENE-5072.patch
>
>
> The Apache Infra / Security team posted to all committers:
> {quote}
> Hi All,
> Oracle has announced [1], [2] a frame injection vulnerability in Javadoc
> generated by Java 5, Java 6 and Java 7 before update 22.
> [...]
> Please take the necessary steps to fix any currently published Javadoc and to
> ensure that any future Javadoc published by your project does not contain the
> vulnerability. The announcement by Oracle includes a link to a tool that can
> be used to fix Javadoc without regeneration.
> The infrastructure team is investigating options for preventing the
> publication of vulnerable Javadoc.
> The issue is public and may be discussed freely on your project's dev list.
> Thanks,
> Mark (ASF Infra)
> {quote}
> I fixed all published Javadocs on http://lucene.apache.org (for all historic
> releases where we have public available Javadocs on the web page).
> The mail also notes that we should not publish javadocs with this javadocs
> problem in the future. Unfortunately the release manager has to use the
> latest Java 7u25 version (released 2 days) ago. This would be fine for Lucene
> trunk (which is Java 7 only).
> But when we generate Javadocs JARs for Lucene 3 and 4, we cannot use Java 7
> (to build the official release) because the javadocs would contain e.g.
> AutoCloaseable interface unless we use a JDK 6 or 5 bootclasspath (like we do
> for web pages).
> We also want the lucene/solr-*-javadoc.jar files to be correct, but those are
> built with Java 5 (3.x) or Java 6 (4.x).
> Unfortunately Oracle does not relaese a newer JDK 5 or JDK 6, so its
> impossible to do a release.
> But Oracle publishes the binary and source code of a "fix tool", that can be
> run on top of a tree of HTML files, patching all broken files (and only
> those). You can run it theoretically on the root folder of your harddisk - I
> did this on the whole lucene.apache.org web site.
> Robert Muir and I were looking for a IVY-compatible solution (the original
> Oracle tool cannot be automatically downloaded by IVY, as Oracle's website
> sets cookies and requests license confirmations). We found the following
> GITHUB project by olamy/karianna:
> https://github.com/AdoptOpenJDK/JavadocUpdaterTool
> As soon as they release the JAR file officially on Maven, we can download it
> with IVY and use it. This is a Maven Plugin, but it still contains the
> original source code of Oracle's tool, so we can execute it as ANT task after
> loading the JAR with IVY's coordinates: {{}}
> In the GITHUB project description they note that you need JDK7 to use the
> tool, but this is no longer true, the -source/-target is Java 5 now, so we
> can run it easily.
> I will add the required tasks in common-build.xml's javadoc macro so it
> post-processes all javadocs and patches vulnerable files. If you build
> javadocs with a recent JDK, it would do nothing.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-5072) Add Oracle's JavaDocsUpdater to build for fixing javadocs if generated with Java 6 (and Java 7 prior u25)
[
https://issues.apache.org/jira/browse/LUCENE-5072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13691261#comment-13691261
]
Uwe Schindler commented on LUCENE-5072:
---
I checked the javadoc pather tool:
- As said before it uses default encoding to patch files -> die, die, die
- It only detects a "string signature in a file" -> replace by a in
ANT!
- It does a simple search/replace of a string -> use ANT copy task to patch
with
Finally, we dont need to use Oracle's code to recursively patch javadocs, We
can do that with a simple fileset after the javadocs run and patch with ANT's
own task.
> Add Oracle's JavaDocsUpdater to build for fixing javadocs if generated with
> Java 6 (and Java 7 prior u25)
> -
>
> Key: LUCENE-5072
> URL: https://issues.apache.org/jira/browse/LUCENE-5072
> Project: Lucene - Core
> Issue Type: Bug
> Components: general/build
>Affects Versions: 4.3.1
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: 5.0, 4.4
>
>
> The Apache Infra / Security team posted to all committers:
> {quote}
> Hi All,
> Oracle has announced [1], [2] a frame injection vulnerability in Javadoc
> generated by Java 5, Java 6 and Java 7 before update 22.
> [...]
> Please take the necessary steps to fix any currently published Javadoc and to
> ensure that any future Javadoc published by your project does not contain the
> vulnerability. The announcement by Oracle includes a link to a tool that can
> be used to fix Javadoc without regeneration.
> The infrastructure team is investigating options for preventing the
> publication of vulnerable Javadoc.
> The issue is public and may be discussed freely on your project's dev list.
> Thanks,
> Mark (ASF Infra)
> {quote}
> I fixed all published Javadocs on http://lucene.apache.org (for all historic
> releases where we have public available Javadocs on the web page).
> The mail also notes that we should not publish javadocs with this javadocs
> problem in the future. Unfortunately the release manager has to use the
> latest Java 7u25 version (released 2 days) ago. This would be fine for Lucene
> trunk (which is Java 7 only).
> But when we generate Javadocs JARs for Lucene 3 and 4, we cannot use Java 7
> (to build the official release) because the javadocs would contain e.g.
> AutoCloaseable interface unless we use a JDK 6 or 5 bootclasspath (like we do
> for web pages).
> We also want the lucene/solr-*-javadoc.jar files to be correct, but those are
> built with Java 5 (3.x) or Java 6 (4.x).
> Unfortunately Oracle does not relaese a newer JDK 5 or JDK 6, so its
> impossible to do a release.
> But Oracle publishes the binary and source code of a "fix tool", that can be
> run on top of a tree of HTML files, patching all broken files (and only
> those). You can run it theoretically on the root folder of your harddisk - I
> did this on the whole lucene.apache.org web site.
> Robert Muir and I were looking for a IVY-compatible solution (the original
> Oracle tool cannot be automatically downloaded by IVY, as Oracle's website
> sets cookies and requests license confirmations). We found the following
> GITHUB project by olamy/karianna:
> https://github.com/AdoptOpenJDK/JavadocUpdaterTool
> As soon as they release the JAR file officially on Maven, we can download it
> with IVY and use it. This is a Maven Plugin, but it still contains the
> original source code of Oracle's tool, so we can execute it as ANT task after
> loading the JAR with IVY's coordinates: {{}}
> In the GITHUB project description they note that you need JDK7 to use the
> tool, but this is no longer true, the -source/-target is Java 5 now, so we
> can run it easily.
> I will add the required tasks in common-build.xml's javadoc macro so it
> post-processes all javadocs and patches vulnerable files. If you build
> javadocs with a recent JDK, it would do nothing.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] (LUCENE-5073) Setting position and offset gaps in IndexableField
[ https://issues.apache.org/jira/browse/LUCENE-5073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wettin updated LUCENE-5073: Attachment: LUCENE-5073.patch > Setting position and offset gaps in IndexableField > -- > > Key: LUCENE-5073 > URL: https://issues.apache.org/jira/browse/LUCENE-5073 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Karl Wettin >Priority: Trivial > Attachments: LUCENE-5073.patch > > > I often find it to be quite the hassle to go via Analyzer in order to add > offset/position gaps when adding data the the same field name. > This patch introduce IndexableField#positionIncrementGap and #offsetGap, > which at index time is added to the value gathered from the correlating > Analyzer#methods. > No tests in here, yet, but first a question: am I missing something important > in the design of Lucene here? Why is this not already a feature? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Created] (LUCENE-5073) Setting position and offset gaps in IndexableField
Karl Wettin created LUCENE-5073: --- Summary: Setting position and offset gaps in IndexableField Key: LUCENE-5073 URL: https://issues.apache.org/jira/browse/LUCENE-5073 Project: Lucene - Core Issue Type: Improvement Reporter: Karl Wettin Priority: Trivial I often find it to be quite the hassle to go via Analyzer in order to add offset/position gaps when adding data the the same field name. This patch introduce IndexableField#positionIncrementGap and #offsetGap, which at index time is added to the value gathered from the correlating Analyzer#methods. No tests in here, yet, but first a question: am I missing something important in the design of Lucene here? Why is this not already a feature? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-5072) Add Oracle's JavaDocsUpdater to build for fixing javadocs if generated with Java 6 (and Java 7 prior u25)
[
https://issues.apache.org/jira/browse/LUCENE-5072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13691260#comment-13691260
]
Robert Muir commented on LUCENE-5072:
-
There is no need for any legal decision. We don't need to distribute anything,
just invoke the tool in our build. Just like calling javac itself, which is
gpl/proprietary.
> Add Oracle's JavaDocsUpdater to build for fixing javadocs if generated with
> Java 6 (and Java 7 prior u25)
> -
>
> Key: LUCENE-5072
> URL: https://issues.apache.org/jira/browse/LUCENE-5072
> Project: Lucene - Core
> Issue Type: Bug
> Components: general/build
>Affects Versions: 4.3.1
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: 5.0, 4.4
>
>
> The Apache Infra / Security team posted to all committers:
> {quote}
> Hi All,
> Oracle has announced [1], [2] a frame injection vulnerability in Javadoc
> generated by Java 5, Java 6 and Java 7 before update 22.
> [...]
> Please take the necessary steps to fix any currently published Javadoc and to
> ensure that any future Javadoc published by your project does not contain the
> vulnerability. The announcement by Oracle includes a link to a tool that can
> be used to fix Javadoc without regeneration.
> The infrastructure team is investigating options for preventing the
> publication of vulnerable Javadoc.
> The issue is public and may be discussed freely on your project's dev list.
> Thanks,
> Mark (ASF Infra)
> {quote}
> I fixed all published Javadocs on http://lucene.apache.org (for all historic
> releases where we have public available Javadocs on the web page).
> The mail also notes that we should not publish javadocs with this javadocs
> problem in the future. Unfortunately the release manager has to use the
> latest Java 7u25 version (released 2 days) ago. This would be fine for Lucene
> trunk (which is Java 7 only).
> But when we generate Javadocs JARs for Lucene 3 and 4, we cannot use Java 7
> (to build the official release) because the javadocs would contain e.g.
> AutoCloaseable interface unless we use a JDK 6 or 5 bootclasspath (like we do
> for web pages).
> We also want the lucene/solr-*-javadoc.jar files to be correct, but those are
> built with Java 5 (3.x) or Java 6 (4.x).
> Unfortunately Oracle does not relaese a newer JDK 5 or JDK 6, so its
> impossible to do a release.
> But Oracle publishes the binary and source code of a "fix tool", that can be
> run on top of a tree of HTML files, patching all broken files (and only
> those). You can run it theoretically on the root folder of your harddisk - I
> did this on the whole lucene.apache.org web site.
> Robert Muir and I were looking for a IVY-compatible solution (the original
> Oracle tool cannot be automatically downloaded by IVY, as Oracle's website
> sets cookies and requests license confirmations). We found the following
> GITHUB project by olamy/karianna:
> https://github.com/AdoptOpenJDK/JavadocUpdaterTool
> As soon as they release the JAR file officially on Maven, we can download it
> with IVY and use it. This is a Maven Plugin, but it still contains the
> original source code of Oracle's tool, so we can execute it as ANT task after
> loading the JAR with IVY's coordinates: {{}}
> In the GITHUB project description they note that you need JDK7 to use the
> tool, but this is no longer true, the -source/-target is Java 5 now, so we
> can run it easily.
> I will add the required tasks in common-build.xml's javadoc macro so it
> post-processes all javadocs and patches vulnerable files. If you build
> javadocs with a recent JDK, it would do nothing.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] [Comment Edited] (LUCENE-5072) Add Oracle's JavaDocsUpdater to build for fixing javadocs if generated with Java 6 (and Java 7 prior u25)
[
https://issues.apache.org/jira/browse/LUCENE-5072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13691258#comment-13691258
]
Uwe Schindler edited comment on LUCENE-5072 at 6/22/13 9:43 PM:
Cool, so we could maybe put the tool into our tools folder and use it from
there. The original Oracle tool has a forbidden-api problem: It used default
charset to process javadocs files :(
If LEGAL-171 does not solve the problem, we can use the Maven plugin as it is
an *internal* build tool (like we use svnkit or groovy for our builds) and not
linked into the product.
was (Author: thetaphi):
Cool, so we could maybe put the tool into our tools folder and use it from
there. The original Oracle tool has a forbidden-api problem: It used default
charset to process javadocs files :(
If LEGAL-171 does not solve the problem, we can use the Maven plugin as it is a
build tool (like we use svnkit or groovy for our builds) and not linked into
the product.
> Add Oracle's JavaDocsUpdater to build for fixing javadocs if generated with
> Java 6 (and Java 7 prior u25)
> -
>
> Key: LUCENE-5072
> URL: https://issues.apache.org/jira/browse/LUCENE-5072
> Project: Lucene - Core
> Issue Type: Bug
> Components: general/build
>Affects Versions: 4.3.1
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: 5.0, 4.4
>
>
> The Apache Infra / Security team posted to all committers:
> {quote}
> Hi All,
> Oracle has announced [1], [2] a frame injection vulnerability in Javadoc
> generated by Java 5, Java 6 and Java 7 before update 22.
> [...]
> Please take the necessary steps to fix any currently published Javadoc and to
> ensure that any future Javadoc published by your project does not contain the
> vulnerability. The announcement by Oracle includes a link to a tool that can
> be used to fix Javadoc without regeneration.
> The infrastructure team is investigating options for preventing the
> publication of vulnerable Javadoc.
> The issue is public and may be discussed freely on your project's dev list.
> Thanks,
> Mark (ASF Infra)
> {quote}
> I fixed all published Javadocs on http://lucene.apache.org (for all historic
> releases where we have public available Javadocs on the web page).
> The mail also notes that we should not publish javadocs with this javadocs
> problem in the future. Unfortunately the release manager has to use the
> latest Java 7u25 version (released 2 days) ago. This would be fine for Lucene
> trunk (which is Java 7 only).
> But when we generate Javadocs JARs for Lucene 3 and 4, we cannot use Java 7
> (to build the official release) because the javadocs would contain e.g.
> AutoCloaseable interface unless we use a JDK 6 or 5 bootclasspath (like we do
> for web pages).
> We also want the lucene/solr-*-javadoc.jar files to be correct, but those are
> built with Java 5 (3.x) or Java 6 (4.x).
> Unfortunately Oracle does not relaese a newer JDK 5 or JDK 6, so its
> impossible to do a release.
> But Oracle publishes the binary and source code of a "fix tool", that can be
> run on top of a tree of HTML files, patching all broken files (and only
> those). You can run it theoretically on the root folder of your harddisk - I
> did this on the whole lucene.apache.org web site.
> Robert Muir and I were looking for a IVY-compatible solution (the original
> Oracle tool cannot be automatically downloaded by IVY, as Oracle's website
> sets cookies and requests license confirmations). We found the following
> GITHUB project by olamy/karianna:
> https://github.com/AdoptOpenJDK/JavadocUpdaterTool
> As soon as they release the JAR file officially on Maven, we can download it
> with IVY and use it. This is a Maven Plugin, but it still contains the
> original source code of Oracle's tool, so we can execute it as ANT task after
> loading the JAR with IVY's coordinates: {{}}
> In the GITHUB project description they note that you need JDK7 to use the
> tool, but this is no longer true, the -source/-target is Java 5 now, so we
> can run it easily.
> I will add the required tasks in common-build.xml's javadoc macro so it
> post-processes all javadocs and patches vulnerable files. If you build
> javadocs with a recent JDK, it would do nothing.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] [Comment Edited] (LUCENE-5072) Add Oracle's JavaDocsUpdater to build for fixing javadocs if generated with Java 6 (and Java 7 prior u25)
[
https://issues.apache.org/jira/browse/LUCENE-5072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13691258#comment-13691258
]
Uwe Schindler edited comment on LUCENE-5072 at 6/22/13 9:38 PM:
Cool, so we could maybe put the tool into our tools folder and use it from
there. The original Oracle tool has a forbidden-api problem: It used default
charset to process javadocs files :(
If LEGAL-171 does not solve the problem, we can use the Maven plugin as it is a
build tool (like we use svnkit or groovy for our builds) and not linked into
the product.
was (Author: thetaphi):
Cool, so we could maybe put the tool into our tools folder and use it from
there. The original Oracle tool has a forbidden-api problem: It used default
charset to process javadocs files :(
If LEGA-171 does not solve the problem, we can use the Maven plugin as it is a
build tool (like we use svnkit or groovy for our builds) and not linked into
the product.
> Add Oracle's JavaDocsUpdater to build for fixing javadocs if generated with
> Java 6 (and Java 7 prior u25)
> -
>
> Key: LUCENE-5072
> URL: https://issues.apache.org/jira/browse/LUCENE-5072
> Project: Lucene - Core
> Issue Type: Bug
> Components: general/build
>Affects Versions: 4.3.1
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: 5.0, 4.4
>
>
> The Apache Infra / Security team posted to all committers:
> {quote}
> Hi All,
> Oracle has announced [1], [2] a frame injection vulnerability in Javadoc
> generated by Java 5, Java 6 and Java 7 before update 22.
> [...]
> Please take the necessary steps to fix any currently published Javadoc and to
> ensure that any future Javadoc published by your project does not contain the
> vulnerability. The announcement by Oracle includes a link to a tool that can
> be used to fix Javadoc without regeneration.
> The infrastructure team is investigating options for preventing the
> publication of vulnerable Javadoc.
> The issue is public and may be discussed freely on your project's dev list.
> Thanks,
> Mark (ASF Infra)
> {quote}
> I fixed all published Javadocs on http://lucene.apache.org (for all historic
> releases where we have public available Javadocs on the web page).
> The mail also notes that we should not publish javadocs with this javadocs
> problem in the future. Unfortunately the release manager has to use the
> latest Java 7u25 version (released 2 days) ago. This would be fine for Lucene
> trunk (which is Java 7 only).
> But when we generate Javadocs JARs for Lucene 3 and 4, we cannot use Java 7
> (to build the official release) because the javadocs would contain e.g.
> AutoCloaseable interface unless we use a JDK 6 or 5 bootclasspath (like we do
> for web pages).
> We also want the lucene/solr-*-javadoc.jar files to be correct, but those are
> built with Java 5 (3.x) or Java 6 (4.x).
> Unfortunately Oracle does not relaese a newer JDK 5 or JDK 6, so its
> impossible to do a release.
> But Oracle publishes the binary and source code of a "fix tool", that can be
> run on top of a tree of HTML files, patching all broken files (and only
> those). You can run it theoretically on the root folder of your harddisk - I
> did this on the whole lucene.apache.org web site.
> Robert Muir and I were looking for a IVY-compatible solution (the original
> Oracle tool cannot be automatically downloaded by IVY, as Oracle's website
> sets cookies and requests license confirmations). We found the following
> GITHUB project by olamy/karianna:
> https://github.com/AdoptOpenJDK/JavadocUpdaterTool
> As soon as they release the JAR file officially on Maven, we can download it
> with IVY and use it. This is a Maven Plugin, but it still contains the
> original source code of Oracle's tool, so we can execute it as ANT task after
> loading the JAR with IVY's coordinates: {{}}
> In the GITHUB project description they note that you need JDK7 to use the
> tool, but this is no longer true, the -source/-target is Java 5 now, so we
> can run it easily.
> I will add the required tasks in common-build.xml's javadoc macro so it
> post-processes all javadocs and patches vulnerable files. If you build
> javadocs with a recent JDK, it would do nothing.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-5072) Add Oracle's JavaDocsUpdater to build for fixing javadocs if generated with Java 6 (and Java 7 prior u25)
[
https://issues.apache.org/jira/browse/LUCENE-5072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13691258#comment-13691258
]
Uwe Schindler commented on LUCENE-5072:
---
Cool, so we could maybe put the tool into our tools folder and use it from
there. The original Oracle tool has a forbidden-api problem: It used default
charset to process javadocs files :(
If LEGA-171 does not solve the problem, we can use the Maven plugin as it is a
build tool (like we use svnkit or groovy for our builds) and not linked into
the product.
> Add Oracle's JavaDocsUpdater to build for fixing javadocs if generated with
> Java 6 (and Java 7 prior u25)
> -
>
> Key: LUCENE-5072
> URL: https://issues.apache.org/jira/browse/LUCENE-5072
> Project: Lucene - Core
> Issue Type: Bug
> Components: general/build
>Affects Versions: 4.3.1
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: 5.0, 4.4
>
>
> The Apache Infra / Security team posted to all committers:
> {quote}
> Hi All,
> Oracle has announced [1], [2] a frame injection vulnerability in Javadoc
> generated by Java 5, Java 6 and Java 7 before update 22.
> [...]
> Please take the necessary steps to fix any currently published Javadoc and to
> ensure that any future Javadoc published by your project does not contain the
> vulnerability. The announcement by Oracle includes a link to a tool that can
> be used to fix Javadoc without regeneration.
> The infrastructure team is investigating options for preventing the
> publication of vulnerable Javadoc.
> The issue is public and may be discussed freely on your project's dev list.
> Thanks,
> Mark (ASF Infra)
> {quote}
> I fixed all published Javadocs on http://lucene.apache.org (for all historic
> releases where we have public available Javadocs on the web page).
> The mail also notes that we should not publish javadocs with this javadocs
> problem in the future. Unfortunately the release manager has to use the
> latest Java 7u25 version (released 2 days) ago. This would be fine for Lucene
> trunk (which is Java 7 only).
> But when we generate Javadocs JARs for Lucene 3 and 4, we cannot use Java 7
> (to build the official release) because the javadocs would contain e.g.
> AutoCloaseable interface unless we use a JDK 6 or 5 bootclasspath (like we do
> for web pages).
> We also want the lucene/solr-*-javadoc.jar files to be correct, but those are
> built with Java 5 (3.x) or Java 6 (4.x).
> Unfortunately Oracle does not relaese a newer JDK 5 or JDK 6, so its
> impossible to do a release.
> But Oracle publishes the binary and source code of a "fix tool", that can be
> run on top of a tree of HTML files, patching all broken files (and only
> those). You can run it theoretically on the root folder of your harddisk - I
> did this on the whole lucene.apache.org web site.
> Robert Muir and I were looking for a IVY-compatible solution (the original
> Oracle tool cannot be automatically downloaded by IVY, as Oracle's website
> sets cookies and requests license confirmations). We found the following
> GITHUB project by olamy/karianna:
> https://github.com/AdoptOpenJDK/JavadocUpdaterTool
> As soon as they release the JAR file officially on Maven, we can download it
> with IVY and use it. This is a Maven Plugin, but it still contains the
> original source code of Oracle's tool, so we can execute it as ANT task after
> loading the JAR with IVY's coordinates: {{}}
> In the GITHUB project description they note that you need JDK7 to use the
> tool, but this is no longer true, the -source/-target is Java 5 now, so we
> can run it easily.
> I will add the required tasks in common-build.xml's javadoc macro so it
> post-processes all javadocs and patches vulnerable files. If you build
> javadocs with a recent JDK, it would do nothing.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-5072) Add Oracle's JavaDocsUpdater to build for fixing javadocs if generated with Java 6 (and Java 7 prior u25)
[
https://issues.apache.org/jira/browse/LUCENE-5072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13691256#comment-13691256
]
Steve Rowe commented on LUCENE-5072:
bq. As soon as they release the JAR file officially on Maven, we can download
it with IVY and use it. This is a Maven Plugin, but it still contains the
original source code of Oracle's tool, so we can execute it as ANT task after
loading the JAR with IVY's coordinates:
See LEGAL-171, where they're discussing whether Apache can distribute this code.
> Add Oracle's JavaDocsUpdater to build for fixing javadocs if generated with
> Java 6 (and Java 7 prior u25)
> -
>
> Key: LUCENE-5072
> URL: https://issues.apache.org/jira/browse/LUCENE-5072
> Project: Lucene - Core
> Issue Type: Bug
> Components: general/build
>Affects Versions: 4.3.1
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: 5.0, 4.4
>
>
> The Apache Infra / Security team posted to all committers:
> {quote}
> Hi All,
> Oracle has announced [1], [2] a frame injection vulnerability in Javadoc
> generated by Java 5, Java 6 and Java 7 before update 22.
> [...]
> Please take the necessary steps to fix any currently published Javadoc and to
> ensure that any future Javadoc published by your project does not contain the
> vulnerability. The announcement by Oracle includes a link to a tool that can
> be used to fix Javadoc without regeneration.
> The infrastructure team is investigating options for preventing the
> publication of vulnerable Javadoc.
> The issue is public and may be discussed freely on your project's dev list.
> Thanks,
> Mark (ASF Infra)
> {quote}
> I fixed all published Javadocs on http://lucene.apache.org (for all historic
> releases where we have public available Javadocs on the web page).
> The mail also notes that we should not publish javadocs with this javadocs
> problem in the future. Unfortunately the release manager has to use the
> latest Java 7u25 version (released 2 days) ago. This would be fine for Lucene
> trunk (which is Java 7 only).
> But when we generate Javadocs JARs for Lucene 3 and 4, we cannot use Java 7
> (to build the official release) because the javadocs would contain e.g.
> AutoCloaseable interface unless we use a JDK 6 or 5 bootclasspath (like we do
> for web pages).
> We also want the lucene/solr-*-javadoc.jar files to be correct, but those are
> built with Java 5 (3.x) or Java 6 (4.x).
> Unfortunately Oracle does not relaese a newer JDK 5 or JDK 6, so its
> impossible to do a release.
> But Oracle publishes the binary and source code of a "fix tool", that can be
> run on top of a tree of HTML files, patching all broken files (and only
> those). You can run it theoretically on the root folder of your harddisk - I
> did this on the whole lucene.apache.org web site.
> Robert Muir and I were looking for a IVY-compatible solution (the original
> Oracle tool cannot be automatically downloaded by IVY, as Oracle's website
> sets cookies and requests license confirmations). We found the following
> GITHUB project by olamy/karianna:
> https://github.com/AdoptOpenJDK/JavadocUpdaterTool
> As soon as they release the JAR file officially on Maven, we can download it
> with IVY and use it. This is a Maven Plugin, but it still contains the
> original source code of Oracle's tool, so we can execute it as ANT task after
> loading the JAR with IVY's coordinates: {{}}
> In the GITHUB project description they note that you need JDK7 to use the
> tool, but this is no longer true, the -source/-target is Java 5 now, so we
> can run it easily.
> I will add the required tasks in common-build.xml's javadoc macro so it
> post-processes all javadocs and patches vulnerable files. If you build
> javadocs with a recent JDK, it would do nothing.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4947) geofilt gives wrong results (indexed polygons)
[
https://issues.apache.org/jira/browse/SOLR-4947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13691255#comment-13691255
]
Christian Winkler commented on SOLR-4947:
-
Thanks for the clarification and sorry that I have not found it in the FAQ. I
would never have thought of the inverted polygon as I was taking OpenStreetMap
for granted. Even the WKT plotter there plots the correct polygon.
Maybe it makes sense to mention OpenStreetMap explicitly in the FAQ as probably
many people will take data from there.
Thanks again
> geofilt gives wrong results (indexed polygons)
> --
>
> Key: SOLR-4947
> URL: https://issues.apache.org/jira/browse/SOLR-4947
> Project: Solr
> Issue Type: Bug
> Components: spatial
>Affects Versions: 4.3
> Environment: java version "1.7.0_15"
> OpenJDK Runtime Environment (IcedTea7 2.3.7) (7u15-2.3.7-0ubuntu1~12.04.1)
> OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
>Reporter: Christian Winkler
>Assignee: David Smiley
>Priority: Critical
>
> I have indexed (filtered) OpenStreetMap data for Germany including ways,
> total 3,855,159 documents, core is optimized.
> Queries contain some correct results but also (seemingly) arbitrary others:
> {noformat}
>
> 0
> 335
>
> true
> {!geofilt sfield=geo pt=49.434825,11.079835 d=1}
> 1371806261508
> xml
>
>
>
>
> w55380630
> POLYGON((7.342515 49.3058912, 7.3428923 49.3058912,
> 7.3428923 49.3057308, 7.342515 49.3057308, 7.342515 49.3058912)
> )
> place_of_worship
> Klinikkirche
> 1438312839527792640
>
> w77731561
> POLYGON((7.7563699 50.4972286, 7.7563699 50.4972296,
> 7.7563713 50.4972296, 7.7563713 50.4972286, 7.7563699 50.4972286)
> )
> [...]
> {noformat}
> 7.7° is not within 1km of 11.1°. It only happens with shapes.
> Indexing only a part of Germany the query works fine and produces the correct
> results.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4948) Tidy up CoreContainer construction logic
[ https://issues.apache.org/jira/browse/SOLR-4948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward updated SOLR-4948: Attachment: SOLR-4948.patch OK, think that's it; a combination of not setting dataDir properly on the TestHarness solr.xml, and checking for thrown exceptions rather than looking at CoreContainer.getCoreInitFailures(). Will run all tests again here, but I think this is ready to commit. > Tidy up CoreContainer construction logic > > > Key: SOLR-4948 > URL: https://issues.apache.org/jira/browse/SOLR-4948 > Project: Solr > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Minor > Attachments: SOLR-4948.patch, SOLR-4948.patch, SOLR-4948.patch > > > While writing tests for SOLR-4914, I discovered that it's *really difficult* > to create a CoreContainer. There are a bunch of constructors which > initialise different things, one (but only one!) of which also loads all the > cores. Then you have the Initializer object, which basically does the same > thing. Sort of. And then the TestHarness doesn't actually use > CoreContainer, but an anonymous subclass of CoreContainer which has it's own > initialisation logic. It would be nice to clean this up! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4921) Support for Adding Documents via the Solr UI
[ https://issues.apache.org/jira/browse/SOLR-4921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll updated SOLR-4921: -- Attachment: SOLR-4921.patch A bit more cleanup and fixed some issues with the Wizard. Renamed the Wizard to be "Document Builder" Added the plus button to the add field section. Ready for review, as I think this about done. > Support for Adding Documents via the Solr UI > > > Key: SOLR-4921 > URL: https://issues.apache.org/jira/browse/SOLR-4921 > Project: Solr > Issue Type: New Feature > Components: web gui >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 4.4 > > Attachments: SOLR-4921.patch, SOLR-4921.patch, SOLR-4921.patch, > SOLR-4921.patch, SOLR-4921.patch, SOLR-4921.patch, SOLR-4921.patch, > SOLR-4921.patch, SOLR-4921.patch, SOLR-4921.patch, SOLR-4921.patch, > SOLR-4921.patch, SOLR-4921.patch > > > For demos and prototyping, it would be nice if we could add documents via the > admin UI. > Various things to support: > 1. Uploading XML, JSON, CSV, etc. > 2. Optionally also do file upload -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4948) Tidy up CoreContainer construction logic
[ https://issues.apache.org/jira/browse/SOLR-4948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13691246#comment-13691246 ] Alan Woodward commented on SOLR-4948: - Actually, no, ignore that last comment. It's because the test is creating a core under test-files, rather than using the tmp datadir that it should be, so the locked index is in a completely different place to the core... > Tidy up CoreContainer construction logic > > > Key: SOLR-4948 > URL: https://issues.apache.org/jira/browse/SOLR-4948 > Project: Solr > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Minor > Attachments: SOLR-4948.patch, SOLR-4948.patch > > > While writing tests for SOLR-4914, I discovered that it's *really difficult* > to create a CoreContainer. There are a bunch of constructors which > initialise different things, one (but only one!) of which also loads all the > cores. Then you have the Initializer object, which basically does the same > thing. Sort of. And then the TestHarness doesn't actually use > CoreContainer, but an anonymous subclass of CoreContainer which has it's own > initialisation logic. It would be nice to clean this up! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4948) Tidy up CoreContainer construction logic
[ https://issues.apache.org/jira/browse/SOLR-4948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward updated SOLR-4948: Attachment: SOLR-4948.patch Latest patch. I still have two test failures in SolrCoreCheckLockOnStartupTest, which I think is due to the old TestHarness not using the normal load() logic and just creating a core on its own. The tests create an IndexWriter on a directory, and then try to open a new SolrCore over the same instance dir. This should fail, but it seems that the default DirectoryFactory notices that there's already an index there, and creates a new index_temp directory to hold the Core's index. Which means no exceptions get thrown, and the test passes. Will try and work out which DirectoryFactory was used before... > Tidy up CoreContainer construction logic > > > Key: SOLR-4948 > URL: https://issues.apache.org/jira/browse/SOLR-4948 > Project: Solr > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Minor > Attachments: SOLR-4948.patch, SOLR-4948.patch > > > While writing tests for SOLR-4914, I discovered that it's *really difficult* > to create a CoreContainer. There are a bunch of constructors which > initialise different things, one (but only one!) of which also loads all the > cores. Then you have the Initializer object, which basically does the same > thing. Sort of. And then the TestHarness doesn't actually use > CoreContainer, but an anonymous subclass of CoreContainer which has it's own > initialisation logic. It would be nice to clean this up! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] (LUCENE-5072) Add Oracle's JavaDocsUpdater to build for fixing javadocs if generated with Java 6 (and Java 7 prior u25)
[
https://issues.apache.org/jira/browse/LUCENE-5072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-5072:
--
Description:
The Apache Infra / Security team posted to all committers:
{quote}
Hi All,
Oracle has announced [1], [2] a frame injection vulnerability in Javadoc
generated by Java 5, Java 6 and Java 7 before update 22.
[...]
Please take the necessary steps to fix any currently published Javadoc and to
ensure that any future Javadoc published by your project does not contain the
vulnerability. The announcement by Oracle includes a link to a tool that can be
used to fix Javadoc without regeneration.
The infrastructure team is investigating options for preventing the publication
of vulnerable Javadoc.
The issue is public and may be discussed freely on your project's dev list.
Thanks,
Mark (ASF Infra)
{quote}
I fixed all published Javadocs on http://lucene.apache.org (for all historic
releases where we have public available Javadocs on the web page).
The mail also notes that we should not publish javadocs with this javadocs
problem in the future. Unfortunately the release manager has to use the latest
Java 7u25 version (released 2 days) ago. This would be fine for Lucene trunk
(which is Java 7 only).
But when we generate Javadocs JARs for Lucene 3 and 4, we cannot use Java 7 (to
build the official release) because the javadocs would contain e.g.
AutoCloaseable interface unless we use a JDK 6 or 5 bootclasspath (like we do
for web pages).
We also want the lucene/solr-*-javadoc.jar files to be correct, but those are
built with Java 5 (3.x) or Java 6 (4.x).
Unfortunately Oracle does not relaese a newer JDK 5 or JDK 6, so its impossible
to do a release.
But Oracle publishes the binary and source code of a "fix tool", that can be
run on top of a tree of HTML files, patching all broken files (and only those).
You can run it theoretically on the root folder of your harddisk - I did this
on the whole lucene.apache.org web site.
Robert Muir and I were looking for a IVY-compatible solution (the original
Oracle tool cannot be automatically downloaded by IVY, as Oracle's website sets
cookies and requests license confirmations). We found the following GITHUB
project by olamy/karianna:
https://github.com/AdoptOpenJDK/JavadocUpdaterTool
As soon as they release the JAR file officially on Maven, we can download it
with IVY and use it. This is a Maven Plugin, but it still contains the original
source code of Oracle's tool, so we can execute it as ANT task after loading
the JAR with IVY's coordinates: {{}}
In the GITHUB project description they note that you need JDK7 to use the tool,
but this is no longer true, the -source/-target is Java 5 now, so we can run it
easily.
I will add the required tasks in common-build.xml's javadoc macro so it
post-processes all javadocs and patches vulnerable files. If you build javadocs
with a recent JDK, it would do nothing.
was:
The Apache Infra / Security team posted to all committers:
{quote}
Hi All,
Oracle has announced [1], [2] a frame injection vulnerability in Javadoc
generated by Java 5, Java 6 and Java 7 before update 22.
[...]
Please take the necessary steps to fix any currently published Javadoc and to
ensure that any future Javadoc published by your project does not contain the
vulnerability. The announcement by Oracle includes a link to a tool that can be
used to fix Javadoc without regeneration.
The infrastructure team is investigating options for preventing the publication
of vulnerable Javadoc.
The issue is public and may be discussed freely on your project's dev list.
Thanks,
Mark (ASF Infra)
{quote}
I fixed all published Javadocs on http://lucene.apache.org (for all historic
releases where we have public available Javadocs on the web page).
The mail also notes that we should not publish javadocs with this javadocs
problem in the future. Unfortunately the release manager has to use the latest
Java 7u25 version (released 2 days) ago. This would be fine for Lucene trunk
(which is Java 7 only).
But when we generate Javadocs JARs for Lucene 3 and 4, we cannot use Java 7 (to
build the official release) because the javadocs would contain e.g.
AutoCloaseable interface unless we use a JDK 6 or 5 bootclasspath (like we do
for web pages).
We also want the lucene/solr-*-javadoc.jar files to be correct, but those are
built with Java 5 (3.x) or Java 6 (4.x).
Unfortunately Oracle does not relaese a newer JDK 5 or JDK 6, so its impossible
to do a release.
But Oracle publishes the binary and source code of a "fix tool", that can be
run on top of a tree of HTML files, patching all broken files (and only those).
You can run it theoretically on the root folder of your harddisk - i did this
on the whole lucene.apache.org web site.
Robert Muir and I were looking for a IVY-compatible solution (the tool cannot
be automa
[jira] [Created] (LUCENE-5072) Add Oracle's JavaDocsUpdater to build for fixing javadocs if generated with Java 6 (and Java 7 prior u25)
Uwe Schindler created LUCENE-5072:
-
Summary: Add Oracle's JavaDocsUpdater to build for fixing javadocs
if generated with Java 6 (and Java 7 prior u25)
Key: LUCENE-5072
URL: https://issues.apache.org/jira/browse/LUCENE-5072
Project: Lucene - Core
Issue Type: Bug
Components: general/build
Affects Versions: 4.3.1
Reporter: Uwe Schindler
Assignee: Uwe Schindler
Fix For: 5.0, 4.4
The Apache Infra / Security team posted to all committers:
{quote}
Hi All,
Oracle has announced [1], [2] a frame injection vulnerability in Javadoc
generated by Java 5, Java 6 and Java 7 before update 22.
[...]
Please take the necessary steps to fix any currently published Javadoc and to
ensure that any future Javadoc published by your project does not contain the
vulnerability. The announcement by Oracle includes a link to a tool that can be
used to fix Javadoc without regeneration.
The infrastructure team is investigating options for preventing the publication
of vulnerable Javadoc.
The issue is public and may be discussed freely on your project's dev list.
Thanks,
Mark (ASF Infra)
{quote}
I fixed all published Javadocs on http://lucene.apache.org (for all historic
releases where we have public available Javadocs on the web page).
The mail also notes that we should not publish javadocs with this javadocs
problem in the future. Unfortunately the release manager has to use the latest
Java 7u25 version (released 2 days) ago. This would be fine for Lucene trunk
(which is Java 7 only).
But when we generate Javadocs JARs for Lucene 3 and 4, we cannot use Java 7 (to
build the official release) because the javadocs would contain e.g.
AutoCloaseable interface unless we use a JDK 6 or 5 bootclasspath (like we do
for web pages).
We also want the lucene/solr-*-javadoc.jar files to be correct, but those are
built with Java 5 (3.x) or Java 6 (4.x).
Unfortunately Oracle does not relaese a newer JDK 5 or JDK 6, so its impossible
to do a release.
But Oracle publishes the binary and source code of a "fix tool", that can be
run on top of a tree of HTML files, patching all broken files (and only those).
You can run it theoretically on the root folder of your harddisk - i did this
on the whole lucene.apache.org web site.
Robert Muir and I were looking for a IVY-compatible solution (the tool cannot
be automatically downloaded by IVY, as Oracle's website sets cookies and
requests license confirmations), and we found the following GITHUB project by
olamy/karianna:
https://github.com/AdoptOpenJDK/JavadocUpdaterTool
As soon as they release the JAR file officially on Maven, we can download it
with IVY and use it. This is a Maven Plugin, but it still contains the original
source code of Oracle's tool, so we can execute it as ANT task after loading
the JAR with IVY's coordinates: {{}}
I will add the required tasks in common-build.xml's javadoc macro so it
post-processes all javadocs and patches vulnerable files. If you build javadocs
with a recent JDK, it would do nothing.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4943) Add a new info admin handler.
[ https://issues.apache.org/jira/browse/SOLR-4943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13691230#comment-13691230 ] Mark Miller commented on SOLR-4943: --- bq. Sorry, I didn't mean remove the URLs with the cores on them, I meant the constructor functions. Yes, I know, but the two are very related ;) bq. So for example InfoHandler has a no-argument constructor, that sets this.cc to null. Right, like I said, that's a copy paste from the CoreAdmin class - it can likely go. bq. because they could be defined in solrconfig.xml as request handlers, and need to go through the normal construct/init/inform lifecycle. Exactly. This issue is not about removing the per core admin info - it's just about adding that info at the system level so that the UI can be reasonable when no SolrCores are defined. > Add a new info admin handler. > - > > Key: SOLR-4943 > URL: https://issues.apache.org/jira/browse/SOLR-4943 > Project: Solr > Issue Type: Improvement >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 5.0, 4.4 > > Attachments: SOLR-4943-2.patch, SOLR-4943-3.patch, SOLR-4943.patch > > > Currently, you have to specify a core to get system information for a variety > of request handlers - properties, logging, thread dump, system, etc. > These should be available at a system location and not core specific location. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4943) Add a new info admin handler.
[ https://issues.apache.org/jira/browse/SOLR-4943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13691228#comment-13691228 ] Alan Woodward commented on SOLR-4943: - Sorry, I didn't mean remove the URLs with the cores on them, I meant the constructor functions. The URLs are all intercepted by SolrDispatchFilter and passed to the handlers on CoreContainer anyway, and that's fine. So for example InfoHandler has a no-argument constructor, that sets this.cc to null. If you use this constructor, you can never get useful information out of the InfoHandler - it will always throw a SolrException. So it seems a bit pointless to have this constructor at all. Also, some of these probably don't need to take CoreContainers at all. SystemInfoHandler just uses it to determine if it's Zk-aware or not, which it could do as easily with a boolean passed to its constructor. LoggingHandler could take a LogWatcher rather than a CoreContainer. Makes it easier to test things, for a start. OIC, looking at it more closely, they need the no-arg constructors because they could be defined in solrconfig.xml as request handlers, and need to go through the normal construct/init/inform lifecycle. So yes, we should probably open another issue to deprecate defining the handlers that are container-wide in individual core configs. > Add a new info admin handler. > - > > Key: SOLR-4943 > URL: https://issues.apache.org/jira/browse/SOLR-4943 > Project: Solr > Issue Type: Improvement >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 5.0, 4.4 > > Attachments: SOLR-4943-2.patch, SOLR-4943-3.patch, SOLR-4943.patch > > > Currently, you have to specify a core to get system information for a variety > of request handlers - properties, logging, thread dump, system, etc. > These should be available at a system location and not core specific location. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-5049) Native (C++) implementation of "pure OR" BooleanQuery
[
https://issues.apache.org/jira/browse/LUCENE-5049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13691206#comment-13691206
]
Michael McCandless commented on LUCENE-5049:
OK, fair enough Uwe ... I've continued this effort at
https://github.com/mikemccand/lucene-c-boost and wrote a blog post about it at
http://blog.mikemccandless.com/2013/06/screaming-fast-lucene-searches-using-c.html
> Native (C++) implementation of "pure OR" BooleanQuery
> -
>
> Key: LUCENE-5049
> URL: https://issues.apache.org/jira/browse/LUCENE-5049
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Attachments: LUCENE-5049.patch
>
>
> I've been playing with a C++ implementation of BooleanQuery containing
> only OR'd (SHOULD) TermQuery clauses, collecting top N hits by score.
> The results are impressive: ~3X speedup for BQ OR over two terms, and
> also good speedups (~38-78%) for Fuzzy1/2 as well since they rewrite
> to BQ OR over N terms:
> {noformat}
> TaskQPS base StdDevQPS comp StdDev
> Pct diff
> MedTerm 69.47 (15.8%) 68.61 (13.4%)
> -1.2% ( -26% - 33%)
> HighTerm 55.25 (16.2%) 54.63 (13.9%)
> -1.1% ( -26% - 34%)
> LowTerm 333.10 (9.6%) 329.43 (8.0%)
> -1.1% ( -17% - 18%)
> IntNRQ3.37 (2.6%)3.36 (4.6%)
> -0.2% ( -7% -7%)
> Prefix3 18.91 (2.0%) 19.04 (3.5%)
> 0.7% ( -4% -6%)
> Wildcard 29.40 (1.7%) 29.70 (2.8%)
> 1.0% ( -3% -5%)
>MedPhrase 132.69 (6.2%) 134.66 (7.0%)
> 1.5% ( -11% - 15%)
> HighSloppyPhrase0.82 (3.6%)0.83 (3.5%)
> 1.9% ( -5% -9%)
> AndHighHigh 19.65 (0.6%) 20.02 (0.8%)
> 1.9% ( 0% -3%)
> HighPhrase 11.74 (6.6%) 11.96 (7.1%)
> 1.9% ( -11% - 16%)
> MedSloppyPhrase 29.09 (1.2%) 29.76 (1.9%)
> 2.3% ( 0% -5%)
> LowSloppyPhrase 25.71 (1.4%) 26.98 (1.7%)
> 4.9% ( 1% -8%)
> Respell 173.78 (3.0%) 182.41 (3.7%)
> 5.0% ( -1% - 12%)
> MedSpanNear 27.67 (2.5%) 29.07 (2.4%)
> 5.1% ( 0% - 10%)
> HighSpanNear2.95 (2.4%)3.10 (2.8%)
> 5.4% ( 0% - 10%)
> LowSpanNear8.29 (3.4%)8.82 (3.3%)
> 6.4% ( 0% - 13%)
> AndHighMed 79.32 (1.6%) 84.44 (1.0%)
> 6.5% ( 3% -9%)
>LowPhrase 23.20 (2.0%) 25.14 (1.6%)
> 8.4% ( 4% - 12%)
> AndHighLow 594.17 (3.4%) 660.32 (1.9%)
> 11.1% ( 5% - 16%)
> Fuzzy2 88.32 (6.4%) 121.44 (1.7%)
> 37.5% ( 27% - 48%)
> Fuzzy1 86.34 (6.0%) 153.49 (1.7%)
> 77.8% ( 66% - 90%)
> OrHighHigh 16.29 (2.5%) 48.29 (1.3%)
> 196.5% ( 188% - 205%)
>OrHighMed 28.98 (2.7%) 87.81 (0.9%)
> 203.0% ( 194% - 212%)
>OrHighLow 27.38 (2.6%) 84.94 (1.1%)
> 210.3% ( 201% - 219%)
> {noformat}
> This is essentially a scaled back attempt at LUCENE-1594 in that it's
> "hardwired" to "just" the "OR of TermQuery" case.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4760) Improve logging messages during startup to better identify core
[
https://issues.apache.org/jira/browse/SOLR-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13691202#comment-13691202
]
Shawn Heisey commented on SOLR-4760:
[~arafalov] It did make it into 4.3.1, but it only affected the error message
about the schema not having a name. The message you are seeing (about the
unique key field) wasn't changed. If you want to file a new issue, I will take
another look when I have time.
> Improve logging messages during startup to better identify core
> ---
>
> Key: SOLR-4760
> URL: https://issues.apache.org/jira/browse/SOLR-4760
> Project: Solr
> Issue Type: Wish
> Components: Schema and Analysis
>Affects Versions: 4.3
>Reporter: Alexandre Rafalovitch
>Assignee: Shawn Heisey
>Priority: Minor
> Fix For: 5.0, 4.4, 4.3.1
>
> Attachments: SOLR-4760.patch, SOLR-4760.patch, SOLR-4760-testfix.patch
>
>
> Some log messages could be more informative. For example:
> {code}
> 680 [coreLoadExecutor-3-thread-3] WARN org.apache.solr.schema.IndexSchema –
> schema has no name!
> {code}
> Would be _very nice_ to know which core this is complaining about.
> Later, once the core is loaded, the core name shows up in the logs,
> but it would be nice to have it earlier without having to
> triangulating it through 'Loading core' messages.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] (LUCENE-4890) QueryTreeBuilder.getBuilder() only finds interfaces on the most derived class
[
https://issues.apache.org/jira/browse/LUCENE-4890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adriano Crestani resolved LUCENE-4890.
--
Resolution: Fixed
> QueryTreeBuilder.getBuilder() only finds interfaces on the most derived class
> -
>
> Key: LUCENE-4890
> URL: https://issues.apache.org/jira/browse/LUCENE-4890
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/queryparser
>Affects Versions: 2.9, 2.9.1, 2.9.2, 2.9.3, 2.9.4, 3.0, 3.0.1, 3.0.2,
> 3.0.3, 3.1, 3.2, 3.3, 3.4, 3.5, 3.6, 3.6.1, 3.6.2
> Environment: Lucene 3.3.0 on Win32
>Reporter: Philip Searle
>Assignee: Adriano Crestani
>Priority: Minor
> Fix For: 5.0, 3.6.3, 4.4
>
> Attachments: LUCENE-4890_2013_05_25.patch
>
>
> QueryBuilder implementations registered with QueryTreeBuilder.setBuilder()
> are not recognized by QueryTreeBuilder.getBuilder() if they are registered
> for an interface implemented by a superclass. Registering them for a concrete
> query node class or an interface implemented by the most-derived class do
> work.
> {code:title=example.java|borderStyle=solid}
> /* Our custom query builder */
> class CustomQueryTreeBuilder extends QueryTreeBuilder {
> public CustomQueryTreeBuilder() {
> /* Turn field:"value" into an application-specific object */
> setBuilder(FieldQueryNode.class, new QueryBuilder() {
> @Override
> public Object build(QueryNode queryNode) {
> FieldQueryNode node = (FieldQueryNode) queryNode;
> return new ApplicationSpecificClass(node.getFieldAsString());
> }
> });
> /* Ignore all other query node types */
> setBuilder(QueryNode.class, new QueryBuilder() {
> @Override
> public Object build(QueryNode queryNode) {
> return null;
> }
> });
> }
> }
> /* Assume this is in the main program: */
> StandardQueryParser queryParser = new StandardQueryParser();
> queryParser.setQueryBuilder(new CustomQueryTreeBuilder());
> /* The following line will throw an exception because it can't find a builder
> for BooleanQueryNode.class */
> Object queryObject = queryParser.parse("field:\"value\" field2:\"value2\"",
> "field");
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] (LUCENE-4890) QueryTreeBuilder.getBuilder() only finds interfaces on the most derived class
[
https://issues.apache.org/jira/browse/LUCENE-4890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adriano Crestani updated LUCENE-4890:
-
Fix Version/s: 4.4
3.6.3
5.0
Affects Version/s: 2.9
2.9.1
2.9.2
2.9.3
2.9.4
3.0
3.0.1
3.0.2
3.0.3
3.1
3.2
3.4
3.5
3.6
3.6.1
3.6.2
> QueryTreeBuilder.getBuilder() only finds interfaces on the most derived class
> -
>
> Key: LUCENE-4890
> URL: https://issues.apache.org/jira/browse/LUCENE-4890
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/queryparser
>Affects Versions: 2.9, 2.9.1, 2.9.2, 2.9.3, 2.9.4, 3.0, 3.0.1, 3.0.2,
> 3.0.3, 3.1, 3.2, 3.3, 3.4, 3.5, 3.6, 3.6.1, 3.6.2
> Environment: Lucene 3.3.0 on Win32
>Reporter: Philip Searle
>Assignee: Adriano Crestani
>Priority: Minor
> Fix For: 5.0, 3.6.3, 4.4
>
> Attachments: LUCENE-4890_2013_05_25.patch
>
>
> QueryBuilder implementations registered with QueryTreeBuilder.setBuilder()
> are not recognized by QueryTreeBuilder.getBuilder() if they are registered
> for an interface implemented by a superclass. Registering them for a concrete
> query node class or an interface implemented by the most-derived class do
> work.
> {code:title=example.java|borderStyle=solid}
> /* Our custom query builder */
> class CustomQueryTreeBuilder extends QueryTreeBuilder {
> public CustomQueryTreeBuilder() {
> /* Turn field:"value" into an application-specific object */
> setBuilder(FieldQueryNode.class, new QueryBuilder() {
> @Override
> public Object build(QueryNode queryNode) {
> FieldQueryNode node = (FieldQueryNode) queryNode;
> return new ApplicationSpecificClass(node.getFieldAsString());
> }
> });
> /* Ignore all other query node types */
> setBuilder(QueryNode.class, new QueryBuilder() {
> @Override
> public Object build(QueryNode queryNode) {
> return null;
> }
> });
> }
> }
> /* Assume this is in the main program: */
> StandardQueryParser queryParser = new StandardQueryParser();
> queryParser.setQueryBuilder(new CustomQueryTreeBuilder());
> /* The following line will throw an exception because it can't find a builder
> for BooleanQueryNode.class */
> Object queryObject = queryParser.parse("field:\"value\" field2:\"value2\"",
> "field");
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] [Closed] (SOLR-4947) geofilt gives wrong results (indexed polygons)
[
https://issues.apache.org/jira/browse/SOLR-4947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley closed SOLR-4947.
--
Resolution: Not A Problem
> geofilt gives wrong results (indexed polygons)
> --
>
> Key: SOLR-4947
> URL: https://issues.apache.org/jira/browse/SOLR-4947
> Project: Solr
> Issue Type: Bug
> Components: spatial
>Affects Versions: 4.3
> Environment: java version "1.7.0_15"
> OpenJDK Runtime Environment (IcedTea7 2.3.7) (7u15-2.3.7-0ubuntu1~12.04.1)
> OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
>Reporter: Christian Winkler
>Assignee: David Smiley
>Priority: Critical
>
> I have indexed (filtered) OpenStreetMap data for Germany including ways,
> total 3,855,159 documents, core is optimized.
> Queries contain some correct results but also (seemingly) arbitrary others:
> {noformat}
>
> 0
> 335
>
> true
> {!geofilt sfield=geo pt=49.434825,11.079835 d=1}
> 1371806261508
> xml
>
>
>
>
> w55380630
> POLYGON((7.342515 49.3058912, 7.3428923 49.3058912,
> 7.3428923 49.3057308, 7.342515 49.3057308, 7.342515 49.3058912)
> )
> place_of_worship
> Klinikkirche
> 1438312839527792640
>
> w77731561
> POLYGON((7.7563699 50.4972286, 7.7563699 50.4972296,
> 7.7563713 50.4972296, 7.7563713 50.4972286, 7.7563699 50.4972286)
> )
> [...]
> {noformat}
> 7.7° is not within 1km of 11.1°. It only happens with shapes.
> Indexing only a part of Germany the query works fine and produces the correct
> results.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4947) geofilt gives wrong results (indexed polygons)
[
https://issues.apache.org/jira/browse/SOLR-4947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley updated SOLR-4947:
---
Summary: geofilt gives wrong results (indexed polygons) (was: geofilt
gives wrong results)
> geofilt gives wrong results (indexed polygons)
> --
>
> Key: SOLR-4947
> URL: https://issues.apache.org/jira/browse/SOLR-4947
> Project: Solr
> Issue Type: Bug
> Components: spatial
>Affects Versions: 4.3
> Environment: java version "1.7.0_15"
> OpenJDK Runtime Environment (IcedTea7 2.3.7) (7u15-2.3.7-0ubuntu1~12.04.1)
> OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
>Reporter: Christian Winkler
>Assignee: David Smiley
>Priority: Critical
>
> I have indexed (filtered) OpenStreetMap data for Germany including ways,
> total 3,855,159 documents, core is optimized.
> Queries contain some correct results but also (seemingly) arbitrary others:
> {noformat}
>
> 0
> 335
>
> true
> {!geofilt sfield=geo pt=49.434825,11.079835 d=1}
> 1371806261508
> xml
>
>
>
>
> w55380630
> POLYGON((7.342515 49.3058912, 7.3428923 49.3058912,
> 7.3428923 49.3057308, 7.342515 49.3057308, 7.342515 49.3058912)
> )
> place_of_worship
> Klinikkirche
> 1438312839527792640
>
> w77731561
> POLYGON((7.7563699 50.4972286, 7.7563699 50.4972296,
> 7.7563713 50.4972296, 7.7563713 50.4972286, 7.7563699 50.4972286)
> )
> [...]
> {noformat}
> 7.7° is not within 1km of 11.1°. It only happens with shapes.
> Indexing only a part of Germany the query works fine and produces the correct
> results.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] [Comment Edited] (SOLR-4947) geofilt gives wrong results
[
https://issues.apache.org/jira/browse/SOLR-4947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13691159#comment-13691159
]
David Smiley edited comment on SOLR-4947 at 6/22/13 1:59 PM:
-
bq. Is there any way to show the distance without scoring? As soon as I switch
on the score=distance I get an OOM.
Returning the distance will only work for points that you index, not polygons.
And furthermore, the implementation in RPT doesn't scale well. If you can use
one point per document (perhaps the center point of your shape), then put that
in a LatLonType field and use that. And set the dynamic field "*_coordinate"
to be a tfloat to save you memory.
was (Author: dsmiley):
bq. Is there any way to show the distance without scoring? As soon as I
switch on the score=distance I get an OOM.
Returning the distance will only work for points that you index, not polygons.
And furthermore, the implementation in PRT doesn't scale well. If you can use
one point per document (perhaps the center point of your shape), then put that
in a LatLonType field and use that. And set the dynamic field "*_coordinate"
to be a tfloat to save you memory.
> geofilt gives wrong results
> ---
>
> Key: SOLR-4947
> URL: https://issues.apache.org/jira/browse/SOLR-4947
> Project: Solr
> Issue Type: Bug
> Components: spatial
>Affects Versions: 4.3
> Environment: java version "1.7.0_15"
> OpenJDK Runtime Environment (IcedTea7 2.3.7) (7u15-2.3.7-0ubuntu1~12.04.1)
> OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
>Reporter: Christian Winkler
>Assignee: David Smiley
>Priority: Critical
>
> I have indexed (filtered) OpenStreetMap data for Germany including ways,
> total 3,855,159 documents, core is optimized.
> Queries contain some correct results but also (seemingly) arbitrary others:
> {noformat}
>
> 0
> 335
>
> true
> {!geofilt sfield=geo pt=49.434825,11.079835 d=1}
> 1371806261508
> xml
>
>
>
>
> w55380630
> POLYGON((7.342515 49.3058912, 7.3428923 49.3058912,
> 7.3428923 49.3057308, 7.342515 49.3057308, 7.342515 49.3058912)
> )
> place_of_worship
> Klinikkirche
> 1438312839527792640
>
> w77731561
> POLYGON((7.7563699 50.4972286, 7.7563699 50.4972296,
> 7.7563713 50.4972296, 7.7563713 50.4972286, 7.7563699 50.4972286)
> )
> [...]
> {noformat}
> 7.7° is not within 1km of 11.1°. It only happens with shapes.
> Indexing only a part of Germany the query works fine and produces the correct
> results.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4947) geofilt gives wrong results
[
https://issues.apache.org/jira/browse/SOLR-4947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13691159#comment-13691159
]
David Smiley commented on SOLR-4947:
bq. Is there any way to show the distance without scoring? As soon as I switch
on the score=distance I get an OOM.
Returning the distance will only work for points that you index, not polygons.
And furthermore, the implementation in PRT doesn't scale well. If you can use
one point per document (perhaps the center point of your shape), then put that
in a LatLonType field and use that. And set the dynamic field "*_coordinate"
to be a tfloat to save you memory.
> geofilt gives wrong results
> ---
>
> Key: SOLR-4947
> URL: https://issues.apache.org/jira/browse/SOLR-4947
> Project: Solr
> Issue Type: Bug
> Components: spatial
>Affects Versions: 4.3
> Environment: java version "1.7.0_15"
> OpenJDK Runtime Environment (IcedTea7 2.3.7) (7u15-2.3.7-0ubuntu1~12.04.1)
> OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
>Reporter: Christian Winkler
>Assignee: David Smiley
>Priority: Critical
>
> I have indexed (filtered) OpenStreetMap data for Germany including ways,
> total 3,855,159 documents, core is optimized.
> Queries contain some correct results but also (seemingly) arbitrary others:
> {noformat}
>
> 0
> 335
>
> true
> {!geofilt sfield=geo pt=49.434825,11.079835 d=1}
> 1371806261508
> xml
>
>
>
>
> w55380630
> POLYGON((7.342515 49.3058912, 7.3428923 49.3058912,
> 7.3428923 49.3057308, 7.342515 49.3057308, 7.342515 49.3058912)
> )
> place_of_worship
> Klinikkirche
> 1438312839527792640
>
> w77731561
> POLYGON((7.7563699 50.4972286, 7.7563699 50.4972296,
> 7.7563713 50.4972296, 7.7563713 50.4972286, 7.7563699 50.4972286)
> )
> [...]
> {noformat}
> 7.7° is not within 1km of 11.1°. It only happens with shapes.
> Indexing only a part of Germany the query works fine and produces the correct
> results.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4947) geofilt gives wrong results
[
https://issues.apache.org/jira/browse/SOLR-4947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13691157#comment-13691157
]
David Smiley commented on SOLR-4947:
Glad to be of help, Christian.
I thought the problem was precision but, no, that was not it. Your polygon is
a rectangle, and such polygons must follow the counter-clockwise order rule.
The WKT spec says this is how it needs to be, although apparently most software
out there appears to work by allowing either order and limiting rects to < 180
degrees. Spatial4j follows the spec but in its next release I plan to have it
not do this so that it is more compatible. This is a very common issue people
hit and [it's in the
FAQ|http://wiki.apache.org/solr/SolrAdaptersForLuceneSpatial4#JTS_.2F_WKT_.2F_Polygon_notes]
(see "Common Error").
Because it was in the wrong order, the rectangle loops the other way around the
world, and because it's now a bigger shape than intended it's also gridded to
larger grid cells.
To see what the problem was, I brought up the [spatial solr sandbox (spatial
demo)|https://github.com/ryantxu/spatial-solr-sandbox] and had it plot your
polygon in Google Earth. You can watch me do this as part of a [bigger
presentation|http://www.youtube.com/watch?v=L2cUGv0Rebs] on spatial I did at
Lucene Revolution.
> geofilt gives wrong results
> ---
>
> Key: SOLR-4947
> URL: https://issues.apache.org/jira/browse/SOLR-4947
> Project: Solr
> Issue Type: Bug
> Components: spatial
>Affects Versions: 4.3
> Environment: java version "1.7.0_15"
> OpenJDK Runtime Environment (IcedTea7 2.3.7) (7u15-2.3.7-0ubuntu1~12.04.1)
> OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
>Reporter: Christian Winkler
>Assignee: David Smiley
>Priority: Critical
>
> I have indexed (filtered) OpenStreetMap data for Germany including ways,
> total 3,855,159 documents, core is optimized.
> Queries contain some correct results but also (seemingly) arbitrary others:
> {noformat}
>
> 0
> 335
>
> true
> {!geofilt sfield=geo pt=49.434825,11.079835 d=1}
> 1371806261508
> xml
>
>
>
>
> w55380630
> POLYGON((7.342515 49.3058912, 7.3428923 49.3058912,
> 7.3428923 49.3057308, 7.342515 49.3057308, 7.342515 49.3058912)
> )
> place_of_worship
> Klinikkirche
> 1438312839527792640
>
> w77731561
> POLYGON((7.7563699 50.4972286, 7.7563699 50.4972296,
> 7.7563713 50.4972296, 7.7563713 50.4972286, 7.7563699 50.4972286)
> )
> [...]
> {noformat}
> 7.7° is not within 1km of 11.1°. It only happens with shapes.
> Indexing only a part of Germany the query works fine and produces the correct
> results.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4760) Improve logging messages during startup to better identify core
[
https://issues.apache.org/jira/browse/SOLR-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13691129#comment-13691129
]
Alexandre Rafalovitch commented on SOLR-4760:
-
Has this actually made it into 4.3.1? Because I am not seeing any difference:
[coreLoadExecutor-3-thread-1] INFO org.apache.solr.core.SolrResourceLoader
– Adding
'file:/Users/arafalov/SOLR/solr-4.3.1/contrib/analysis-extras/lucene-libs/lucene-analyzers-morfologik-4.3.1.jar'
to classloader
[coreLoadExecutor-3-thread-2] INFO org.apache.solr.schema.IndexSchema –
unique key field: id
> Improve logging messages during startup to better identify core
> ---
>
> Key: SOLR-4760
> URL: https://issues.apache.org/jira/browse/SOLR-4760
> Project: Solr
> Issue Type: Wish
> Components: Schema and Analysis
>Affects Versions: 4.3
>Reporter: Alexandre Rafalovitch
>Assignee: Shawn Heisey
>Priority: Minor
> Fix For: 5.0, 4.4, 4.3.1
>
> Attachments: SOLR-4760.patch, SOLR-4760.patch, SOLR-4760-testfix.patch
>
>
> Some log messages could be more informative. For example:
> {code}
> 680 [coreLoadExecutor-3-thread-3] WARN org.apache.solr.schema.IndexSchema –
> schema has no name!
> {code}
> Would be _very nice_ to know which core this is complaining about.
> Later, once the core is loaded, the core name shows up in the logs,
> but it would be nice to have it earlier without having to
> triangulating it through 'Loading core' messages.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4921) Support for Adding Documents via the Solr UI
[ https://issues.apache.org/jira/browse/SOLR-4921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll updated SOLR-4921: -- Attachment: SOLR-4921.patch Rethought the Wizard a bit. Should be working now. Steps: # Select the Wizard from the Doc Type drop down # Choose your field # Fill in text area # Hit "Add Field" # repeat until done # Hit submit document when the doc is complete This uses the same pathway as the JSON option when submitting. > Support for Adding Documents via the Solr UI > > > Key: SOLR-4921 > URL: https://issues.apache.org/jira/browse/SOLR-4921 > Project: Solr > Issue Type: New Feature > Components: web gui >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 4.4 > > Attachments: SOLR-4921.patch, SOLR-4921.patch, SOLR-4921.patch, > SOLR-4921.patch, SOLR-4921.patch, SOLR-4921.patch, SOLR-4921.patch, > SOLR-4921.patch, SOLR-4921.patch, SOLR-4921.patch, SOLR-4921.patch, > SOLR-4921.patch > > > For demos and prototyping, it would be nice if we could add documents via the > admin UI. > Various things to support: > 1. Uploading XML, JSON, CSV, etc. > 2. Optionally also do file upload -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4921) Support for Adding Documents via the Solr UI
[ https://issues.apache.org/jira/browse/SOLR-4921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll updated SOLR-4921: -- Attachment: SOLR-4921.patch A start on the wizard. > Support for Adding Documents via the Solr UI > > > Key: SOLR-4921 > URL: https://issues.apache.org/jira/browse/SOLR-4921 > Project: Solr > Issue Type: New Feature > Components: web gui >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 4.4 > > Attachments: SOLR-4921.patch, SOLR-4921.patch, SOLR-4921.patch, > SOLR-4921.patch, SOLR-4921.patch, SOLR-4921.patch, SOLR-4921.patch, > SOLR-4921.patch, SOLR-4921.patch, SOLR-4921.patch, SOLR-4921.patch > > > For demos and prototyping, it would be nice if we could add documents via the > admin UI. > Various things to support: > 1. Uploading XML, JSON, CSV, etc. > 2. Optionally also do file upload -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4.x-MacOSX (64bit/jdk1.7.0) - Build # 569 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-MacOSX/569/ Java: 64bit/jdk1.7.0 -XX:-UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: org.apache.solr.client.solrj.TestBatchUpdate.testWithXml Error Message: IOException occured when talking to server at: https://127.0.0.1:53543/solr/collection1 Stack Trace: org.apache.solr.client.solrj.SolrServerException: IOException occured when talking to server at: https://127.0.0.1:53543/solr/collection1 at __randomizedtesting.SeedInfo.seed([8801ABA9740DFBBB:23E3125FF60BE2D6]:0) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:435) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180) at org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(AbstractUpdateRequest.java:117) at org.apache.solr.client.solrj.SolrServer.commit(SolrServer.java:168) at org.apache.solr.client.solrj.SolrServer.commit(SolrServer.java:146) at org.apache.solr.client.solrj.TestBatchUpdate.doIt(TestBatchUpdate.java:130) at org.apache.solr.client.solrj.TestBatchUpdate.testWithXml(TestBatchUpdate.java:54) 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:601) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.e
[jira] [Commented] (SOLR-4947) geofilt gives wrong results
[
https://issues.apache.org/jira/browse/SOLR-4947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13691087#comment-13691087
]
Christian Winkler commented on SOLR-4947:
-
Thanks for your super fast reply David.
Indeed I have played with the precision. However the polygon "Klinikkirche"
(which is a church) has a dimension of only a few hundred square meters whereas
the filter requests a 1km distance of an object which is a few hundred (!)
kilometers away. So I don't think it is related to the precision.
Indexing at the moment takes already one day and the index is about 12 GB. I
suspect that it will take considerably longer with higher precision and lead to
a much larger index. But sure I can give it a try.
Is there any way to show the distance without scoring? As soon as I switch on
the score=distance I get an OOM.
> geofilt gives wrong results
> ---
>
> Key: SOLR-4947
> URL: https://issues.apache.org/jira/browse/SOLR-4947
> Project: Solr
> Issue Type: Bug
> Components: spatial
>Affects Versions: 4.3
> Environment: java version "1.7.0_15"
> OpenJDK Runtime Environment (IcedTea7 2.3.7) (7u15-2.3.7-0ubuntu1~12.04.1)
> OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
>Reporter: Christian Winkler
>Assignee: David Smiley
>Priority: Critical
>
> I have indexed (filtered) OpenStreetMap data for Germany including ways,
> total 3,855,159 documents, core is optimized.
> Queries contain some correct results but also (seemingly) arbitrary others:
> {noformat}
>
> 0
> 335
>
> true
> {!geofilt sfield=geo pt=49.434825,11.079835 d=1}
> 1371806261508
> xml
>
>
>
>
> w55380630
> POLYGON((7.342515 49.3058912, 7.3428923 49.3058912,
> 7.3428923 49.3057308, 7.342515 49.3057308, 7.342515 49.3058912)
> )
> place_of_worship
> Klinikkirche
> 1438312839527792640
>
> w77731561
> POLYGON((7.7563699 50.4972286, 7.7563699 50.4972296,
> 7.7563713 50.4972296, 7.7563713 50.4972286, 7.7563699 50.4972286)
> )
> [...]
> {noformat}
> 7.7° is not within 1km of 11.1°. It only happens with shapes.
> Indexing only a part of Germany the query works fine and produces the correct
> results.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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
PMC Chair change
Hi all, most of you will already know it: Since June 19, 2013, I am the new Project Management Committee Chair, replacing Steve Rowe. I am glad to manage all the legal stuff for new committers or contributions from external entities - and also preparing the board reports. All this, of course and as always, with included but not deliberate @UweSays quotations. Many thanks to all PMC members who have voted for me! Many thanks to Steve for the help and hints to all the things I have to know in my new role! Uwe - Uwe Schindler uschind...@apache.org Apache Lucene PMC Chair / Committer Bremen, Germany http://lucene.apache.org/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2242) Get distinct count of names for a facet field
[
https://issues.apache.org/jira/browse/SOLR-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13691078#comment-13691078
]
J Mohamed Zahoor commented on SOLR-2242:
One way to achieve this in distributed environment is to have some
approximation techniques like HyperLogLog.
> Get distinct count of names for a facet field
> -
>
> Key: SOLR-2242
> URL: https://issues.apache.org/jira/browse/SOLR-2242
> Project: Solr
> Issue Type: New Feature
> Components: Response Writers
>Affects Versions: 4.0-ALPHA
>Reporter: Bill Bell
>Priority: Minor
> Fix For: 4.4
>
> Attachments: SOLR-2242-3x_5_tests.patch, SOLR-2242-3x.patch,
> SOLR-2242.patch, SOLR-2242.patch, SOLR-2242.patch,
> SOLR-2242.shard.withtests.patch, SOLR-2242.solr3.1-fix.patch,
> SOLR-2242.solr3.1.patch, SOLR.2242.solr3.1.patch, SOLR-2242-solr40-3.patch
>
>
> When returning facet.field= you will get a list of matches for
> distinct values. This is normal behavior. This patch tells you how many
> distinct values you have (# of rows). Use with limit=-1 and mincount=1.
> The feature is called "namedistinct". Here is an example:
> Parameters:
> facet.numTerms or f..facet.numTerms = true (default is false) - turn
> on distinct counting of terms
> facet.field - the field to count the terms
> It creates a new section in the facet section...
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numTerms=true&facet.limit=-1&facet.field=price
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numTerms=false&facet.limit=-1&facet.field=price
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numTerms=true&facet.limit=-1&facet.field=price
> This currently only works on facet.field.
> {code}
>
>
> ...
>
>
> 14
>
>
> 14
>
>
>
>
>
> OR with no sharding-
>
> 14
>
> {code}
> Several people use this to get the group.field count (the # of groups).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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
