[JENKINS] Lucene-Solr-Tests-trunk-Java7 - Build # 4738 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java7/4738/ All tests passed Build Log: [...truncated 3307 lines...] [junit4] ERROR: JVM J0 ended with an exception, command line: /usr/local/openjdk7/jre/bin/java -XX:+UseG1GC -Dtests.prefix=tests -Dtests.seed=A91B7201E0C36034 -Xmx512M -Dtests.iters= -Dtests.verbose=false -Dtests.infostream=false -Dtests.codec=random -Dtests.postingsformat=random -Dtests.docvaluesformat=random -Dtests.locale=random -Dtests.timezone=random -Dtests.directory=random -Dtests.linedocsfile=europarl.lines.txt.gz -Dtests.luceneMatchVersion=5.0 -Dtests.cleanthreads=perClass -Djava.util.logging.config.file=/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java7/lucene/tools/junit4/logging.properties -Dtests.nightly=false -Dtests.weekly=false -Dtests.monster=false -Dtests.slow=true -Dtests.asserts.gracious=false -Dtests.multiplier=3 -DtempDir=./temp -Djava.io.tmpdir=./temp -Djunit4.tempDir=/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java7/solr/build/solr-core/test/temp -Dclover.db.dir=/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java7/lucene/build/clover/db -Djava.security.manager=org.apache.lucene.util.TestSecurityManager -Djava.security.policy=/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java7/lucene/tools/junit4/tests.policy -Dlucene.version=5.0-SNAPSHOT -Djetty.testMode=1 -Djetty.insecurerandom=1 -Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory -Djava.awt.headless=true -Djdk.map.althashing.threshold=0 -Dtests.jettyConnector=Socket -Dtests.leaveTemporary=false -Dtests.filterstacks=true -Dtests.disableHdfs=true -Dfile.encoding=ISO-8859-1 -classpath
[jira] [Updated] (SOLR-5095) SolrCore.infoRegistry needs overhauled with some form of namespacing
[
https://issues.apache.org/jira/browse/SOLR-5095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-5095:
---
Attachment: SOLR-5095.patch
1. Made map key as JMX canonical name that correspond to registered mbean and
unique
2. Overriden Map.get in order to translate existing key to JMX canonical name
3. Changed unregister method: removed unused InfoMBean parameter, changed
unregister to work on canonical name
4. JMX names reminded unchanged and backward compatible
SolrCore.infoRegistry needs overhauled with some form of namespacing
--
Key: SOLR-5095
URL: https://issues.apache.org/jira/browse/SOLR-5095
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
Attachments: SOLR-5095.patch, SOLR-5095_bug_demo.patch
While investigating SOLR-3616 / SOLR-2715, I realized the failure i was
seeing didn't seem to be related to the initial report of that bug, and
instead seemed to be due to an obvious and fundemental limitation in the way
SolrCore keeps track of plugins using the infoRegistry: It's just a
{{MapString, SolrInfoMBean}} keyed off of the name of the plugin, but there
is not namespacing used in the infoRegistry, so two completley different
types of plugins with the same name will overwrite each other.
When looking at data using something like /admin/mbeans, this manifests
itself solely as missing objects: last one .put() into the infoRegistry
wins -- using JMX, both objects are actually visible because of how JMX
ObjectNames are built arround a set of key=val pairs, and a bug in how
JmxMonitorMap unregisters existing MBeans when .put() is called on a key it
already knows about (the unregister call is made using an ObjectName built
using the infoBean passed to the put() call -- if infoBean.getName() is not
exactly the same as the previous infoBean put() with the same key, then the
MbeanServer will continue to know about both of them)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5109) Solr 4.4 will not deploy in Glassfish 4.x
[ https://issues.apache.org/jira/browse/SOLR-5109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14047075#comment-14047075 ] Shalin Shekhar Mangar commented on SOLR-5109: - Thanks Michael. Any reason why guava should be removed from the ivy-ignore-conflicts.properties file? Solr 4.4 will not deploy in Glassfish 4.x - Key: SOLR-5109 URL: https://issues.apache.org/jira/browse/SOLR-5109 Project: Solr Issue Type: Bug Affects Versions: 4.4 Environment: Glassfish 4.x Reporter: jamon camisso Priority: Blocker Labels: guava Attachments: LUCENE-5109.patch, guava-15.0-SNAPSHOT.jar The bundled Guava 14.0.1 JAR blocks deploying Solr 4.4 in Glassfish 4.x. This failure is a known issue with upstream Guava and is described here: https://code.google.com/p/guava-libraries/issues/detail?id=1433 Building Guava guava-15.0-SNAPSHOT.jar from master and bundling it in Solr allows for a successful deployment. Until the Guava developers release version 15 using their HEAD or even an RC tag seems like the only way to resolve this. This is frustrating since it was proposed that Guava be removed as a dependency before Solr 4.0 was released and yet it remains and blocks upgrading: https://issues.apache.org/jira/browse/SOLR-3601 -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request: efbytesref as of 20140629
GitHub user PaulElschot opened a pull request: https://github.com/apache/lucene-solr/pull/60 efbytesref as of 20140629 LUCENE-5524 This closes #50 Update to recent trunk. Implement Accountable in EliasFanoDocIdSet. There is one nocommit for the test of Accountable.ramBytesUsed on EliasFanoDocIdSet: disabled the test inherited from BaseDocIdSetTestCase because it fails even though there is a reasonable implementation. The question is how to make this test pass: reimplement it to fit the implementation of Accountable in EliasFanoDocIdSet, or improve the implementation in EliasFanoDocIdSet. I'm probably overlooking something here. You can merge this pull request into a Git repository by running: $ git pull https://github.com/PaulElschot/lucene-solr efbytesref-201406a Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/60.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #60 commit 5ef98c1a655d9b79a01f8ffc884676076dbbec47 Author: Paul Elschot paul.j.elsc...@gmail.com Date: 2014-06-29T09:40:04Z efbytesref as of 20140629 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5524) Elias-Fano sequence also on BytesRef
[ https://issues.apache.org/jira/browse/LUCENE-5524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14047087#comment-14047087 ] ASF GitHub Bot commented on LUCENE-5524: GitHub user PaulElschot opened a pull request: https://github.com/apache/lucene-solr/pull/60 efbytesref as of 20140629 LUCENE-5524 This closes #50 Update to recent trunk. Implement Accountable in EliasFanoDocIdSet. There is one nocommit for the test of Accountable.ramBytesUsed on EliasFanoDocIdSet: disabled the test inherited from BaseDocIdSetTestCase because it fails even though there is a reasonable implementation. The question is how to make this test pass: reimplement it to fit the implementation of Accountable in EliasFanoDocIdSet, or improve the implementation in EliasFanoDocIdSet. I'm probably overlooking something here. You can merge this pull request into a Git repository by running: $ git pull https://github.com/PaulElschot/lucene-solr efbytesref-201406a Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/60.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #60 commit 5ef98c1a655d9b79a01f8ffc884676076dbbec47 Author: Paul Elschot paul.j.elsc...@gmail.com Date: 2014-06-29T09:40:04Z efbytesref as of 20140629 Elias-Fano sequence also on BytesRef Key: LUCENE-5524 URL: https://issues.apache.org/jira/browse/LUCENE-5524 Project: Lucene - Core Issue Type: New Feature Components: core/other Reporter: Paul Elschot Priority: Minor -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request: Labeledtree 201406a
GitHub user PaulElschot opened a pull request: https://github.com/apache/lucene-solr/pull/61 Labeledtree 201406a LUCENE-5627 This closes #51 Add LabelFieldSchema and PositionalJoinQueryFactory for use in a query parser. Improved module dependencies for label module. Based on recent efbytesref, LUCENE-5524, which is based on recent trunk. You can merge this pull request into a Git repository by running: $ git pull https://github.com/PaulElschot/lucene-solr labeledtree-201406a Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/61.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #61 commit 5ef98c1a655d9b79a01f8ffc884676076dbbec47 Author: Paul Elschot paul.j.elsc...@gmail.com Date: 2014-06-29T09:40:04Z efbytesref as of 20140629 commit f7f5dd63f55bf54c38bf3535df58d4fec557d626 Author: Paul Elschot paul.j.elsc...@gmail.com Date: 2014-06-29T09:48:59Z labeledtree as of 20140629 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5627) Positional joins
[ https://issues.apache.org/jira/browse/LUCENE-5627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14047088#comment-14047088 ] ASF GitHub Bot commented on LUCENE-5627: GitHub user PaulElschot opened a pull request: https://github.com/apache/lucene-solr/pull/61 Labeledtree 201406a LUCENE-5627 This closes #51 Add LabelFieldSchema and PositionalJoinQueryFactory for use in a query parser. Improved module dependencies for label module. Based on recent efbytesref, LUCENE-5524, which is based on recent trunk. You can merge this pull request into a Git repository by running: $ git pull https://github.com/PaulElschot/lucene-solr labeledtree-201406a Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/61.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #61 commit 5ef98c1a655d9b79a01f8ffc884676076dbbec47 Author: Paul Elschot paul.j.elsc...@gmail.com Date: 2014-06-29T09:40:04Z efbytesref as of 20140629 commit f7f5dd63f55bf54c38bf3535df58d4fec557d626 Author: Paul Elschot paul.j.elsc...@gmail.com Date: 2014-06-29T09:48:59Z labeledtree as of 20140629 Positional joins Key: LUCENE-5627 URL: https://issues.apache.org/jira/browse/LUCENE-5627 Project: Lucene - Core Issue Type: New Feature Reporter: Paul Elschot Priority: Minor Prototype of analysis and search for labeled fragments -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5109) Solr 4.4 will not deploy in Glassfish 4.x
[
https://issues.apache.org/jira/browse/SOLR-5109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14047091#comment-14047091
]
Shalin Shekhar Mangar commented on SOLR-5109:
-
I get the following exception on running tests with this patch:
{code}
[junit4] 2 NOTE: reproduce with: ant test -Dtestcase=MorphlineMapperTest
-Dtests.method=testMapper -Dtests.seed=E7DCE14D317EEE6 -Dtests.slow=true
-Dtests.locale=pt_BR -Dtests.timezone=CST6CDT -Dtests.file.encoding=UTF-8
[junit4] ERROR 5.72s J0 | MorphlineMapperTest.testMapper
[junit4] Throwable #1: java.lang.NoSuchMethodError:
com.google.common.io.Closeables.closeQuietly(Ljava/io/Closeable;)V
[junit4]at
__randomizedtesting.SeedInfo.seed([E7DCE14D317EEE6:C409BE18B828A797]:0)
[junit4]at
org.kitesdk.morphline.tika.DetectMimeTypeBuilder$DetectMimeType.init(DetectMimeTypeBuilder.java:119)
[junit4]at
org.kitesdk.morphline.tika.DetectMimeTypeBuilder.build(DetectMimeTypeBuilder.java:65)
[junit4]at
org.kitesdk.morphline.base.AbstractCommand.buildCommand(AbstractCommand.java:302)
[junit4]at
org.kitesdk.morphline.base.AbstractCommand.buildCommandChain(AbstractCommand.java:249)
[junit4]at
org.kitesdk.morphline.stdlib.Pipe.init(Pipe.java:46)
[junit4]at
org.kitesdk.morphline.stdlib.PipeBuilder.build(PipeBuilder.java:40)
[junit4]at
org.kitesdk.morphline.base.Compiler.compile(Compiler.java:126)
[junit4]at
org.kitesdk.morphline.base.Compiler.compile(Compiler.java:55)
[junit4]at
org.apache.solr.hadoop.morphline.MorphlineMapRunner.init(MorphlineMapRunner.java:157)
[junit4]at
org.apache.solr.hadoop.morphline.MorphlineMapper.setup(MorphlineMapper.java:75)
[junit4]at
org.apache.hadoop.mapreduce.Mapper.run(Mapper.java:142)
[junit4]at
org.apache.hadoop.mrunit.mapreduce.MapDriver.run(MapDriver.java:137)
[junit4]at
org.apache.solr.hadoop.MorphlineMapperTest.testMapper(MorphlineMapperTest.java:61)
[junit4]at java.lang.Thread.run(Thread.java:744)
{code}
Solr 4.4 will not deploy in Glassfish 4.x
-
Key: SOLR-5109
URL: https://issues.apache.org/jira/browse/SOLR-5109
Project: Solr
Issue Type: Bug
Affects Versions: 4.4
Environment: Glassfish 4.x
Reporter: jamon camisso
Priority: Blocker
Labels: guava
Attachments: LUCENE-5109.patch, guava-15.0-SNAPSHOT.jar
The bundled Guava 14.0.1 JAR blocks deploying Solr 4.4 in Glassfish 4.x.
This failure is a known issue with upstream Guava and is described here:
https://code.google.com/p/guava-libraries/issues/detail?id=1433
Building Guava guava-15.0-SNAPSHOT.jar from master and bundling it in Solr
allows for a successful deployment.
Until the Guava developers release version 15 using their HEAD or even an RC
tag seems like the only way to resolve this.
This is frustrating since it was proposed that Guava be removed as a
dependency before Solr 4.0 was released and yet it remains and blocks
upgrading: https://issues.apache.org/jira/browse/SOLR-3601
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-6211) TrieDateField doesn't default to omitNorms=true
Michael Ryan created SOLR-6211: -- Summary: TrieDateField doesn't default to omitNorms=true Key: SOLR-6211 URL: https://issues.apache.org/jira/browse/SOLR-6211 Project: Solr Issue Type: Bug Affects Versions: 4.9 Reporter: Michael Ryan In SOLR-3140, omitNorms=true was made the default for all primitive fields. But this is not the case for TrieDateField - if the fieldType config for a TrieDateField has no omitNorms set, the fields will have norms. It definitely looks like it was intended for TrieDateField to default to omitNorms=true, because in the example schema.xml, omitNorms=true was removed from tdate. I think TrieDateField.init() just needs to call super.init() to fix this. Right now it is initializing its wrapped field, but not itself. There were some changes around this in trunk in SOLR-5936, but I haven't tested to see if it's fixed there. It might have covered this bug up even further, as there is now a test in PrimitiveFieldTypeTest for this, but it uses a the overridden TrieDateField.hasProperty() method, which is not the way that SchemaField actually accesses the field type properties. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6211) TrieDateField doesn't default to omitNorms=true
[ https://issues.apache.org/jira/browse/SOLR-6211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Ryan updated SOLR-6211: --- Description: In SOLR-3140, omitNorms=true was made the default for all primitive fields. But this is not the case for TrieDateField - if the fieldType config for a TrieDateField has no omitNorms set, the fields will have norms. It definitely looks like it was intended for TrieDateField to default to omitNorms=true, because in the example schema.xml, omitNorms=true was removed from tdate. I think TrieDateField.init() just needs to call super.init() to fix this. Right now it is initializing its wrapped field, but not itself. There were some changes around this in trunk in SOLR-5936, but I haven't tested to see if it's fixed there. It might have covered this bug up even further, as there is now a test in PrimitiveFieldTypeTest for this, but it uses the overridden TrieDateField.hasProperty() method, which is not the way that SchemaField actually accesses the field type properties. was: In SOLR-3140, omitNorms=true was made the default for all primitive fields. But this is not the case for TrieDateField - if the fieldType config for a TrieDateField has no omitNorms set, the fields will have norms. It definitely looks like it was intended for TrieDateField to default to omitNorms=true, because in the example schema.xml, omitNorms=true was removed from tdate. I think TrieDateField.init() just needs to call super.init() to fix this. Right now it is initializing its wrapped field, but not itself. There were some changes around this in trunk in SOLR-5936, but I haven't tested to see if it's fixed there. It might have covered this bug up even further, as there is now a test in PrimitiveFieldTypeTest for this, but it uses a the overridden TrieDateField.hasProperty() method, which is not the way that SchemaField actually accesses the field type properties. TrieDateField doesn't default to omitNorms=true --- Key: SOLR-6211 URL: https://issues.apache.org/jira/browse/SOLR-6211 Project: Solr Issue Type: Bug Affects Versions: 4.9 Reporter: Michael Ryan In SOLR-3140, omitNorms=true was made the default for all primitive fields. But this is not the case for TrieDateField - if the fieldType config for a TrieDateField has no omitNorms set, the fields will have norms. It definitely looks like it was intended for TrieDateField to default to omitNorms=true, because in the example schema.xml, omitNorms=true was removed from tdate. I think TrieDateField.init() just needs to call super.init() to fix this. Right now it is initializing its wrapped field, but not itself. There were some changes around this in trunk in SOLR-5936, but I haven't tested to see if it's fixed there. It might have covered this bug up even further, as there is now a test in PrimitiveFieldTypeTest for this, but it uses the overridden TrieDateField.hasProperty() method, which is not the way that SchemaField actually accesses the field type properties. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-4730) SmartChineseAnalyzer got wrong matched offset
[
https://issues.apache.org/jira/browse/LUCENE-4730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14047046#comment-14047046
]
Michael Dodsworth edited comment on LUCENE-4730 at 6/29/14 3:39 PM:
This appears to be a symptom of LUCENE-4984 (fixed in 4.8).
The following test fails:
{code:java}
// note Version.LUCENE_4_7
assertAnalyzesTo(new SmartChineseAnalyzer(Version.LUCENE_4_7, true), My China
,
new String[] { my, china}, new int[] {0,3}, new int[] {2, 8});
{code}
whereas this passes:
{code:java}
// note Version.LUCENE_4_8
assertAnalyzesTo(new SmartChineseAnalyzer(Version.LUCENE_4_8, true), My China
,
new String[] { my, china}, new int[] {0,3}, new int[] {2, 8});
{code}
I'll add a test to verify this double-whitespace case but otherwise, this can
be closed out.
was (Author: mdodswo...@salesforce.com):
This appears to be a symptom of LUCENE-4984 (fixed in 4.8).
The following test fails:
{code:java}
// note Version.LUCENE_4_7
assertAnalyzesTo(new SmartChineseAnalyzer(Version.LUCENE_4_7, true), My China
,
new String[] { my, china}, new int[] {0,3}, new int[] {2, 8});
{code}
whereas this passes:
{code:java}
note Version.LUCENE_4_8
assertAnalyzesTo(new SmartChineseAnalyzer(Version.LUCENE_4_8, true), My China
,
new String[] { my, china}, new int[] {0,3}, new int[] {2, 8});
{code}
I'll add a test to verify this double-whitespace case but otherwise, this can
be closed out.
SmartChineseAnalyzer got wrong matched offset
-
Key: LUCENE-4730
URL: https://issues.apache.org/jira/browse/LUCENE-4730
Project: Lucene - Core
Issue Type: Bug
Components: modules/analysis
Affects Versions: 4.0, 4.1
Environment: JDK1.7 Linux/Windows
Reporter: Jinsong Hu
Priority: Critical
Attachments: LUCENE-4730.patch
We found that SmartChineseAnalyzer got wrong matched offset with the
following test code:
public void testHighlight() throws Exception {
String text = My China ;
String queryText = China;
StringBuilder builder = new StringBuilder(html);
Analyzer analyzer = new SmartChineseAnalyzer(Version.LUCENE_40);
//Analyzer analyzer = new StandardAnalyzer(Version.LUCENE_40);
QueryParser parser = new QueryParser(Version.LUCENE_40, text,
analyzer);
Query query = parser.parse(queryText);
SimpleHTMLFormatter formatter = new SimpleHTMLFormatter(span
style=\background: yellow\, /span);
TokenStream tokens = analyzer.tokenStream(text, new
StringReader(text));
QueryScorer scorer = new QueryScorer(query, text);
Highlighter highlighter = new Highlighter(formatter, scorer);
highlighter.setTextFragmenter(new SimpleSpanFragmenter(scorer));
String result = highlighter.getBestFragments(tokens, text, 10, ...);
if (result.length() text.length()) {
result = text;
}
builder.append(body);
builder.append(result);
builder.append(/body);
builder.append(/html);
System.out.println(builder.toString());
}
This method will generate a hilighted text, however, the highlight position
is obviously wrong, and if we remove one space from the text, that is, change
text from My China (ends with two spaces) to My China (ends with one
space), it will generate a text with correct highlight. If we change the
analyzer from SmartChineseAnalyzer to StandardAnalyzer, the highlight issue
will disappear.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6211) TrieDateField doesn't default to omitNorms=true
[
https://issues.apache.org/jira/browse/SOLR-6211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14047153#comment-14047153
]
Steve Rowe commented on SOLR-6211:
--
+1
This is only a problem on branch_4x, because on trunk, for SOLR-5936, I added
the following to {{TrieDateField}}:
{code:java}
@Override
protected boolean hasProperty(int p) {
return wrappedField.hasProperty(p);
}
{code}
I think the above should be added to branch_4x {{TrieDateField}} too, rather
than calling {{super.init()}} from {{init()}}.
On trunk {{PrimitiveFieldTypeTest.testDefaultOmitNorms()}} explicitly tests
that {{TrieDateField}} has the {{OMIT_NORMS}} property under schema version
1.5, but not on branch_4x - we should add all Trie fields to that test on both
branch_4x and trunk.
I'll work up a patch.
TrieDateField doesn't default to omitNorms=true
---
Key: SOLR-6211
URL: https://issues.apache.org/jira/browse/SOLR-6211
Project: Solr
Issue Type: Bug
Affects Versions: 4.9
Reporter: Michael Ryan
In SOLR-3140, omitNorms=true was made the default for all primitive fields.
But this is not the case for TrieDateField - if the fieldType config for a
TrieDateField has no omitNorms set, the fields will have norms.
It definitely looks like it was intended for TrieDateField to default to
omitNorms=true, because in the example schema.xml, omitNorms=true was removed
from tdate.
I think TrieDateField.init() just needs to call super.init() to fix this.
Right now it is initializing its wrapped field, but not itself.
There were some changes around this in trunk in SOLR-5936, but I haven't
tested to see if it's fixed there. It might have covered this bug up even
further, as there is now a test in PrimitiveFieldTypeTest for this, but it
uses the overridden TrieDateField.hasProperty() method, which is not the way
that SchemaField actually accesses the field type properties.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5109) Solr 4.4 will not deploy in Glassfish 4.x
[ https://issues.apache.org/jira/browse/SOLR-5109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14047162#comment-14047162 ] Michael Dodsworth commented on SOLR-5109: - ah, fun. Those tests don't run under java 8 due to a Saxon-HE issue (which is actually fixed in 9.5.1-5). The guava issue has been fixed in kite-sdk:master - https://github.com/kite-sdk/kite/commit/0ab2795872e4e5721f477d79e5049371a17ab8db. We'll have to wait for the next drop of kite-sdk before guava can be upgraded. I'll create a separate issue for updating Saxon-HE and reinstating the affected tests. Apologies and thanks for looking this, Shalin. Solr 4.4 will not deploy in Glassfish 4.x - Key: SOLR-5109 URL: https://issues.apache.org/jira/browse/SOLR-5109 Project: Solr Issue Type: Bug Affects Versions: 4.4 Environment: Glassfish 4.x Reporter: jamon camisso Priority: Blocker Labels: guava Attachments: LUCENE-5109.patch, guava-15.0-SNAPSHOT.jar The bundled Guava 14.0.1 JAR blocks deploying Solr 4.4 in Glassfish 4.x. This failure is a known issue with upstream Guava and is described here: https://code.google.com/p/guava-libraries/issues/detail?id=1433 Building Guava guava-15.0-SNAPSHOT.jar from master and bundling it in Solr allows for a successful deployment. Until the Guava developers release version 15 using their HEAD or even an RC tag seems like the only way to resolve this. This is frustrating since it was proposed that Guava be removed as a dependency before Solr 4.0 was released and yet it remains and blocks upgrading: https://issues.apache.org/jira/browse/SOLR-3601 -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-6212) upgrade Saxon-HE to 9.5.1-5 and reinstate Morphline tests that were affected under java 8/9 with 9.5.1-4
Michael Dodsworth created SOLR-6212: --- Summary: upgrade Saxon-HE to 9.5.1-5 and reinstate Morphline tests that were affected under java 8/9 with 9.5.1-4 Key: SOLR-6212 URL: https://issues.apache.org/jira/browse/SOLR-6212 Project: Solr Issue Type: Bug Affects Versions: 4.7, 5.0 Reporter: Michael Dodsworth Priority: Minor From SOLR-1301: For posterity, there is a thread on the dev list where we are working through an issue with Saxon on java 8 and ibm's j9. Wolfgang filed https://saxonica.plan.io/issues/1944 upstream. (Saxon is pulled in via cdk-morphlines-saxon). Due to this issue, several Morphline tests were made to be 'ignored' in java 8+. The Saxon issue has been fixed in 9.5.1-5, so we should upgrade and reinstate those tests. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-6212) upgrade Saxon-HE to 9.5.1-5 and reinstate Morphline tests that were affected under java 8/9 with 9.5.1-4
[ https://issues.apache.org/jira/browse/SOLR-6212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller reassigned SOLR-6212: - Assignee: Mark Miller upgrade Saxon-HE to 9.5.1-5 and reinstate Morphline tests that were affected under java 8/9 with 9.5.1-4 Key: SOLR-6212 URL: https://issues.apache.org/jira/browse/SOLR-6212 Project: Solr Issue Type: Bug Affects Versions: 4.7, 5.0 Reporter: Michael Dodsworth Assignee: Mark Miller Priority: Minor From SOLR-1301: For posterity, there is a thread on the dev list where we are working through an issue with Saxon on java 8 and ibm's j9. Wolfgang filed https://saxonica.plan.io/issues/1944 upstream. (Saxon is pulled in via cdk-morphlines-saxon). Due to this issue, several Morphline tests were made to be 'ignored' in java 8+. The Saxon issue has been fixed in 9.5.1-5, so we should upgrade and reinstate those tests. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6212) upgrade Saxon-HE to 9.5.1-5 and reinstate Morphline tests that were affected under java 8/9 with 9.5.1-4
[ https://issues.apache.org/jira/browse/SOLR-6212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14047223#comment-14047223 ] wolfgang hoschek commented on SOLR-6212: This is already fixed in the latest stable morphline release per http://kitesdk.org/docs/current/release_notes.html upgrade Saxon-HE to 9.5.1-5 and reinstate Morphline tests that were affected under java 8/9 with 9.5.1-4 Key: SOLR-6212 URL: https://issues.apache.org/jira/browse/SOLR-6212 Project: Solr Issue Type: Bug Affects Versions: 4.7, 5.0 Reporter: Michael Dodsworth Assignee: Mark Miller Priority: Minor From SOLR-1301: For posterity, there is a thread on the dev list where we are working through an issue with Saxon on java 8 and ibm's j9. Wolfgang filed https://saxonica.plan.io/issues/1944 upstream. (Saxon is pulled in via cdk-morphlines-saxon). Due to this issue, several Morphline tests were made to be 'ignored' in java 8+. The Saxon issue has been fixed in 9.5.1-5, so we should upgrade and reinstate those tests. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: VOTE: RC0 apache-solr-ref-guide-4.9.pdf
VOTE has passed, I've triggered the svn publish to start the sync out to the mirrors. : Date: Thu, 26 Jun 2014 18:18:27 -0500 : From: Cassandra Targett casstarg...@gmail.com : Reply-To: dev@lucene.apache.org : To: dev@lucene.apache.org : Cc: Lucene mailing list gene...@lucene.apache.org : Subject: VOTE: RC0 apache-solr-ref-guide-4.9.pdf : : The Solr Ref Guide for Solr 4.9 is ready for vote: : : https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-4.9-RC0/ : : +1 from me. : : Cassandra : -Hoss http://www.lucidworks.com/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6212) upgrade Saxon-HE to 9.5.1-5 and reinstate Morphline tests that were affected under java 8/9 with 9.5.1-4
[ https://issues.apache.org/jira/browse/SOLR-6212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dodsworth updated SOLR-6212: Attachment: SOLR-6212.patch upgrading Saxon-HE (to 9.5.1-5) and morphlines (to 0.14.1) upgrade Saxon-HE to 9.5.1-5 and reinstate Morphline tests that were affected under java 8/9 with 9.5.1-4 Key: SOLR-6212 URL: https://issues.apache.org/jira/browse/SOLR-6212 Project: Solr Issue Type: Bug Affects Versions: 4.7, 5.0 Reporter: Michael Dodsworth Assignee: Mark Miller Priority: Minor Attachments: SOLR-6212.patch From SOLR-1301: For posterity, there is a thread on the dev list where we are working through an issue with Saxon on java 8 and ibm's j9. Wolfgang filed https://saxonica.plan.io/issues/1944 upstream. (Saxon is pulled in via cdk-morphlines-saxon). Due to this issue, several Morphline tests were made to be 'ignored' in java 8+. The Saxon issue has been fixed in 9.5.1-5, so we should upgrade and reinstate those tests. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5109) Solr 4.4 will not deploy in Glassfish 4.x
[ https://issues.apache.org/jira/browse/SOLR-5109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14047391#comment-14047391 ] wolfgang hoschek commented on SOLR-5109: FWIW, morphlines currently won't work with guava-16 or guava-17 because of the incompatible guava API changes in the guava Closeables class in those two guava releases. However, there's a fix for this issue that will show up soon in kite-morphlines 0.15.0. See https://github.com/kite-sdk/kite/commit/0ab2795872e4e5721f477d79e5049371a17ab8db Solr 4.4 will not deploy in Glassfish 4.x - Key: SOLR-5109 URL: https://issues.apache.org/jira/browse/SOLR-5109 Project: Solr Issue Type: Bug Affects Versions: 4.4 Environment: Glassfish 4.x Reporter: jamon camisso Priority: Blocker Labels: guava Attachments: LUCENE-5109.patch, guava-15.0-SNAPSHOT.jar The bundled Guava 14.0.1 JAR blocks deploying Solr 4.4 in Glassfish 4.x. This failure is a known issue with upstream Guava and is described here: https://code.google.com/p/guava-libraries/issues/detail?id=1433 Building Guava guava-15.0-SNAPSHOT.jar from master and bundling it in Solr allows for a successful deployment. Until the Guava developers release version 15 using their HEAD or even an RC tag seems like the only way to resolve this. This is frustrating since it was proposed that Guava be removed as a dependency before Solr 4.0 was released and yet it remains and blocks upgrading: https://issues.apache.org/jira/browse/SOLR-3601 -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-5109) Solr 4.4 will not deploy in Glassfish 4.x
[ https://issues.apache.org/jira/browse/SOLR-5109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14047394#comment-14047394 ] wolfgang hoschek edited comment on SOLR-5109 at 6/30/14 5:36 AM: - Another potential issue is that hadoop ships with guava-11.0.2 on the classpath of the task tracker (the JVM that runs the job). So this old guava version will race with any other guava version that happens to be on the classpath. was (Author: whoschek): Another potential issue is that hadoop ships with guava-12.0.1 on the classpath of the task tracker (the JVM that runs the job). So this old guava version will race with any other guava version that happens to be on the classpath. Solr 4.4 will not deploy in Glassfish 4.x - Key: SOLR-5109 URL: https://issues.apache.org/jira/browse/SOLR-5109 Project: Solr Issue Type: Bug Affects Versions: 4.4 Environment: Glassfish 4.x Reporter: jamon camisso Priority: Blocker Labels: guava Attachments: LUCENE-5109.patch, guava-15.0-SNAPSHOT.jar The bundled Guava 14.0.1 JAR blocks deploying Solr 4.4 in Glassfish 4.x. This failure is a known issue with upstream Guava and is described here: https://code.google.com/p/guava-libraries/issues/detail?id=1433 Building Guava guava-15.0-SNAPSHOT.jar from master and bundling it in Solr allows for a successful deployment. Until the Guava developers release version 15 using their HEAD or even an RC tag seems like the only way to resolve this. This is frustrating since it was proposed that Guava be removed as a dependency before Solr 4.0 was released and yet it remains and blocks upgrading: https://issues.apache.org/jira/browse/SOLR-3601 -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5109) Solr 4.4 will not deploy in Glassfish 4.x
[ https://issues.apache.org/jira/browse/SOLR-5109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14047394#comment-14047394 ] wolfgang hoschek commented on SOLR-5109: Another potential issue is that hadoop ships with guava-12.0.1 on the classpath of the task tracker (the JVM that runs the job). So this old guava version will race with any other guava version that happens to be on the classpath. Solr 4.4 will not deploy in Glassfish 4.x - Key: SOLR-5109 URL: https://issues.apache.org/jira/browse/SOLR-5109 Project: Solr Issue Type: Bug Affects Versions: 4.4 Environment: Glassfish 4.x Reporter: jamon camisso Priority: Blocker Labels: guava Attachments: LUCENE-5109.patch, guava-15.0-SNAPSHOT.jar The bundled Guava 14.0.1 JAR blocks deploying Solr 4.4 in Glassfish 4.x. This failure is a known issue with upstream Guava and is described here: https://code.google.com/p/guava-libraries/issues/detail?id=1433 Building Guava guava-15.0-SNAPSHOT.jar from master and bundling it in Solr allows for a successful deployment. Until the Guava developers release version 15 using their HEAD or even an RC tag seems like the only way to resolve this. This is frustrating since it was proposed that Guava be removed as a dependency before Solr 4.0 was released and yet it remains and blocks upgrading: https://issues.apache.org/jira/browse/SOLR-3601 -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
