[jira] [Commented] (SOLR-14151) Make schema components load from packages
[
https://issues.apache.org/jira/browse/SOLR-14151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17004681#comment-17004681
]
Noble Paul commented on SOLR-14151:
---
we will not support SPI from packages.
> Make schema components load from packages
> -
>
> Key: SOLR-14151
> URL: https://issues.apache.org/jira/browse/SOLR-14151
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Priority: Major
> Time Spent: 4h 10m
> Remaining Estimate: 0h
>
> Example:
> {code:xml}
>
>
>
>generateNumberParts="0" catenateWords="0"
> catenateNumbers="0" catenateAll="0"/>
>
>
>
>
> {code}
> * When a package is updated, the entire {{IndexSchema}} object is refreshed,
> but the SolrCore object is not reloaded
> * Any component can be prefixed with the package name
> * The semantics of loading plugins remain the same as that of the components
> in {{solrconfig.xml}}
> * Plugins can be registered using schema API
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1123: LUCENE-9093: Unified highlighter with word separator never gives context to the left
dsmiley commented on a change in pull request #1123: LUCENE-9093: Unified highlighter with word separator never gives context to the left URL: https://github.com/apache/lucene-solr/pull/1123#discussion_r361830391 ## File path: solr/solrj/src/java/org/apache/solr/common/params/HighlightParams.java ## @@ -47,6 +47,8 @@ // sizing public static final String FRAGSIZE= HIGHLIGHT+".fragsize"; // OH, FVH, UH + public static final String FRAGALIGNRATIO = HIGHLIGHT+".fragAlignRatio"; // UH + public static final String FRAGSIZEISMINIMUM = HIGHLIGHT+".fragsizeIsMinimum"; // UH Review comment: very minor: I'd prefer these two added rows are switched so that fragsizeIsMinimum directly follows fragsize This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1123: LUCENE-9093: Unified highlighter with word separator never gives context to the left
dsmiley commented on a change in pull request #1123: LUCENE-9093: Unified
highlighter with word separator never gives context to the left
URL: https://github.com/apache/lucene-solr/pull/1123#discussion_r361828027
##
File path:
lucene/highlighter/src/java/org/apache/lucene/search/uhighlight/LengthGoalBreakIterator.java
##
@@ -104,10 +126,37 @@ public int next(int n) {
return baseIter.next(n); // probably wrong
}
- // called by getSummaryPassagesNoHighlight to generate default summary.
+ // Called by getSummaryPassagesNoHighlight to generate default summary.
+ // This is the same implementation that following() has, except:
Review comment:
This is a lot of code to duplicate; lets not do this.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1123: LUCENE-9093: Unified highlighter with word separator never gives context to the left
dsmiley commented on a change in pull request #1123: LUCENE-9093: Unified
highlighter with word separator never gives context to the left
URL: https://github.com/apache/lucene-solr/pull/1123#discussion_r361828673
##
File path:
lucene/highlighter/src/java/org/apache/lucene/search/uhighlight/LengthGoalBreakIterator.java
##
@@ -173,8 +205,30 @@ private int moveToBreak(int idx) { // precondition: idx
is a known break
// called at start of new Passage given first word start offset
@Override
- public int preceding(int offset) {
-return baseIter.preceding(offset); // no change needed
+ public int preceding(int matchStartIndex) {
+final int targetIdx = (matchStartIndex - 1) - (int)(lengthGoal *
fragmentAlignment);
+if (targetIdx <= 0) {
+ return 0;
+}
+final int beforeIdx = baseIter.preceding(targetIdx + 1);
+if (beforeIdx == DONE) {
+ return 0;
+}
+if (beforeIdx == targetIdx) { // right on the money
+ return beforeIdx;
+}
+if (isMinimumLength) { // thus never undershoot
+ return beforeIdx;
+}
+
+// note: it is a shame that we invoke following() *one more time*; BI's
are sometimes expensive.
+
+// Find closest break to target
+final int afterIdx = baseIter.following(targetIdx - 1);
+if (afterIdx - targetIdx < targetIdx - beforeIdx && afterIdx <
matchStartIndex) {
+ return afterIdx;
+}
+return beforeIdx;
Review comment:
No moveToBreak and so the underlying BI here is not consistent.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1123: LUCENE-9093: Unified highlighter with word separator never gives context to the left
dsmiley commented on a change in pull request #1123: LUCENE-9093: Unified
highlighter with word separator never gives context to the left
URL: https://github.com/apache/lucene-solr/pull/1123#discussion_r361828293
##
File path:
lucene/highlighter/src/java/org/apache/lucene/search/uhighlight/LengthGoalBreakIterator.java
##
@@ -146,18 +182,14 @@ public int following(int followingIdx) {
return afterIdx;
}
-// note: it is a shame that we invoke preceding() *in addition to*
following(); BI's are sometimes expensive.
-
-// Find closest break < target
-final int beforeIdx = baseIter.preceding(targetIdx); // or could do
baseIter.previous() but we hope the BI implements preceding()
-if (beforeIdx <= followingIdx) { // too far back
- return moveToBreak(afterIdx);
-}
+// note: it is a shame that we invoke preceding() *one more time*; BI's
are sometimes expensive.
-if (targetIdx - beforeIdx <= afterIdx - targetIdx) {
+// Find closest break to target
+final int beforeIdx = baseIter.preceding(targetIdx);
+if (targetIdx - beforeIdx < afterIdx - targetIdx && beforeIdx >
matchEndIndex) {
return beforeIdx;
}
-return moveToBreak(afterIdx);
Review comment:
Maybe removing the moveToBreak here is an optimization attempt but it feels
wrong. Also current() accuracy will become necessary if you look at my other
comment about a small proposal to use it so this BI in preceding() doesn't get
look too far left.
It'd be nice if moveToBreak didn't need to exist. I could imagine a BI
wrapper that you could set it's position on but it wouldn't propagate. Methods
whose semantics are based on current() (like next()) would need to act
differently. Kind of a lot of code though. I took a stab at it for fun:
https://gist.github.com/dsmiley/b425b152d51d4c63f498fc84d125ea0a
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1123: LUCENE-9093: Unified highlighter with word separator never gives context to the left
dsmiley commented on a change in pull request #1123: LUCENE-9093: Unified
highlighter with word separator never gives context to the left
URL: https://github.com/apache/lucene-solr/pull/1123#discussion_r361829906
##
File path:
lucene/highlighter/src/test/org/apache/lucene/search/uhighlight/LengthGoalBreakIteratorTest.java
##
@@ -39,65 +41,142 @@
// 0 1
// 01234567890123456789
static final String CONTENT = "Aa bb. Cc dd. Ee ff";
+ static final String CONTENT2 = "Aa bb Cc dd X Ee ff Gg hh.";
+
+ public void testFragmentAlignmentConstructor() throws IOException {
+BreakIterator baseBI = new CustomSeparatorBreakIterator('.');
+// test fragmentAlignment validation
+float[] valid_aligns = {0.f, 0.f, 0.5f, 0.99f, 1.f};
+for (float alignment : valid_aligns) {
+ LengthGoalBreakIterator.createClosestToLength(baseBI, 50, alignment);
+}
+float[] invalid_aligns = {-0.01f, -1.f, 1.5f, Float.NaN,
Float.NEGATIVE_INFINITY, Float.POSITIVE_INFINITY};
+for (float alignment : invalid_aligns) {
+ expectThrows(IllegalArgumentException.class, () -> {
+LengthGoalBreakIterator.createClosestToLength(baseBI, 50, alignment);
+ });
+}
+// test backwards compatibility constructors
+String backwardCompString =
LengthGoalBreakIterator.createClosestToLength(baseBI, 50).toString();
+assertTrue(backwardCompString,
backwardCompString.contains("fragAlign=0.0"));
+backwardCompString = LengthGoalBreakIterator.createMinLength(baseBI,
50).toString();
+assertTrue(backwardCompString,
backwardCompString.contains("fragAlign=0.0"));
+ }
public void testTargetLen() throws IOException {
// "goal" means target length goal to find closest break
// at first word:
Query query = query("aa");
-assertEquals("almost two sent",
-"Aa bb.", highlightClosestToLen(CONTENT, query, 9));
Review comment:
I looked closer at why these numbers changed by 2 and I see it's because
FieldHighlighter now passes the match end offset for the `following` call. As
you've been telling me, the sizing tends to be larger by the match itself.
Hmmm. Perhaps FieldHighlighter should calculate the mid-point and then use
that for both calls. The test might then be off by only 1 but still, the
results would be closer to the intended sizing. WDYT?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1123: LUCENE-9093: Unified highlighter with word separator never gives context to the left
dsmiley commented on a change in pull request #1123: LUCENE-9093: Unified
highlighter with word separator never gives context to the left
URL: https://github.com/apache/lucene-solr/pull/1123#discussion_r361828632
##
File path:
lucene/highlighter/src/java/org/apache/lucene/search/uhighlight/LengthGoalBreakIterator.java
##
@@ -173,8 +205,30 @@ private int moveToBreak(int idx) { // precondition: idx
is a known break
// called at start of new Passage given first word start offset
@Override
- public int preceding(int offset) {
-return baseIter.preceding(offset); // no change needed
+ public int preceding(int matchStartIndex) {
+final int targetIdx = (matchStartIndex - 1) - (int)(lengthGoal *
fragmentAlignment);
+if (targetIdx <= 0) {
+ return 0;
Review comment:
Note that you didn't set the state on the underlying BI for this case. But
we should do that for correctness?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1123: LUCENE-9093: Unified highlighter with word separator never gives context to the left
dsmiley commented on a change in pull request #1123: LUCENE-9093: Unified
highlighter with word separator never gives context to the left
URL: https://github.com/apache/lucene-solr/pull/1123#discussion_r361828618
##
File path:
lucene/highlighter/src/java/org/apache/lucene/search/uhighlight/LengthGoalBreakIterator.java
##
@@ -173,8 +205,30 @@ private int moveToBreak(int idx) { // precondition: idx
is a known break
// called at start of new Passage given first word start offset
@Override
- public int preceding(int offset) {
-return baseIter.preceding(offset); // no change needed
+ public int preceding(int matchStartIndex) {
+final int targetIdx = (matchStartIndex - 1) - (int)(lengthGoal *
fragmentAlignment);
+if (targetIdx <= 0) {
+ return 0;
+}
+final int beforeIdx = baseIter.preceding(targetIdx + 1);
+if (beforeIdx == DONE) {
+ return 0;
Review comment:
Returning beforeIdx (DONE) is perhaps more accurate/correct than 0? Or
maybe first()? Perhaps doesn't matter; this is perhaps theoretical.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1123: LUCENE-9093: Unified highlighter with word separator never gives context to the left
dsmiley commented on a change in pull request #1123: LUCENE-9093: Unified highlighter with word separator never gives context to the left URL: https://github.com/apache/lucene-solr/pull/1123#discussion_r361827668 ## File path: lucene/highlighter/src/java/org/apache/lucene/search/uhighlight/FieldHighlighter.java ## @@ -159,8 +160,9 @@ public Object highlightFieldForDoc(LeafReader reader, int docId, String content) break; } // advance breakIterator -passage.setStartOffset(Math.max(this.breakIterator.preceding(start + 1), 0)); -passage.setEndOffset(Math.min(this.breakIterator.following(start), contentLength)); +passage.setStartOffset(Math.max(this.breakIterator.preceding(start + 1), lastPassageEnd)); Review comment: Oh wait; something occurred to me. The breakIterator.preceding impl doesn't intrinsically know that FieldHighlighter is going to call `Math.max(..., lastPassageEnd)` on it. And I recall you are adding this change here in FieldHighlighter because the updated LengthGoalBreakIterator might want to look further back to the left into a zone that might have been part of a previous Passage. Maybe `LengthGoalBreakIterator.preceding` should examine `current()` at the start and ensure it doesn't yield a break before that. Then FieldHighlighter wouldn't change. Without this small proposal, the length of this passage will be undersized because LengthGoalBreakIterator doesn't know FieldHighlighter is going to chop off some of the beginning thanks to that `max()`. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on issue #1124: SOLR-14151 :Schema components to be loadable from packages
dsmiley commented on issue #1124: SOLR-14151 :Schema components to be loadable from packages URL: https://github.com/apache/lucene-solr/pull/1124#issuecomment-569474142 > The problem is that SRL is directly used in all APIs I don't consider this a problem. Solr has a lot of plugin abstractions and resources that need loading and at least there is a single abstraction (SRL) that serves this purpose. If there were a bunch of loading abstractions then _that_ may be a problem (IMO), but that is not the case yet thankfully. It may be becoming the case here so I'm paying attention to complexity. > ``` > public String getConfigDir() > > public String getDataDir() > > public Properties getCoreProperties() > > public InputStream openConfig(String name) throws IOException > > public InputStream openSchema(String name) > ``` I don't like those methods being there either! Yay; we agree. There are some more that seem dubious to me too, e.g. `persistConfLocally`; _blech!_ > So the common sense thing to do is to create an interface and hide these methods I think that's one option (the one you are taking). I don't care to say what is or isn't "common sense". A down side to this approach is that the system is now more complex as a whole; the SRL you don't like is still there. I'm curious; do you think these unsightly methods on SRL (that we agree should go away) are really fundamental problems with SRL and get in the way of what we are doing today? > Slapping package loading responsibilities on to SRL is the most dangerous thing to do. We have no separation of responsibilities, and we have a class we are all afraid to touch because it may break something and we nobody knows how it works. Sol already has enough such pieces You are a man of strong opinions. I very much disagree with you concerning your view on SRL. SRL has been loading plugins since before a package management system came along. If it worked with a package manager, that seems to me the same responsibility -- it still loads plugins. The implementation would then change to also work with a package manager but it would still be responsible for loading plugins. Perhaps we actually agree much more than it appears. You are proposing a new abstraction that looks _a lot_ like SRL: SolrClassLoader. It's as if you can't bear to say you like SRL so you create something else in its image but without the dead weight we agree shouldn't be in SRL. Can't we instead work to "fix" SRL and have one abstraction? I very much share your concern of being wary of code that "nobody knows how it works" but I don't view SRL as such. You can count me as someone who can help you or anyone understand SRL should you need help ;-). Now _IndexFetcher_ there's a beast I'm scared of. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14141) eliminate JKS keystore from solr SSL docs
[ https://issues.apache.org/jira/browse/SOLR-14141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17004598#comment-17004598 ] Robert Muir commented on SOLR-14141: yeah, like i said the worst is, anyone who has ever used solr on java9+ has a pkcs12 format keystore, but with a .jks file extension. they are currently passing keystore type flags of JKS. it all still works fine only because of the way java implemented the compat, but its really insane. so this patch is mostly juat a docs fix to reflect reality... > eliminate JKS keystore from solr SSL docs > - > > Key: SOLR-14141 > URL: https://issues.apache.org/jira/browse/SOLR-14141 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Robert Muir >Priority: Major > Attachments: SOLR-14141.patch, SOLR-14141.patch > > > On the "Enabling SSL" page: > https://lucene.apache.org/solr/guide/8_3/enabling-ssl.html#enabling-ssl > The first step is currently to create a JKS keystore. The next step > immediately converts the JKS keystore into PKCS12, so that openssl can then > be used to extract key material in PEM format for use with curl. > Now that PKCS12 is java's default keystore format, why not omit step 1 > entirely? What am I missing? PKCS12 is a more commonly > understood/standardized format. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14141) eliminate JKS keystore from solr SSL docs
[
https://issues.apache.org/jira/browse/SOLR-14141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17004595#comment-17004595
]
Kevin Risden commented on SOLR-14141:
-
{quote}you can specify jks and it will read pkcs12 just fine. since its
essentially a noop, i think we should not clutter the docs with this?{quote}
Ah guess I missed that part. That must be what you meant with
"keystore.type.compat=true". I always assumed the storetype needed to be
specified. Looks like this is in JDK 8 build 60 or higher based on
https://bugs.openjdk.java.net/browse/JDK-8062552
+1 to keep it as is then.
> eliminate JKS keystore from solr SSL docs
> -
>
> Key: SOLR-14141
> URL: https://issues.apache.org/jira/browse/SOLR-14141
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Robert Muir
>Priority: Major
> Attachments: SOLR-14141.patch, SOLR-14141.patch
>
>
> On the "Enabling SSL" page:
> https://lucene.apache.org/solr/guide/8_3/enabling-ssl.html#enabling-ssl
> The first step is currently to create a JKS keystore. The next step
> immediately converts the JKS keystore into PKCS12, so that openssl can then
> be used to extract key material in PEM format for use with curl.
> Now that PKCS12 is java's default keystore format, why not omit step 1
> entirely? What am I missing? PKCS12 is a more commonly
> understood/standardized format.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14141) eliminate JKS keystore from solr SSL docs
[ https://issues.apache.org/jira/browse/SOLR-14141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17004593#comment-17004593 ] Robert Muir commented on SOLR-14141: we accomplish that with the explicit storetype param on creation. on reading these parameters are useless: you can specify jks and it will read pkcs12 just fine. since its essentially a noop, i think we should not clutter the docs with this? happy to open a followup to remove these params entirely too. > eliminate JKS keystore from solr SSL docs > - > > Key: SOLR-14141 > URL: https://issues.apache.org/jira/browse/SOLR-14141 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Robert Muir >Priority: Major > Attachments: SOLR-14141.patch, SOLR-14141.patch > > > On the "Enabling SSL" page: > https://lucene.apache.org/solr/guide/8_3/enabling-ssl.html#enabling-ssl > The first step is currently to create a JKS keystore. The next step > immediately converts the JKS keystore into PKCS12, so that openssl can then > be used to extract key material in PEM format for use with curl. > Now that PKCS12 is java's default keystore format, why not omit step 1 > entirely? What am I missing? PKCS12 is a more commonly > understood/standardized format. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] risdenk commented on a change in pull request #1121: SOLR-11207: Add OWASP dependency checker to gradle build
risdenk commented on a change in pull request #1121: SOLR-11207: Add OWASP dependency checker to gradle build URL: https://github.com/apache/lucene-solr/pull/1121#discussion_r361818552 ## File path: gradle/validation/dependency-check.gradle ## @@ -0,0 +1,12 @@ +// This adds OWASP vulnerability validation of project dependencies + +// This should be false only for debugging. +def failOnError = true Review comment: It might make sense to set this to false to get this into the gradle-master build and then once merged to master change the default. I personally find failing the build on OWASP errors can be really frustrating with new CVEs out all the time. I like to see the warnings/errors but not fail the build. This depends on the severity of the CVE as well sometimes. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] risdenk commented on a change in pull request #1121: SOLR-11207: Add OWASP dependency checker to gradle build
risdenk commented on a change in pull request #1121: SOLR-11207: Add OWASP
dependency checker to gradle build
URL: https://github.com/apache/lucene-solr/pull/1121#discussion_r361818500
##
File path: gradle/validation/dependency-check.gradle
##
@@ -0,0 +1,12 @@
+// This adds OWASP vulnerability validation of project dependencies
+
+// This should be false only for debugging.
+def failOnError = true
+
+dependencyCheck {
+ autoUpdate=false
Review comment:
Why not `autoUpdate=true`? I think this is for auto updating the definitions.
From
https://jeremylong.github.io/DependencyCheck/dependency-check-gradle/configuration.html
```
Sets whether auto-updating of the NVD CVE/CPE data is enabled. It is not
recommended that this be turned to false.
```
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14141) eliminate JKS keystore from solr SSL docs
[
https://issues.apache.org/jira/browse/SOLR-14141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17004590#comment-17004590
]
Kevin Risden commented on SOLR-14141:
-
Looked over the changes. Looks good. The only minor change to the last patch
I'd suggest is putting back these lines in the sh/cmd scripts.
{code:java}
# Override Key/Trust Store types if necessary
SOLR_SSL_KEY_STORE_TYPE=PKCS12
SOLR_SSL_TRUST_STORE_TYPE=PKCS12
{code}
I think these were there to show you could change the type of the
keystore/truststore.
> eliminate JKS keystore from solr SSL docs
> -
>
> Key: SOLR-14141
> URL: https://issues.apache.org/jira/browse/SOLR-14141
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Robert Muir
>Priority: Major
> Attachments: SOLR-14141.patch, SOLR-14141.patch
>
>
> On the "Enabling SSL" page:
> https://lucene.apache.org/solr/guide/8_3/enabling-ssl.html#enabling-ssl
> The first step is currently to create a JKS keystore. The next step
> immediately converts the JKS keystore into PKCS12, so that openssl can then
> be used to extract key material in PEM format for use with curl.
> Now that PKCS12 is java's default keystore format, why not omit step 1
> entirely? What am I missing? PKCS12 is a more commonly
> understood/standardized format.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] noblepaul commented on a change in pull request #1124: SOLR-14151 :Schema components to be loadable from packages
noblepaul commented on a change in pull request #1124: SOLR-14151 :Schema
components to be loadable from packages
URL: https://github.com/apache/lucene-solr/pull/1124#discussion_r361817112
##
File path:
solr/core/src/java/org/apache/solr/pkg/PackageAwareSolrClassLoader.java
##
@@ -0,0 +1,154 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.pkg;
+
+import java.io.IOException;
+import java.io.InputStream;
+import java.util.ArrayList;
+import java.util.HashMap;
+import java.util.List;
+import java.util.Map;
+import java.util.Objects;
+import java.util.function.BiFunction;
+
+import org.apache.solr.core.PluginInfo;
+import org.apache.solr.core.SolrClassLoader;
+import org.apache.solr.core.SolrCore;
+import org.apache.solr.core.SolrResourceLoader;
+import org.apache.solr.util.plugin.SolrCoreAware;
+
+import static java.util.Collections.singletonMap;
+
+/**
+ * This class implements a SolrClassLoader that can identify the correct
packages
+ * and load classes from that. This also listens to any changes to the
relevant packages and
+ * invoke a callback if anything is modified
+ */
+public class PackageAwareSolrClassLoader implements SolrClassLoader {
+ final SolrCore core;
+ final SolrResourceLoader loader;
+ private Map classNameVsPkg = new HashMap<>();
+
+ private final List listeners = new ArrayList<>();
+ private final Runnable reloadRunnable;
+
+
+ public PackageAwareSolrClassLoader(SolrCore core, SolrResourceLoader loader,
Runnable runnable) {
Review comment:
It's to reload your set of plugins. In the case of schema it's a
`refreshSchema()` , If you wish to reload core or something else , you could do
it here
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] noblepaul commented on a change in pull request #1124: SOLR-14151 :Schema components to be loadable from packages
noblepaul commented on a change in pull request #1124: SOLR-14151 :Schema
components to be loadable from packages
URL: https://github.com/apache/lucene-solr/pull/1124#discussion_r361817070
##
File path: solr/core/src/java/org/apache/solr/core/MemClassLoader.java
##
@@ -53,6 +53,16 @@ public MemClassLoader(List libs,
SolrResourceLoader resour
this.libs = libs;
}
+ @Override
+ public T newInstance(String cname, Class expectedType, String...
subpackages) {
+return null;
Review comment:
Actually , we are getting rid of `MemClassLoader`. It's a part of the
`runtimeLib` feature. So, we don't need to implement any of these
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13778) Windows JDK SSL Test Failure trend: SSLException: Software caused connection abort: recv failed
[
https://issues.apache.org/jira/browse/SOLR-13778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17004586#comment-17004586
]
Robert Muir commented on SOLR-13778:
With the attached RecvRepro.java I see the following: (all with jdk13):
Linux:
Exception in thread "main" java.lang.RuntimeException: Unreachable?
at RecvRepro.main(RecvRepro.java:46)
Mac OS X:
Received: java.net.SocketException: Connection reset
FreeBSD:
Received: java.net.SocketException: Connection reset
So besides the linux vs windows difference (where windows gets SocketException:
recv failed), we see on the BSDs (including mac os X) that you also get a
SocketException. It is just that the JDK must be handling this one different? I
ran truss to trace the system calls, just so we are sure:
{noformat}
read(7,0x824416000,100) ERR#54 'Connection reset by
peer'
...
errno.h:#define ECONNRESET 54 /* Connection reset by peer */
{noformat}
> Windows JDK SSL Test Failure trend: SSLException: Software caused connection
> abort: recv failed
> ---
>
> Key: SOLR-13778
> URL: https://issues.apache.org/jira/browse/SOLR-13778
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Priority: Major
> Attachments: RecvFailedTest.java, RecvRepro.java, SOLR-13778.patch,
> dumps-LegacyCloud.zip, logs-2019-12-12-1.zip, recv-multiple-2019-12-18.zip
>
>
> Now that Uwe's jenkins build has been correctly reporting it's build results
> for my [automated
> reports|http://fucit.org/solr-jenkins-reports/failure-report.html] to pick
> up, I've noticed a pattern of failures that indicate a definite problem with
> using SSL on Windows (even with java 11.0.4
> )
> The symptommatic stack traces all contain...
> {noformat}
> ...
>[junit4]> Caused by: javax.net.ssl.SSLException: Software caused
> connection abort: recv failed
>[junit4]>at
> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:127)
> ...
>[junit4]> Caused by: java.net.SocketException: Software caused
> connection abort: recv failed
>[junit4]>at
> java.base/java.net.SocketInputStream.socketRead0(Native Method)
> ...
> {noformat}
> I suspect this may be related to
> [https://bugs.openjdk.java.net/browse/JDK-8209333] but i have no concrete
> evidence to back this up.
> I'll post some details of my analysis in comments...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13486) race condition between leader's "replay on startup" and non-leader's "recover from leader" can leave replicas out of sync (TestCloudConsistency)
[
https://issues.apache.org/jira/browse/SOLR-13486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17004577#comment-17004577
]
Erick Erickson commented on SOLR-13486:
---
At least I can get this to reproduce fairly reliably, digging. Although I'm
getting different errors.
> race condition between leader's "replay on startup" and non-leader's "recover
> from leader" can leave replicas out of sync (TestCloudConsistency)
>
>
> Key: SOLR-13486
> URL: https://issues.apache.org/jira/browse/SOLR-13486
> Project: Solr
> Issue Type: Bug
>Reporter: Chris M. Hostetter
>Priority: Major
> Attachments:
> apache_Lucene-Solr-BadApples-NightlyTests-master_61.log.txt.gz,
> apache_Lucene-Solr-BadApples-Tests-8.x_102.log.txt.gz
>
>
> I've been investigating some jenkins failures from TestCloudConsistency,
> which at first glance suggest a problem w/replica(s) recovering after a
> network partition from the leader - but in digging into the logs the root
> cause acturally seems to be a thread race conditions when a replica (the
> leader) is first registered...
> * The {{ZkContainer.registerInZk(...)}} method (which is called by
> {{CoreContainer.registerCore(...)}} & {{CoreContainer.load()}}) is typically
> run in a background thread (via the {{ZkContainer.coreZkRegister}}
> ExecutorService)
> * {{ZkContainer.registerInZk(...)}} delegates to
> {{ZKController.register(...)}} which is ultimately responsible for checking
> if there are any "old" tlogs on disk, and if so handling the "Replaying tlog
> for during startup" logic
> * Because this happens in a background thread, other logic/requests can be
> handled by this core/replica in the meantime - before it starts (or while in
> the middle of) replaying the tlogs
> ** Notably: *leader's that have not yet replayed tlogs on startup will
> erroneously respond to RTG / Fingerprint / PeerSync requests from other
> replicas w/incomplete data*
> ...In general, it seems scary / fishy to me that a replica can (aparently)
> become *ACTIVE* before it's finished it's {{registerInZk}} + "Replaying tlog
> ... during startup" logic ... particularly since this can happen even for
> replicas that are/become leaders. It seems like this could potentially cause
> a whole host of problems, only one of which manifests in this particular test
> failure:
> * *BEFORE* replicaX's "coreZkRegister" thread reaches the "Replaying tlog
> ... during startup" check:
> ** replicaX can recognize (via zk terms) that it should be the leader(X)
> ** this leaderX can then instruct some other replicaY to recover from it
> ** replicaY can send RTG / PeerSync / FetchIndex requests to the leaderX
> (either on it's own volition, or because it was instructed to by leaderX) in
> an attempt to recover
> *** the responses to these recovery requests will not include updates in the
> tlog files that existed on leaderX prior to startup that hvae not yet been
> replayed
> * *AFTER* replicaY has finished it's recovery, leaderX's "Replaying tlog ...
> during startup" can finish
> ** replicaY now thinks it is in sync with leaderX, but leaderX has
> (replayed) updates the other replicas know nothing about
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13808) Query DSL should let to cache filter
[
https://issues.apache.org/jira/browse/SOLR-13808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17004576#comment-17004576
]
ASF subversion and git services commented on SOLR-13808:
Commit 3ae1a0b3bad84cdfaa3941b87a1a7fcad63a66d4 in lucene-solr's branch
refs/heads/master from Mikhail Khludnev
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=3ae1a0b ]
SOLR-13808: remove redundant @Repeat
> Query DSL should let to cache filter
>
>
> Key: SOLR-13808
> URL: https://issues.apache.org/jira/browse/SOLR-13808
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Fix For: 8.5
>
> Attachments: SOLR-13808.patch, SOLR-13808.patch
>
>
> Query DSL let to express Lucene BQ's filter
>
> {code:java}
> { query: {bool: { filter: {term: {f:name,query:"foo bar"}}} }}{code}
> However, it might easily catch the need in caching it in filter cache. This
> might rely on ExtensibleQuery and QParser:
> {code:java}
> { query: {bool: { filter: {term: {f:name,query:"foo bar", cache:true}}} }}
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13808) Query DSL should let to cache filter
[
https://issues.apache.org/jira/browse/SOLR-13808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17004572#comment-17004572
]
ASF subversion and git services commented on SOLR-13808:
Commit c01b45b924db876e715579931cd64f2b008da4bf in lucene-solr's branch
refs/heads/branch_8x from Mikhail Khludnev
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c01b45b ]
SOLR-13808: caching {!bool filter=..} by default.
> Query DSL should let to cache filter
>
>
> Key: SOLR-13808
> URL: https://issues.apache.org/jira/browse/SOLR-13808
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Fix For: 8.5
>
> Attachments: SOLR-13808.patch, SOLR-13808.patch
>
>
> Query DSL let to express Lucene BQ's filter
>
> {code:java}
> { query: {bool: { filter: {term: {f:name,query:"foo bar"}}} }}{code}
> However, it might easily catch the need in caching it in filter cache. This
> might rely on ExtensibleQuery and QParser:
> {code:java}
> { query: {bool: { filter: {term: {f:name,query:"foo bar", cache:true}}} }}
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13808) Query DSL should let to cache filter
[
https://issues.apache.org/jira/browse/SOLR-13808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17004570#comment-17004570
]
ASF subversion and git services commented on SOLR-13808:
Commit 3f29fe0b804baf0a40af378441c82ee7c6b8ec19 in lucene-solr's branch
refs/heads/master from Mikhail Khludnev
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=3f29fe0 ]
SOLR-13808: caching {!bool filter=..} by default.
> Query DSL should let to cache filter
>
>
> Key: SOLR-13808
> URL: https://issues.apache.org/jira/browse/SOLR-13808
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Fix For: 8.5
>
> Attachments: SOLR-13808.patch, SOLR-13808.patch
>
>
> Query DSL let to express Lucene BQ's filter
>
> {code:java}
> { query: {bool: { filter: {term: {f:name,query:"foo bar"}}} }}{code}
> However, it might easily catch the need in caching it in filter cache. This
> might rely on ExtensibleQuery and QParser:
> {code:java}
> { query: {bool: { filter: {term: {f:name,query:"foo bar", cache:true}}} }}
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13756) ivy cannot download org.restlet.ext.servlet jar
[ https://issues.apache.org/jira/browse/SOLR-13756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17004548#comment-17004548 ] Joel Bernstein edited comment on SOLR-13756 at 12/28/19 6:44 PM: - I opened a ticket for this on the restlet project: [https://github.com/restlet/restlet-framework-java/issues/1366] [~gyzsolt], I see you are at Cloudera. Can Cloudera host the restlet artifacts on: [https://repository.cloudera.com/artifactory/libs-release] I believe this would indeed resolve the issue. was (Author: joel.bernstein): I opened a ticket for this on the restlet project: [https://github.com/restlet/restlet-framework-java/issues/1366] [~gyzsolt], I see you are at Cloudera. Can Cloudera host the restlet artifacts on: https://repository.cloudera.com/artifactory/libs-release I believe this would indeed resolve the issue. > ivy cannot download org.restlet.ext.servlet jar > --- > > Key: SOLR-13756 > URL: https://issues.apache.org/jira/browse/SOLR-13756 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Chongchen Chen >Priority: Major > > I checkout the project and run `ant idea`, it will try to download jars. But > https://repo1.maven.org/maven2/org/restlet/jee/org.restlet.ext.servlet/2.3.0/org.restlet.ext.servlet-2.3.0.jar > will return 404 now. > [ivy:retrieve] public: tried > [ivy:retrieve] > https://repo1.maven.org/maven2/org/restlet/jee/org.restlet.ext.servlet/2.3.0/org.restlet.ext.servlet-2.3.0.jar > [ivy:retrieve]:: > [ivy:retrieve]:: FAILED DOWNLOADS:: > [ivy:retrieve]:: ^ see resolution messages for details ^ :: > [ivy:retrieve]:: > [ivy:retrieve]:: > org.restlet.jee#org.restlet;2.3.0!org.restlet.jar > [ivy:retrieve]:: > org.restlet.jee#org.restlet.ext.servlet;2.3.0!org.restlet.ext.servlet.jar > [ivy:retrieve]:: -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13756) ivy cannot download org.restlet.ext.servlet jar
[ https://issues.apache.org/jira/browse/SOLR-13756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17004548#comment-17004548 ] Joel Bernstein commented on SOLR-13756: --- I opened a ticket for this on the restlet project: [https://github.com/restlet/restlet-framework-java/issues/1366] [~gyzsolt], I see you are at Cloudera. Can Cloudera host the restlet artifacts on: https://repository.cloudera.com/artifactory/libs-release I believe this would indeed resolve the issue. > ivy cannot download org.restlet.ext.servlet jar > --- > > Key: SOLR-13756 > URL: https://issues.apache.org/jira/browse/SOLR-13756 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Chongchen Chen >Priority: Major > > I checkout the project and run `ant idea`, it will try to download jars. But > https://repo1.maven.org/maven2/org/restlet/jee/org.restlet.ext.servlet/2.3.0/org.restlet.ext.servlet-2.3.0.jar > will return 404 now. > [ivy:retrieve] public: tried > [ivy:retrieve] > https://repo1.maven.org/maven2/org/restlet/jee/org.restlet.ext.servlet/2.3.0/org.restlet.ext.servlet-2.3.0.jar > [ivy:retrieve]:: > [ivy:retrieve]:: FAILED DOWNLOADS:: > [ivy:retrieve]:: ^ see resolution messages for details ^ :: > [ivy:retrieve]:: > [ivy:retrieve]:: > org.restlet.jee#org.restlet;2.3.0!org.restlet.jar > [ivy:retrieve]:: > org.restlet.jee#org.restlet.ext.servlet;2.3.0!org.restlet.ext.servlet.jar > [ivy:retrieve]:: -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-12490) Query DSL supports for further referring and exclusion in JSON facets
[
https://issues.apache.org/jira/browse/SOLR-12490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-12490:
Attachment: SOLR-12490.patch
> Query DSL supports for further referring and exclusion in JSON facets
> --
>
> Key: SOLR-12490
> URL: https://issues.apache.org/jira/browse/SOLR-12490
> Project: Solr
> Issue Type: Improvement
> Components: Facet Module, faceting
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Labels: newdev
> Attachments: SOLR-12490.patch, SOLR-12490.patch, SOLR-12490.patch
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> It's spin off from the
> [discussion|https://issues.apache.org/jira/browse/SOLR-9685?focusedCommentId=16508720=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16508720].
>
> h2. Problem
> # after SOLR-9685 we can tag separate clauses in hairish queries like
> {{parent}}, {{bool}}
> # we can {{domain.excludeTags}}
> # we are looking for child faceting with exclusions, see SOLR-9510, SOLR-8998
>
> # but we can refer only separate params in {{domain.filter}}, it's not
> possible to refer separate clauses
> see the first comment
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Assigned] (SOLR-12490) Query DSL supports for further referring and exclusion in JSON facets
[
https://issues.apache.org/jira/browse/SOLR-12490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev reassigned SOLR-12490:
---
Assignee: Mikhail Khludnev
> Query DSL supports for further referring and exclusion in JSON facets
> --
>
> Key: SOLR-12490
> URL: https://issues.apache.org/jira/browse/SOLR-12490
> Project: Solr
> Issue Type: Improvement
> Components: Facet Module, faceting
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Labels: newdev
> Attachments: SOLR-12490.patch, SOLR-12490.patch
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> It's spin off from the
> [discussion|https://issues.apache.org/jira/browse/SOLR-9685?focusedCommentId=16508720=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16508720].
>
> h2. Problem
> # after SOLR-9685 we can tag separate clauses in hairish queries like
> {{parent}}, {{bool}}
> # we can {{domain.excludeTags}}
> # we are looking for child faceting with exclusions, see SOLR-9510, SOLR-8998
>
> # but we can refer only separate params in {{domain.filter}}, it's not
> possible to refer separate clauses
> see the first comment
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-10912) Adding automatic patch validation
[
https://issues.apache.org/jira/browse/SOLR-10912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17004489#comment-17004489
]
Mikhail Khludnev commented on SOLR-10912:
-
[~sarowe], regarding
??Since Allen Wittenauer wrote above that "The job on Jenkins that feeds
test-patch is NOT github aware", I don't plan on doing this verification. I'll
include this on a TODO list below.??
Can it be YETUS-614, which is fixed in Yetus 0.8.0? Note, I tried to use github
PR link in precommit, but got just this
https://builds.apache.org/job/PreCommit-SOLR-Build/641/console
{code:java}
[Sat Dec 28 08:14:15 UTC 2019 DEBUG]: jira_http_fetch:
https://issues.apache.org/jira/browse/SOLR-12490
[Sat Dec 28 08:14:17 UTC 2019 DEBUG]: jira_locate_patch: SOLR-12490 seemed like
a Github PR, but there was a failure.
{code}
How we can evaluate Yetus 0.8.0 or the latest one?
> Adding automatic patch validation
> -
>
> Key: SOLR-10912
> URL: https://issues.apache.org/jira/browse/SOLR-10912
> Project: Solr
> Issue Type: Improvement
> Components: Build
>Reporter: Mano Kovacs
>Assignee: Steven Rowe
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-10912.ok-patch-in-core.patch, SOLR-10912.patch,
> SOLR-10912.patch, SOLR-10912.sample-patch.patch,
> SOLR-10912.solj-contrib-facet-error.patch
>
>
> Proposing introduction of automated patch validation, similar what Hadoop or
> other Apache projects are using (see link). This would ensure that every
> patch passes a certain set of criterions before getting approved. It would
> save time for developer (faster feedback loop), save time for committers
> (less step to do manually), and would increase quality.
> Hadoop is currently using Apache Yetus to run validations, which seems to be
> a good direction to start. This jira could be the board of discussing the
> preferred solution.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] Traktormaster commented on issue #1123: LUCENE-9093: Unified highlighter with word separator never gives context to the left
Traktormaster commented on issue #1123: LUCENE-9093: Unified highlighter with word separator never gives context to the left URL: https://github.com/apache/lucene-solr/pull/1123#issuecomment-569408594 Basically the whole patch has been reworked, here are the highlights: - About half as many calls to `preceding()` and `following()` on the wrapped BI. - `fragsize` is about the length of the contextual text around the match. (it's relation to the snippet size is indirect) - `fragalign` has been renamed to `fragAlignRatio`. Changed it's default value to `0.5`. - Made the hidden `closestTo/targetLen` mode the default instead of `minimumLen`. This adds an automatic slop-like behaviour. - The new parameter `fragsizeIsMinimum` can be used to switch back to the previously used mode. (minimum mode is a little faster) - Changed the call of `following(start)` in `FieldHighlighter` to `following(end - 1)` for performance and correctness. - Tests and docs have been updated. With these defaults the UH will give more meaingful results as-is. To have even more similar results to the older highlighters the `hl.bs.type` can be switched to `WORD`. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13759) Optimize Queries when query filtering by TRA router.field
[ https://issues.apache.org/jira/browse/SOLR-13759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17004426#comment-17004426 ] mosh commented on SOLR-13759: - Gus, you're absolutely right about the *FilterQuery* parsing part and I liked the concept of treating each *FilterQuery* clause as an individual query and parse it accordingly. Once parsed the queries I understand the necessity of collecting the query clauses and for appling our collection filtering logic but I am not quite sure that I got how *QueryVisitor* will be our savior here. I was not familiar with *QueyVisitor* but after reading about it (mostly going through the code and digging down the LUCENE-3041 issue) it seems like it is *Term* oriented and, on the other hand, the queries that are interesting us and on which we are basing our optimization on are not consist of *Term*... or maybe I am missing something... I would be glad if you could explain deeply what's the idea of using *QueryVisitor*. Maybe overriding #Query.visit method and collecting the relevant part of the query clauses is the way to go ?! Thanks for the review! > Optimize Queries when query filtering by TRA router.field > - > > Key: SOLR-13759 > URL: https://issues.apache.org/jira/browse/SOLR-13759 > Project: Solr > Issue Type: Sub-task >Reporter: mosh >Assignee: Gus Heck >Priority: Minor > Attachments: SOLR-13759.patch, SOLR-13759.patch, > image-2019-12-09-22-45-51-721.png > > > We are currently testing TRA using Solr 7.7, having >300 shards in the alias, > with much growth in the coming months. > The "hot" data(in our case, more recent) will be stored on stronger > nodes(SSD, more RAM, etc). > A proposal of optimizing queries will be by filtering query by date range, by > that we will be able to querying the specific TRA collections taking > advantage of the TRA mechanism of partitioning data based on date. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-12490) Query DSL supports for further referring and exclusion in JSON facets
[
https://issues.apache.org/jira/browse/SOLR-12490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17004423#comment-17004423
]
Lucene/Solr QA commented on SOLR-12490:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 6s{color}
| {color:red} SOLR-12490 does not apply to master. Rebase required? Wrong
Branch? See
https://wiki.apache.org/solr/HowToContribute#Creating_the_patch_file for help.
{color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-12490 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12983575/SOLR-12490.patch |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/641/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Query DSL supports for further referring and exclusion in JSON facets
> --
>
> Key: SOLR-12490
> URL: https://issues.apache.org/jira/browse/SOLR-12490
> Project: Solr
> Issue Type: Improvement
> Components: Facet Module, faceting
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: newdev
> Attachments: SOLR-12490.patch, SOLR-12490.patch
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> It's spin off from the
> [discussion|https://issues.apache.org/jira/browse/SOLR-9685?focusedCommentId=16508720=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16508720].
>
> h2. Problem
> # after SOLR-9685 we can tag separate clauses in hairish queries like
> {{parent}}, {{bool}}
> # we can {{domain.excludeTags}}
> # we are looking for child faceting with exclusions, see SOLR-9510, SOLR-8998
>
> # but we can refer only separate params in {{domain.filter}}, it's not
> possible to refer separate clauses
> see the first comment
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
