[jira] [Commented] (SOLR-11645) When there are duplicate java commandline arguments, the Solr UI dashboard doesn't show Args at all
[
https://issues.apache.org/jira/browse/SOLR-11645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16254072#comment-16254072
]
Stefan Matheis (steffkes) commented on SOLR-11645:
--
Shawn, i don't have a current checkout / environment - skimming over your patch
as well as https://docs.angularjs.org/error/ngRepeat/dupes makes it look just
fine!
bq. I noticed in the javascript code that the command line arguments are sorted
before they are displayed. Is that something we really want to do? Shouldn't
they appear in actual order?
I can't say for sure when this landed - i can see both sides of it: having it
sorted makes it easier to recognize a duplicate (which as far as i know is only
a technically, java doesn't care about does it?) while having it in the actual
order probably helps when people are trying to group them in a sorting way
(relevant things together, or global/local/tenant-based properties).
include this change in this ticket and we'll see where it goes - i'd probably
bet that most people won't even notice it.
> When there are duplicate java commandline arguments, the Solr UI dashboard
> doesn't show Args at all
> ---
>
> Key: SOLR-11645
> URL: https://issues.apache.org/jira/browse/SOLR-11645
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Affects Versions: 7.1
>Reporter: Shawn Heisey
>Priority: Minor
> Attachments: SOLR-11645.patch, SOLR-11645.patch
>
>
> A user couldn't get the "Args" to display in the admin UI.
> Ultimately it was determined that they had duplicate arguments on their
> commandline, and this was resulting in an error in the browser:
> {code}
> Error: [ngRepeat:dupes] Duplicates in a repeater are not allowed. Use
> 'track by' expression to specify unique keys. Repeater: arg in
> commandLineArgs, Duplicate key: string:-XX:+UseGCLogFileRotation, Duplicate
> value: -XX:+UseGCLogFileRotation
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8956) Highlight missing in Analysis View
[
https://issues.apache.org/jira/browse/SOLR-8956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16016104#comment-16016104
]
Stefan Matheis (steffkes) commented on SOLR-8956:
-
[~janhoy] not sure how it got there, last time i've checked it wasn't ;o but
given it is now, we can close this ticket, yep
> Highlight missing in Analysis View
> --
>
> Key: SOLR-8956
> URL: https://issues.apache.org/jira/browse/SOLR-8956
> Project: Solr
> Issue Type: Bug
> Components: Admin UI, Schema and Analysis
>Affects Versions: 5.4, 5.5, 6.0
>Reporter: Stefan Matheis (steffkes)
>Assignee: Upayavira
> Attachments: analysis-fixed.png, Solr+Admin+2016-04-06+12-03-36.png,
> Solr+Admin+2016-04-06+12-09-23.png
>
>
> the new analysis view is missing the highlighting for matches. screenshots
> appended to show the difference.
> this was reported by user {{mloeb}} on #solr yesterday. initially he asked
> about highlighting in general - questioning a few things has gotten us to the
> analysis view for debugging purposes. not seeing any highlights given the
> index/query data - i've asked him to try the very same in the old admin ui
> where it worked.
> i haven't dived in the code yet, probably [~upayavira] can give a hint where
> / at what to look?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10042) Delete old deprecated Admin UI
[ https://issues.apache.org/jira/browse/SOLR-10042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16012060#comment-16012060 ] Stefan Matheis (steffkes) commented on SOLR-10042: -- [~janhoy] LGTM. as far as i know the structure is pretty well separated between the old and the current UI, so it should be okay to remove all the old files, yepp > Delete old deprecated Admin UI > -- > > Key: SOLR-10042 > URL: https://issues.apache.org/jira/browse/SOLR-10042 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Reporter: Jan Høydahl >Assignee: Jan Høydahl > Fix For: master (7.0) > > Attachments: SOLR-10042.patch > > > The old jQuery based Admin UI has been deprecated since 6.0. Let us clean up > the last known bugs in Angular UI and simply delete the old UI in master. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4720) Admin UI - Empty List of Iterations on Slave
[ https://issues.apache.org/jira/browse/SOLR-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15568009#comment-15568009 ] Stefan Matheis (steffkes) commented on SOLR-4720: - Go for it - this was basically more of a reminder than a real issue. At least i've never heard anyone talking about it and it's a edge case. > Admin UI - Empty List of Iterations on Slave > > > Key: SOLR-4720 > URL: https://issues.apache.org/jira/browse/SOLR-4720 > Project: Solr > Issue Type: Improvement > Components: web gui >Reporter: Stefan Matheis (steffkes) >Assignee: Stefan Matheis (steffkes) >Priority: Trivial > Fix For: 4.9, 6.0 > > > If you start your slave and have a look at the Replication Page, the list of > iterations may be empty - but it's not cristal clear if it's a bug (iteration > happend, info available but not shown) or just a matter of fact, that there > has nothing happend. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-9210) Dataimport Handlers are only available in original User Interface
[ https://issues.apache.org/jira/browse/SOLR-9210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15331608#comment-15331608 ] Stefan Matheis (steffkes) edited comment on SOLR-9210 at 6/15/16 12:13 PM: --- This is a duplicate of SOLR-8993, therefore closing this one. was (Author: steffkes): This is a duplicate of SOLR-8983, therefore closing this one. > Dataimport Handlers are only available in original User Interface > - > > Key: SOLR-9210 > URL: https://issues.apache.org/jira/browse/SOLR-9210 > Project: Solr > Issue Type: Bug > Components: UI >Affects Versions: 6.0.1 > Environment: Linux >Reporter: ClaudeHe >Assignee: Stefan Matheis (steffkes) >Priority: Minor > Original Estimate: 1h > Remaining Estimate: 1h > > 2 defined Dataimport Handlers, Migrated from 5.2. > UI Message: "Sorry no dataimport-handler defined" > No Problem with: > original UI > using the dataimport-handler URL directly > The Problem still occurs after removing one of the Dataimport Handlers > Here the config: > > > import_a_dih.xml > > > > > import_b_dih.xml > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-9210) Dataimport Handlers are only available in original User Interface
[ https://issues.apache.org/jira/browse/SOLR-9210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) resolved SOLR-9210. - Resolution: Duplicate Assignee: Stefan Matheis (steffkes) This is a duplicate of SOLR-8983, therefore closing this one. > Dataimport Handlers are only available in original User Interface > - > > Key: SOLR-9210 > URL: https://issues.apache.org/jira/browse/SOLR-9210 > Project: Solr > Issue Type: Bug > Components: UI >Affects Versions: 6.0.1 > Environment: Linux >Reporter: ClaudeHe >Assignee: Stefan Matheis (steffkes) >Priority: Minor > Original Estimate: 1h > Remaining Estimate: 1h > > 2 defined Dataimport Handlers, Migrated from 5.2. > UI Message: "Sorry no dataimport-handler defined" > No Problem with: > original UI > using the dataimport-handler URL directly > The Problem still occurs after removing one of the Dataimport Handlers > Here the config: > > > import_a_dih.xml > > > > > import_b_dih.xml > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9196) Dead link on SolrConfigXml wiki page
[ https://issues.apache.org/jira/browse/SOLR-9196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15320505#comment-15320505 ] Stefan Matheis (steffkes) commented on SOLR-9196: - Excellent Point Jan, didn't think about that before applying the change. At least put a large banner on top of the page as we did on other pages as well, in case we're not entirely sure that all relevant content got already moved into the ref guide - until we're done with that migration. > Dead link on SolrConfigXml wiki page > > > Key: SOLR-9196 > URL: https://issues.apache.org/jira/browse/SOLR-9196 > Project: Solr > Issue Type: Bug > Components: documentation >Reporter: Steen Manniche >Assignee: Stefan Matheis (steffkes) >Priority: Trivial > Labels: documentation > > Under the headline http://wiki.apache.org/solr/SolrConfigXml#lib the link to > the example solrconfig.xml at > https://svn.apache.org/repos/asf/lucene/dev/trunk/solr/example/solr/collection1/conf/solrconfig.xml > is a 404 > Should perhaps point to > https://raw.githubusercontent.com/apache/lucene-solr/master/solr/example/files/conf/solrconfig.xml > instead? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-9196) Dead link on SolrConfigXml wiki page
[ https://issues.apache.org/jira/browse/SOLR-9196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) resolved SOLR-9196. - Resolution: Fixed I've fixed the link you've mentioned and another one pointing to the very same broken destination - it's currently persisting, which takes quite some time. just so you're not wondering why the change itself might not yet be visible. Since the Solr Wiki is maintained by the Community, you can always get an account and help improve the documentation on your own [~steen.manniche] - if you like to do so, drop a short note on the mailing list requesting access as wiki contributor. > Dead link on SolrConfigXml wiki page > > > Key: SOLR-9196 > URL: https://issues.apache.org/jira/browse/SOLR-9196 > Project: Solr > Issue Type: Bug > Components: documentation >Reporter: Steen Manniche >Assignee: Stefan Matheis (steffkes) >Priority: Trivial > Labels: documentation > > Under the headline http://wiki.apache.org/solr/SolrConfigXml#lib the link to > the example solrconfig.xml at > https://svn.apache.org/repos/asf/lucene/dev/trunk/solr/example/solr/collection1/conf/solrconfig.xml > is a 404 > Should perhaps point to > https://raw.githubusercontent.com/apache/lucene-solr/master/solr/example/files/conf/solrconfig.xml > instead? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-9196) Dead link on SolrConfigXml wiki page
[ https://issues.apache.org/jira/browse/SOLR-9196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) reassigned SOLR-9196: --- Assignee: Stefan Matheis (steffkes) > Dead link on SolrConfigXml wiki page > > > Key: SOLR-9196 > URL: https://issues.apache.org/jira/browse/SOLR-9196 > Project: Solr > Issue Type: Bug > Components: documentation >Reporter: Steen Manniche >Assignee: Stefan Matheis (steffkes) >Priority: Trivial > Labels: documentation > > Under the headline http://wiki.apache.org/solr/SolrConfigXml#lib the link to > the example solrconfig.xml at > https://svn.apache.org/repos/asf/lucene/dev/trunk/solr/example/solr/collection1/conf/solrconfig.xml > is a 404 > Should perhaps point to > https://raw.githubusercontent.com/apache/lucene-solr/master/solr/example/files/conf/solrconfig.xml > instead? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9098) Show if schema is currently mutable or not
[
https://issues.apache.org/jira/browse/SOLR-9098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15278301#comment-15278301
]
Stefan Matheis (steffkes) commented on SOLR-9098:
-
Okay, so probably [this part of Varun's
comment|https://issues.apache.org/jira/browse/SOLR-8386?focusedCommentId=15048595=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15048595]
gives a hint:
bq. In trunk , if no schema factory is specified then ManagedIndexSchemaFactory
is used by default.
sounds a bit like "if no factory is specified, no information about it is
included in the response .." but i'd have to check the relevant code once i get
there.
so rather than introduce a new key in the response for {{/schema}} as my patch
suggested we should try to get the bits for {{/config}} back in and extend the
existing check.
> Show if schema is currently mutable or not
> --
>
> Key: SOLR-9098
> URL: https://issues.apache.org/jira/browse/SOLR-9098
> Project: Solr
> Issue Type: Improvement
> Components: Schema and Analysis
>Reporter: Stefan Matheis (steffkes)
>Assignee: Stefan Matheis (steffkes)
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: SOLR-9098.patch
>
>
> When our schema is not mutable (for whatever reason) the only way to get that
> information is to try a change and see if it fails, like this:
> {code}$ curl -i localhost:8983/solr/dummy/schema -d '{ "add-field":{
> "name":"sell-by", "type":"tdate", "stored":true } }'
> HTTP/1.1 200 OK
> Content-Type: application/json; charset=UTF-8
> Content-Length: 112
> {
> "responseHeader":{
> "status":0,
> "QTime":5
> },
> "errors":[
> {
> "errorMessages":"schema is not editable"
> }
> ]
> }{code}
> this message is caused by {{SchemaManager#performOperations}} which checks if
> {{schema instanceof ManagedIndexSchema && schema.isMutable()}} - we could
> include that information in the response for {{/schema}} and allow users to
> see upfront if they could modify the schema or rather not.
> [~steve_rowe] i'm not entirely sure that i didn't miss any tests related to
> the schema handler, would you mind having a look?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9098) Show if schema is currently mutable or not
[
https://issues.apache.org/jira/browse/SOLR-9098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15278250#comment-15278250
]
Stefan Matheis (steffkes) commented on SOLR-9098:
-
Thanks for mentioning that Steve! Further checking revealed, that the schema
page already does the following request:
{code}Config.get({core: $routeParams.core}, function(data) {
$scope.isSchemaUpdatable = (data.config.hasOwnProperty('schemaFactory') ==
false || data.config.schemaFactory.class == "ManagedIndexSchemaFactory");
});{code}
looking at it, i was following to SOLR-8386 - so i'd say somewhere in the past,
it was already there and probably got lost again?
Reading through {{ManagedIndexSchemaFactory}} i got the impression that it's
not entirely impossible to have a immutable schema while using it - which would
imply that we'd need another check, instead of just checking for the class in
use. or am i mistaken here?
> Show if schema is currently mutable or not
> --
>
> Key: SOLR-9098
> URL: https://issues.apache.org/jira/browse/SOLR-9098
> Project: Solr
> Issue Type: Improvement
> Components: Schema and Analysis
>Reporter: Stefan Matheis (steffkes)
>Assignee: Stefan Matheis (steffkes)
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: SOLR-9098.patch
>
>
> When our schema is not mutable (for whatever reason) the only way to get that
> information is to try a change and see if it fails, like this:
> {code}$ curl -i localhost:8983/solr/dummy/schema -d '{ "add-field":{
> "name":"sell-by", "type":"tdate", "stored":true } }'
> HTTP/1.1 200 OK
> Content-Type: application/json; charset=UTF-8
> Content-Length: 112
> {
> "responseHeader":{
> "status":0,
> "QTime":5
> },
> "errors":[
> {
> "errorMessages":"schema is not editable"
> }
> ]
> }{code}
> this message is caused by {{SchemaManager#performOperations}} which checks if
> {{schema instanceof ManagedIndexSchema && schema.isMutable()}} - we could
> include that information in the response for {{/schema}} and allow users to
> see upfront if they could modify the schema or rather not.
> [~steve_rowe] i'm not entirely sure that i didn't miss any tests related to
> the schema handler, would you mind having a look?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-9100) Add version-identifier to all files loaded by Admin UI
Stefan Matheis (steffkes) created SOLR-9100: --- Summary: Add version-identifier to all files loaded by Admin UI Key: SOLR-9100 URL: https://issues.apache.org/jira/browse/SOLR-9100 Project: Solr Issue Type: Improvement Components: web gui Affects Versions: 6.0, 5.5 Reporter: Stefan Matheis (steffkes) Assignee: Stefan Matheis (steffkes) Priority: Minor Fix For: master (7.0) Attachments: SOLR-9100.patch The Angular UI added a bunch of javascript files to the base html, given that we had some problems w/ users getting cached files in their Brower when using a new release, i suggest we add those identifier (back) for those files as well. [~upayavira] mind looking if i missed a reference? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-9100) Add version-identifier to all files loaded by Admin UI
[ https://issues.apache.org/jira/browse/SOLR-9100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-9100: Attachment: SOLR-9100.patch > Add version-identifier to all files loaded by Admin UI > -- > > Key: SOLR-9100 > URL: https://issues.apache.org/jira/browse/SOLR-9100 > Project: Solr > Issue Type: Improvement > Components: web gui >Affects Versions: 5.5, 6.0 >Reporter: Stefan Matheis (steffkes) >Assignee: Stefan Matheis (steffkes) >Priority: Minor > Fix For: master (7.0) > > Attachments: SOLR-9100.patch > > > The Angular UI added a bunch of javascript files to the base html, given that > we had some problems w/ users getting cached files in their Brower when using > a new release, i suggest we add those identifier (back) for those files as > well. > [~upayavira] mind looking if i missed a reference? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-9098) Show if schema is currently mutable or not
[
https://issues.apache.org/jira/browse/SOLR-9098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Matheis (steffkes) updated SOLR-9098:
Attachment: SOLR-9098.patch
> Show if schema is currently mutable or not
> --
>
> Key: SOLR-9098
> URL: https://issues.apache.org/jira/browse/SOLR-9098
> Project: Solr
> Issue Type: Improvement
> Components: Schema and Analysis
>Reporter: Stefan Matheis (steffkes)
>Assignee: Stefan Matheis (steffkes)
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: SOLR-9098.patch
>
>
> When our schema is not mutable (for whatever reason) the only way to get that
> information is to try a change and see if it fails, like this:
> {code}$ curl -i localhost:8983/solr/dummy/schema -d '{ "add-field":{
> "name":"sell-by", "type":"tdate", "stored":true } }'
> HTTP/1.1 200 OK
> Content-Type: application/json; charset=UTF-8
> Content-Length: 112
> {
> "responseHeader":{
> "status":0,
> "QTime":5
> },
> "errors":[
> {
> "errorMessages":"schema is not editable"
> }
> ]
> }{code}
> this message is caused by {{SchemaManager#performOperations}} which checks if
> {{schema instanceof ManagedIndexSchema && schema.isMutable()}} - we could
> include that information in the response for {{/schema}} and allow users to
> see upfront if they could modify the schema or rather not.
> [~steve_rowe] i'm not entirely sure that i didn't miss any tests related to
> the schema handler, would you mind having a look?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-9098) Show if schema is currently mutable or not
Stefan Matheis (steffkes) created SOLR-9098:
---
Summary: Show if schema is currently mutable or not
Key: SOLR-9098
URL: https://issues.apache.org/jira/browse/SOLR-9098
Project: Solr
Issue Type: Improvement
Components: Schema and Analysis
Reporter: Stefan Matheis (steffkes)
Assignee: Stefan Matheis (steffkes)
Priority: Minor
Fix For: master (7.0)
When our schema is not mutable (for whatever reason) the only way to get that
information is to try a change and see if it fails, like this:
{code}$ curl -i localhost:8983/solr/dummy/schema -d '{ "add-field":{
"name":"sell-by", "type":"tdate", "stored":true } }'
HTTP/1.1 200 OK
Content-Type: application/json; charset=UTF-8
Content-Length: 112
{
"responseHeader":{
"status":0,
"QTime":5
},
"errors":[
{
"errorMessages":"schema is not editable"
}
]
}{code}
this message is caused by {{SchemaManager#performOperations}} which checks if
{{schema instanceof ManagedIndexSchema && schema.isMutable()}} - we could
include that information in the response for {{/schema}} and allow users to see
upfront if they could modify the schema or rather not.
[~steve_rowe] i'm not entirely sure that i didn't miss any tests related to the
schema handler, would you mind having a look?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9010) Query tab - allow using browser "previous", "next" buttons to load previous/next queries in the form
[ https://issues.apache.org/jira/browse/SOLR-9010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15247664#comment-15247664 ] Stefan Matheis (steffkes) commented on SOLR-9010: - Right after i've wrote that comment, i did realize how many questions i've included in it already - Jakub would you mind taking this idea to the mailing-list, so we could discuss it with others and then return to this ticket? enhance the description with proper details and things like that > Query tab - allow using browser "previous", "next" buttons to load > previous/next queries in the form > > > Key: SOLR-9010 > URL: https://issues.apache.org/jira/browse/SOLR-9010 > Project: Solr > Issue Type: Improvement > Components: web gui >Affects Versions: 5.5 > Environment: Lucene Solr for Linux (downloaded as an archive) >Reporter: Jakub Zakrzewski > > Hi guys, > I'm new here, however I have been using solr web admin interface for some > weeks now. > My problem is that I often would like to access my previous queries loaded in > the form. However it is not possible now. > I'd like to have an url that opened will load the values to the form fields. > Now the web gui displays an url which is a solr request url and not web admin > query url. > I could implement this feature or create a web page that will use this > feature. Are you interested? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9010) Query tab - allow using browser "previous", "next" buttons to load previous/next queries in the form
[ https://issues.apache.org/jira/browse/SOLR-9010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15247663#comment-15247663 ] Stefan Matheis (steffkes) commented on SOLR-9010: - Hey [~jzak], short note aside: normally we try to bring up such questions / feature-ideas on the mailing list to discuss the details before we open up JIRA-Tickets. if you'd remember that for the next time, that'd be perfect. related to your suggestion: i think it's a nice addition. i don't have an idea, how i'd build something like that - especially in terms of the user interface (how to navigate back and forth ..) - but if it would be possible that you bring up a patch, a screenshot/-mock or at least a description of how you think it might work, we could discuss that. -Stefan > Query tab - allow using browser "previous", "next" buttons to load > previous/next queries in the form > > > Key: SOLR-9010 > URL: https://issues.apache.org/jira/browse/SOLR-9010 > Project: Solr > Issue Type: Improvement > Components: web gui >Affects Versions: 5.5 > Environment: Lucene Solr for Linux (downloaded as an archive) >Reporter: Jakub Zakrzewski > > Hi guys, > I'm new here, however I have been using solr web admin interface for some > weeks now. > My problem is that I often would like to access my previous queries loaded in > the form. However it is not possible now. > I'd like to have an url that opened will load the values to the form fields. > Now the web gui displays an url which is a solr request url and not web admin > query url. > I could implement this feature or create a web page that will use this > feature. Are you interested? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8993) New UI can't show DIH
[
https://issues.apache.org/jira/browse/SOLR-8993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15242885#comment-15242885
]
Stefan Matheis (steffkes) commented on SOLR-8993:
-
[~shawn.mccorkell] thanks for joining, i'm not entirely sure if the first part
of your comment is really the same issue? Obviously i can be closely related,
but we're talking about not showing any handlers at all - unless you have one
named {{dataimport}} (at least it looks that way)
bq. They both show up named properly in the new UI but load the config only
from the first handler /dataimport. when I click on /dataimport-date-range I
see the last run time, details and config from /dataimport.
that would mean, when you have {{dataimport-date-range}} selected you can't
trigger a import on that as well? given your description i'd guess it will
trigger the (default) {{dataimport}} instead of the selected one. can you
confirm that?
although i'm pretty sure you're right about lazy loading the list of handlers.
> New UI can't show DIH
> -
>
> Key: SOLR-8993
> URL: https://issues.apache.org/jira/browse/SOLR-8993
> Project: Solr
> Issue Type: Bug
> Components: UI
>Affects Versions: 6.0
>Reporter: Buğra Yıldırım
>Priority: Critical
> Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png,
> screenshot-4.png
>
>
> New UI can't show DIHs when more than one DIH exists. I switch to old UI for
> importing from database.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8993) New UI can't show DIH
[
https://issues.apache.org/jira/browse/SOLR-8993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15242794#comment-15242794
]
Stefan Matheis (steffkes) commented on SOLR-8993:
-
No need to excuse yourself, bug reports are appreciated and helpful - i'm just
trying to figure out what's the actual problem at hand. if the new ui is able
at all to show dataimport handler, if it does require a specific name to be
included in the list of defined handlers or if the problem is located elsewhere.
which is why i've asked if you have (or otherwise could) checked if it does
work, if one of the handlers is named {{dataimport}} w/o any pre- or suffix.
your two screenshots do show, that it does not work at all - but in a case,
where none of the handlers are named as such.
> New UI can't show DIH
> -
>
> Key: SOLR-8993
> URL: https://issues.apache.org/jira/browse/SOLR-8993
> Project: Solr
> Issue Type: Bug
> Components: UI
>Affects Versions: 6.0
>Reporter: Buğra Yıldırım
>Priority: Critical
> Attachments: screenshot-1.png, screenshot-2.png
>
>
> New UI can't show DIHs when more than one DIH exists. I switch to old UI for
> importing from database.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8993) New UI can't show DIH
[
https://issues.apache.org/jira/browse/SOLR-8993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15242787#comment-15242787
]
Stefan Matheis (steffkes) commented on SOLR-8993:
-
Thanks for the screenshots [~bugra.yildirim] - still trying to confirm your
initial report.
Does it matter if the configuration does use {{dataimport}}? obviously the old
ui is able to list all of them, no matter how they are named. but i'm curious
what's the case for the new ui.
> New UI can't show DIH
> -
>
> Key: SOLR-8993
> URL: https://issues.apache.org/jira/browse/SOLR-8993
> Project: Solr
> Issue Type: Bug
> Components: UI
>Affects Versions: 6.0
>Reporter: Buğra Yıldırım
>Priority: Critical
> Attachments: screenshot-1.png, screenshot-2.png
>
>
> New UI can't show DIHs when more than one DIH exists. I switch to old UI for
> importing from database.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8993) New UI can't show DIH
[ https://issues.apache.org/jira/browse/SOLR-8993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15242740#comment-15242740 ] Stefan Matheis (steffkes) commented on SOLR-8993: - [~bugra.yildirim] i'm not entirely sure i understand what you're saying this this. does the new ui require a thing named "dataimport" to work? is the amount of configurations relevant? what exactly does "not work" mean in this case? do you get a error message (on screen) or something like that? > New UI can't show DIH > - > > Key: SOLR-8993 > URL: https://issues.apache.org/jira/browse/SOLR-8993 > Project: Solr > Issue Type: Bug > Components: UI >Affects Versions: 6.0 >Reporter: Buğra Yıldırım >Priority: Critical > > New UI can't show DIHs when more than one DIH exists. I switch to old UI for > importing from database. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8956) Highlight missing in Analysis View
[
https://issues.apache.org/jira/browse/SOLR-8956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15242568#comment-15242568
]
Stefan Matheis (steffkes) commented on SOLR-8956:
-
[~elyograg] i like it, but given that the current functionality is done on the
server - i think this one should be as well. for a bunch of reasons, one of
them being: it's functionality that is used while the magic happens during
search. whatever we would do on the client-side while the user uses the
analysis-screen .. we can't guarantee that the results are equal. which is why
i wouldn't even try to replicate the results in the first place. like the
{{match}}-attribute we get back within the response, we should include should
information. using them on the client-side is obviously far more easy, afaik we
don't have that data yet, do we?
> Highlight missing in Analysis View
> --
>
> Key: SOLR-8956
> URL: https://issues.apache.org/jira/browse/SOLR-8956
> Project: Solr
> Issue Type: Bug
> Components: Schema and Analysis, web gui
>Affects Versions: 5.4, 5.5, master
>Reporter: Stefan Matheis (steffkes)
>Assignee: Upayavira
> Attachments: Solr+Admin+2016-04-06+12-03-36.png,
> Solr+Admin+2016-04-06+12-09-23.png
>
>
> the new analysis view is missing the highlighting for matches. screenshots
> appended to show the difference.
> this was reported by user {{mloeb}} on #solr yesterday. initially he asked
> about highlighting in general - questioning a few things has gotten us to the
> analysis view for debugging purposes. not seeing any highlights given the
> index/query data - i've asked him to try the very same in the old admin ui
> where it worked.
> i haven't dived in the code yet, probably [~upayavira] can give a hint where
> / at what to look?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8956) Highlight missing in Analysis View
[
https://issues.apache.org/jira/browse/SOLR-8956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15242566#comment-15242566
]
Stefan Matheis (steffkes) commented on SOLR-8956:
-
bq. [~steffkes] is it simply that if a term appears in both sides (query/index)
it gets highlighted? Is this represented in the underlying data, or something
you do client-side?
even simpler than that [~upayavira], [relevant code from the
analysis.js|https://git1-us-west.apache.org/repos/asf/lucene-solr/repo?p=lucene-solr.git;a=blob;f=solr/webapp/web/js/scripts/analysis.js;h=5fcadaf0f1a6c97c7be4a4739275f9d9bcc1ceb2;hb=HEAD#l517]:
{code} 514 if( analysis_data[type][i+1][j].match &&
515 ( 'text' === short_key || 'raw_bytes' ===
short_key ) )
516 {
517 classes.push( 'match' );
518 }{code}
there is a {{match}} attribute in the response auf the analysis endpoint. the
check in L515 is used to limit the cells that get highlighted, iirc (think of
the verbose view w/ all the additional information per term)
> Highlight missing in Analysis View
> --
>
> Key: SOLR-8956
> URL: https://issues.apache.org/jira/browse/SOLR-8956
> Project: Solr
> Issue Type: Bug
> Components: Schema and Analysis, web gui
>Affects Versions: 5.4, 5.5, master
>Reporter: Stefan Matheis (steffkes)
>Assignee: Upayavira
> Attachments: Solr+Admin+2016-04-06+12-03-36.png,
> Solr+Admin+2016-04-06+12-09-23.png
>
>
> the new analysis view is missing the highlighting for matches. screenshots
> appended to show the difference.
> this was reported by user {{mloeb}} on #solr yesterday. initially he asked
> about highlighting in general - questioning a few things has gotten us to the
> analysis view for debugging purposes. not seeing any highlights given the
> index/query data - i've asked him to try the very same in the old admin ui
> where it worked.
> i haven't dived in the code yet, probably [~upayavira] can give a hint where
> / at what to look?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8982) UI: Cloud -> Dump option isn't working
[ https://issues.apache.org/jira/browse/SOLR-8982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15240763#comment-15240763 ] Stefan Matheis (steffkes) commented on SOLR-8982: - bq. Or delete the functionality. What benefit does it give you? In what way is it useful to you? The reason we added them in the first place was to get as much information as possible (from one place) when a user might have problems with his cloud-setup. i can't say if it did get use often, never used the cloud functionality that extensive on my own. > UI: Cloud -> Dump option isn't working > -- > > Key: SOLR-8982 > URL: https://issues.apache.org/jira/browse/SOLR-8982 > Project: Solr > Issue Type: Bug > Components: UI >Affects Versions: 6.0 >Reporter: Hoss Man > > the "Dump" option on the (new) angular UI Cloud screen doesn't seem to be > working. the "pre" tag where all the data is suppose to appear is empty... > http://127.0.1.1:8983/solr/#/~cloud > Work around: use the older deprecated UI, it does appear to be working... > http://127.0.1.1:8983/solr/old.html#/~cloud -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8730) Experimental UI, the hl.fl is not properly set doing queries
[ https://issues.apache.org/jira/browse/SOLR-8730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-8730: Component/s: web gui > Experimental UI, the hl.fl is not properly set doing queries > > > Key: SOLR-8730 > URL: https://issues.apache.org/jira/browse/SOLR-8730 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 5.4.1 > Environment: Debian wheezy x64, 4 processors, 4gb memory, 4 SOLR > clouds servers >Reporter: Jean-Renaud Margelidon >Assignee: Upayavira >Priority: Minor > Fix For: 6.0 > > > When using the experiment UI and doing searches on collection, when > populating the hl.fl field, the value is used for the fl instead. > URL generated: > http://127.0.0.1/solr/collection/select?fl=content=on=on=html=json > URL Expected: > http://127.0.0.1/solr/collection/select?hl.fl=content=on=on=html=json -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-8957) Query view generates incorrect param names
[
https://issues.apache.org/jira/browse/SOLR-8957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Matheis (steffkes) closed SOLR-8957.
---
Resolution: Duplicate
Assignee: Stefan Matheis (steffkes)
Indeed, thanks for pointing that out [~upayavira]. SOLR-8730 was created in
February, didn't see it when i've looked for existing tickets.
> Query view generates incorrect param names
> --
>
> Key: SOLR-8957
> URL: https://issues.apache.org/jira/browse/SOLR-8957
> Project: Solr
> Issue Type: Bug
> Components: web gui
>Affects Versions: 5.4, 5.5, master
>Reporter: Stefan Matheis (steffkes)
>Assignee: Stefan Matheis (steffkes)
>
> Following SOLR-8956 we discovered that options within a section are leading
> to incorrect param-names.
> enabling {{hl}} and furthermore setting "something" for {{hl.fl}} (just
> below) lead to a query containing {{hl=true=something}} obviously missing
> the {{hl.}} prefix, same was true for {{hl.simple.pre}} as well as
> {{hl.simple.post}}
> i didn't try but i guess that's true for all sections and not specific to the
> highlighting. again, [~upayavira] might know where to look?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-8957) Query view generates incorrect param names
Stefan Matheis (steffkes) created SOLR-8957:
---
Summary: Query view generates incorrect param names
Key: SOLR-8957
URL: https://issues.apache.org/jira/browse/SOLR-8957
Project: Solr
Issue Type: Bug
Components: web gui
Affects Versions: 5.5, 5.4, master
Reporter: Stefan Matheis (steffkes)
Following SOLR-8956 we discovered that options within a section are leading to
incorrect param-names.
enabling {{hl}} and furthermore setting "something" for {{hl.fl}} (just below)
lead to a query containing {{hl=true=something}} obviously missing the
{{hl.}} prefix, same was true for {{hl.simple.pre}} as well as
{{hl.simple.post}}
i didn't try but i guess that's true for all sections and not specific to the
highlighting. again, [~upayavira] might know where to look?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8956) Highlight missing in Analysis View
[
https://issues.apache.org/jira/browse/SOLR-8956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Matheis (steffkes) updated SOLR-8956:
Attachment: Solr+Admin+2016-04-06+12-09-23.png
Solr+Admin+2016-04-06+12-03-36.png
> Highlight missing in Analysis View
> --
>
> Key: SOLR-8956
> URL: https://issues.apache.org/jira/browse/SOLR-8956
> Project: Solr
> Issue Type: Bug
> Components: Schema and Analysis, web gui
>Affects Versions: 5.4, 5.5, master
>Reporter: Stefan Matheis (steffkes)
> Attachments: Solr+Admin+2016-04-06+12-03-36.png,
> Solr+Admin+2016-04-06+12-09-23.png
>
>
> the new analysis view is missing the highlighting for matches. screenshots
> appended to show the difference.
> this was reported by user {{mloeb}} on #solr yesterday. initially he asked
> about highlighting in general - questioning a few things has gotten us to the
> analysis view for debugging purposes. not seeing any highlights given the
> index/query data - i've asked him to try the very same in the old admin ui
> where it worked.
> i haven't dived in the code yet, probably [~upayavira] can give a hint where
> / at what to look?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-8956) Highlight missing in Analysis View
Stefan Matheis (steffkes) created SOLR-8956:
---
Summary: Highlight missing in Analysis View
Key: SOLR-8956
URL: https://issues.apache.org/jira/browse/SOLR-8956
Project: Solr
Issue Type: Bug
Components: Schema and Analysis, web gui
Affects Versions: 5.5, 5.4, master
Reporter: Stefan Matheis (steffkes)
the new analysis view is missing the highlighting for matches. screenshots
appended to show the difference.
this was reported by user {{mloeb}} on #solr yesterday. initially he asked
about highlighting in general - questioning a few things has gotten us to the
analysis view for debugging purposes. not seeing any highlights given the
index/query data - i've asked him to try the very same in the old admin ui
where it worked.
i haven't dived in the code yet, probably [~upayavira] can give a hint where /
at what to look?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8210) Admin UI menu does not scroll
[
https://issues.apache.org/jira/browse/SOLR-8210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14973934#comment-14973934
]
Stefan Matheis (steffkes) commented on SOLR-8210:
-
[~upayavira] there is a function
[{{check_fixed_menu}}|http://svn.apache.org/viewvc/lucene/dev/trunk/solr/webapp/web/js/scripts/app.js?view=markup#l602]
that tries to handle that:
{code}check_fixed_menu = function check_fixed_menu()
{
$( '#wrapper' ).toggleClass(
'scroll',
$( window ).height() < $( '#menu-wrapper' ).height() + $( '#header'
).height() + 40
);
}{code}
The idea would be: check the height of the (browser)window and compare it to
the height of the menu (wrapper) to decide if the menu could be a sticky one
(that is what that kind of menu is typically called) or should scroll with the
remaining content because there is not enough space on the screen.
{{check_fixed_menu}} gets called once the application starts as well as on
{{window.resize}} to catch up if the user resizes the browser window, in which
case it might change either way (become sticky or not sticky anymore)
> Admin UI menu does not scroll
> -
>
> Key: SOLR-8210
> URL: https://issues.apache.org/jira/browse/SOLR-8210
> Project: Solr
> Issue Type: Improvement
> Components: web gui
>Affects Versions: 5.3
>Reporter: Upayavira
>Assignee: Upayavira
>Priority: Minor
>
> When you view the UI on a projector - or a small screen (e.g. with dev tools
> open), some menu options might be obscured at the bottom of the screen. The
> menu doesn't scroll though, meaning the only way to get to these entries is
> to use another screen, or change the text size in the browser temporarily.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8084) Original UI: Plugins/Stats "refresh values" link has problems in Chrome and Microsoft browsers
[
https://issues.apache.org/jira/browse/SOLR-8084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Matheis (steffkes) updated SOLR-8084:
Attachment: SOLR-8084.patch
using {{return false;}} disables the browser default handling of a link
(actually switching to the referenced url in {{href}} - therefore just
executing the {{window.location.reload}} which will stay on the current url.
and not switch (back) to the dashboard as described in the original report from
Lorenzo.
> Original UI: Plugins/Stats "refresh values" link has problems in Chrome and
> Microsoft browsers
> --
>
> Key: SOLR-8084
> URL: https://issues.apache.org/jira/browse/SOLR-8084
> Project: Solr
> Issue Type: Bug
> Components: UI, web gui
>Affects Versions: 5.3
>Reporter: Shawn Heisey
> Attachments: SOLR-8084.patch
>
>
> On the "Plugins/Stats" page, there is a "Refresh Values" link.
> A user on the mailing list was having problems with this link going to the
> dashboard.
> My testing on Windows 10 with 5.3.0 on the current UI showed Firefox working
> properly, but Chrome and Microsoft browsers have problems. Edge and Chrome
> return to the dashboard as the user noticed. IE11 throws up an error that
> says "404 Not Found get". When that popup is dismissed, the right pane of
> the window is empty except for a constant spinning icon saying "Loading ...".
> The Angular UI shows no problems in all four browsers. I did not test with
> any others.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7796) Implement a gather support info button
[
https://issues.apache.org/jira/browse/SOLR-7796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14628672#comment-14628672
]
Stefan Matheis (steffkes) commented on SOLR-7796:
-
I absolutely like the idea!
While [~elyograg], [~eribeiro] and i were throwing ideas around in #solr, the
following things came up - which i'm just including here for reference:
{code}15.2129 @ steffkes elyograg: +1 on SOLR-7796, gathering support
relevant information is a really nice idea!
15.2133 @ elyograg yep. It's somewhat painful to tailor each request for
info to the situation, and I hate to have people spend a lot of time gathering
info that might ultimately
turn out to be useless ... so instead of relying on
their skill level or taking up tons of their time, do it instantly.
15.2141 eribeiro elyograg: steffkes: if no one more knowledgeable
contributor picks up SOLR-7796 in a day or two, I am gonna try to take a stab
at it. ;-)
15.2147 @ steffkes eribeiro: nice! if you need help .. feel free to ping
me or Upayavira
15.2148 eribeiro okay, thanks. :)
15.2149 @ steffkes implementation might differ a bit, depending on where
you're going to include it - but the basic idea should be the same for both, i
guess
15.2150 @ steffkes eribeiro: true that. while reading i was thinking if
it might be possible to solve it in one shot .. but we're indeed talking about
a few things that might be
interesting here ..
15.2150 @ steffkes like the whole schema .. in case we stick to something
text based .. that might get a loong document
15.2150 eribeiro yeah...
15.2151 eribeiro +1 about the zip thing then
15.2151 @ steffkes which we have to do on the server, rather then the
client side .. :/
15.2151 @ steffkes otherwise i wouldn't bet that it's easy to implement.
generate a zip in everyones browser .. i don't know :D
15.2152 eribeiro haha, let's find out. :)
15.2152 @ steffkes on the other hand .. just thinking out load: if
pressing that button would open a modal layer .. which contains a bunch of
checkboxes .. where you could decide
*what* to actually prepare for export?
15.2153 @ steffkes i mean, even if someone is going to include his schema
.. it's not really a problem. it's just a few lines of text. we he/she is
already used to
15.2154 @ steffkes pastie.org has a nice feature where you can use ## at
the beginning of a line to indicate a section, like this one:
http://pastie.org/10295224
15.2154 eribeiro that would be awesome. something alike tools like
phpMySQLAdmin does when backing up and restoring the DB.
15.2154 @ steffkes not sure if apaste.info does support something like
that as well
15.2155 @ steffkes and .. to go really crazy .. we could probably try to
include the possibility to directly *post* this content to a paste-site. that
would be reeeaaallly nifty
15.2155 @ steffkes like .. hitting a button and getting back a url you
can share, which includes all the things you've previously checked :o
15.2156 eribeiro wow, indeed.
15.2156 @ steffkes but .. i don't want to set the bar to high :D
15.2157 @ steffkes just throwing ideas around while thinking about it
15.2158 eribeiro haha, got it. I will start small and see what I get. :)
15.2158 @ steffkes the last thing (posting directly) might require a
change for apaste.info but only easy things like additional headers, so that a
javascript client is allowed to go
crossdomain, which is normally forbidden by the
browsers security policy{code}
just to be sure that the last idea (POSTing it directly somewhere) isn't
entirely out of reach, i dropped by #asinfra's hipchat and talked with
[~humbedooh] about the idea:
{quote}10:01 Stefan Matheis we were just throwing ideas around in #solr over at
freenode. Shawn come up with an idea to include a gather support
information-button in the admin ui
10:02 Daniel Gruno (Humbedooh) ehm..
10:02 Stefan Matheis based on the my idea was we could probably include a
possibility to directly POST this information to apaste.info - which would
require a rather small change on apaste.info's configuration
10:02 Daniel Gruno (Humbedooh) ah
10:02 Stefan Matheis ;
10:02 Gavin McDonald (McDuck) @Humbedooh is yoiur man
10:02 Daniel Gruno (Humbedooh) well, we _could_ add a token account
10:02 Stefan Matheis like enabling CORS header
10:02 Daniel Gruno (Humbedooh) or err
10:02 Daniel Gruno (Humbedooh) with a token
10:02 Daniel Gruno (Humbedooh) role account
10:02 Daniel Gruno (Humbedooh) oh, sure, CORS should be easy enough
10:02 Daniel Gruno (Humbedooh) that's just a matter of editing the yaml for the
TLS terminator
10:02 Daniel Gruno (Humbedooh) in fact, it's actually all something you'd do on
that machine
10:02
[jira] [Commented] (SOLR-6614) SolrCloud graph viz truncates port designation
[
https://issues.apache.org/jira/browse/SOLR-6614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14212315#comment-14212315
]
Stefan Matheis (steffkes) commented on SOLR-6614:
-
as i've explained to [~ralph.tice] yesterday on the conference party, i don't
believe that it's an explicit problem with the port number .. to me it looks
more like the svg-drawing area just ends - and the content doesn't completely
fit.
{{-100}} might be a bit to much, since that really moves the area out of the
content-area (if looking at html-elements), Ralph for me, reducing the first
param to zero works fine as well, can you confirm that?
{code}- .attr( 'transform', 'translate(100, 0)' );
+ .attr( 'transform', 'translate(0, 0)' );{code}
the underlying problem is .. a tree in d3.js uses one top-node, which doesn't
work in our case .. so i'm faking here a bit by leaving that blank. looking at
the rendered source-code you can see classes like {{lvl-1}} which indicate the
invisible tree-nodes. they are taking up a bit space, which is why reducing the
position from 100 to 0 still leaves some white space on the left side. but
avoids that elements are actually overlapping - which might lead to problems
like i can see button xy, but i can't click on it which can happens in some
browsers in such a case.
SolrCloud graph viz truncates port designation
--
Key: SOLR-6614
URL: https://issues.apache.org/jira/browse/SOLR-6614
Project: Solr
Issue Type: Bug
Components: SolrCloud, web gui
Affects Versions: 4.10.1
Reporter: Ralph Tice
Priority: Minor
Attachments: SOLR-6614.patch
I believe this is a regression but I didn't see anything jump out at me from
the history on cloud.js. The port designation for shards is truncated. I am
pretty sure the port designation only appears if you have multiple JVMs on
the same hostname in your SolrCloud.
Here is a visual depiction of the problem:
http://monosnap.com/image/WzETqptfhcuDGKXjpJPR854lIzriyI
I have a very minor patch which addresses this as well as an issue with the
legend being overlaid on top of shard designations. It's pretty simple, but
I generally only have the use case of dozens or hundreds of shards so I'm not
sure how this looks in other situations.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6614) SolrCloud graph viz truncates port designation
[ https://issues.apache.org/jira/browse/SOLR-6614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-6614: Attachment: Screen Shot 2014-11-14 at 3.44.38 PM.png Screen Shot 2014-11-14 at 3.44.05 PM.png Screen Shot 2014-11-14 at 3.43.53 PM.png Screen Shot 2014-11-14 at 3.43.39 PM.png sometimes a picture can say more than a bunch of words .. at least for me, right now ; attached screenshots should give an explanation what is happening here. they are btw done in chrome, on the bottom you see the chrome developer tools - just in case you're wondering. SolrCloud graph viz truncates port designation -- Key: SOLR-6614 URL: https://issues.apache.org/jira/browse/SOLR-6614 Project: Solr Issue Type: Bug Components: SolrCloud, web gui Affects Versions: 4.10.1 Reporter: Ralph Tice Priority: Minor Attachments: SOLR-6614.patch, Screen Shot 2014-11-14 at 3.43.39 PM.png, Screen Shot 2014-11-14 at 3.43.53 PM.png, Screen Shot 2014-11-14 at 3.44.05 PM.png, Screen Shot 2014-11-14 at 3.44.38 PM.png I believe this is a regression but I didn't see anything jump out at me from the history on cloud.js. The port designation for shards is truncated. I am pretty sure the port designation only appears if you have multiple JVMs on the same hostname in your SolrCloud. Here is a visual depiction of the problem: http://monosnap.com/image/WzETqptfhcuDGKXjpJPR854lIzriyI I have a very minor patch which addresses this as well as an issue with the legend being overlaid on top of shard designations. It's pretty simple, but I generally only have the use case of dozens or hundreds of shards so I'm not sure how this looks in other situations. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-6738) Admin UI - Escape Data on Plugins-View
Stefan Matheis (steffkes) created SOLR-6738: --- Summary: Admin UI - Escape Data on Plugins-View Key: SOLR-6738 URL: https://issues.apache.org/jira/browse/SOLR-6738 Project: Solr Issue Type: Bug Components: web gui Reporter: Stefan Matheis (steffkes) Assignee: Stefan Matheis (steffkes) Fix For: 5.0, Trunk The Plugin-View needs to escape all data that is shown to the user, right now that is done only for a few appearances. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6738) Admin UI - Escape Data on Plugins-View
[ https://issues.apache.org/jira/browse/SOLR-6738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-6738: Attachment: SOLR-6738.patch Admin UI - Escape Data on Plugins-View -- Key: SOLR-6738 URL: https://issues.apache.org/jira/browse/SOLR-6738 Project: Solr Issue Type: Bug Components: web gui Reporter: Stefan Matheis (steffkes) Assignee: Stefan Matheis (steffkes) Fix For: 5.0, Trunk Attachments: SOLR-6738.patch The Plugin-View needs to escape all data that is shown to the user, right now that is done only for a few appearances. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-6739) Admin UI - Sort list of command line args
Stefan Matheis (steffkes) created SOLR-6739:
---
Summary: Admin UI - Sort list of command line args
Key: SOLR-6739
URL: https://issues.apache.org/jira/browse/SOLR-6739
Project: Solr
Issue Type: Improvement
Components: web gui
Reporter: Stefan Matheis (steffkes)
Assignee: Stefan Matheis (steffkes)
Priority: Minor
Fix For: 5.0, Trunk
since {{bin/solr}} is adding a bunch of command line args, it might be helpful
to see them in sorted order, right now they appear in random order - and that
order might not even be consistently random ;o
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6739) Admin UI - Sort list of command line args
[
https://issues.apache.org/jira/browse/SOLR-6739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Matheis (steffkes) updated SOLR-6739:
Attachment: SOLR-6739.patch
the attached patch {{sort}} and afterwards {{reverse}} the given list -
reversing the order is needed because the behavior of the current code is to
append items (by iterating over them) after the previous element .. which
implicitly reverses order, while doing so.
Admin UI - Sort list of command line args
-
Key: SOLR-6739
URL: https://issues.apache.org/jira/browse/SOLR-6739
Project: Solr
Issue Type: Improvement
Components: web gui
Reporter: Stefan Matheis (steffkes)
Assignee: Stefan Matheis (steffkes)
Priority: Minor
Fix For: 5.0, Trunk
Attachments: SOLR-6739.patch
since {{bin/solr}} is adding a bunch of command line args, it might be
helpful to see them in sorted order, right now they appear in random order -
and that order might not even be consistently random ;o
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-6740) Admin UI - improve Files View
Stefan Matheis (steffkes) created SOLR-6740: --- Summary: Admin UI - improve Files View Key: SOLR-6740 URL: https://issues.apache.org/jira/browse/SOLR-6740 Project: Solr Issue Type: Improvement Components: web gui Reporter: Stefan Matheis (steffkes) Assignee: Stefan Matheis (steffkes) Priority: Minor Fix For: 5.0, Trunk JSON- CSS-Files are missing syntax-highlighting, the left column (containing file names) is rather small and longer filenames overlay the content-area. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6740) Admin UI - improve Files View
[ https://issues.apache.org/jira/browse/SOLR-6740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-6740: Attachment: SOLR-6740.patch Admin UI - improve Files View - Key: SOLR-6740 URL: https://issues.apache.org/jira/browse/SOLR-6740 Project: Solr Issue Type: Improvement Components: web gui Reporter: Stefan Matheis (steffkes) Assignee: Stefan Matheis (steffkes) Priority: Minor Fix For: 5.0, Trunk Attachments: SOLR-6740.patch JSON- CSS-Files are missing syntax-highlighting, the left column (containing file names) is rather small and longer filenames overlay the content-area. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-6739) Admin UI - Sort list of command line args
[
https://issues.apache.org/jira/browse/SOLR-6739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Matheis (steffkes) resolved SOLR-6739.
-
Resolution: Implemented
Admin UI - Sort list of command line args
-
Key: SOLR-6739
URL: https://issues.apache.org/jira/browse/SOLR-6739
Project: Solr
Issue Type: Improvement
Components: web gui
Reporter: Stefan Matheis (steffkes)
Assignee: Stefan Matheis (steffkes)
Priority: Minor
Fix For: 5.0, Trunk
Attachments: SOLR-6739.patch
since {{bin/solr}} is adding a bunch of command line args, it might be
helpful to see them in sorted order, right now they appear in random order -
and that order might not even be consistently random ;o
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-6740) Admin UI - improve Files View
[ https://issues.apache.org/jira/browse/SOLR-6740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) resolved SOLR-6740. - Resolution: Implemented Admin UI - improve Files View - Key: SOLR-6740 URL: https://issues.apache.org/jira/browse/SOLR-6740 Project: Solr Issue Type: Improvement Components: web gui Reporter: Stefan Matheis (steffkes) Assignee: Stefan Matheis (steffkes) Priority: Minor Fix For: 5.0, Trunk Attachments: SOLR-6740.patch JSON- CSS-Files are missing syntax-highlighting, the left column (containing file names) is rather small and longer filenames overlay the content-area. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5377) the Core Selector in the Admin UI should pre-select a core
[ https://issues.apache.org/jira/browse/SOLR-5377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-5377: Component/s: web gui the Core Selector in the Admin UI should pre-select a core Key: SOLR-5377 URL: https://issues.apache.org/jira/browse/SOLR-5377 Project: Solr Issue Type: Improvement Components: web gui Reporter: Michael McCandless Priority: Minor I was trying to use the admin UI, to understand how text was analyzed, but it was confusing (I couldn't find the Analysis page) until I realized I had to use the Core Selector to select my core. I had only one core ... it seems like the Core Selector could easily just pre-select a core (the one in my case...). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6622) Issue with Multivalued fields when using UIMA
[ https://issues.apache.org/jira/browse/SOLR-6622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14171113#comment-14171113 ] Stefan Matheis (steffkes) commented on SOLR-6622: - Great :) There is a little how-to in case you need more information: http://wiki.apache.org/solr/HowToContribute Issue with Multivalued fields when using UIMA - Key: SOLR-6622 URL: https://issues.apache.org/jira/browse/SOLR-6622 Project: Solr Issue Type: Bug Components: contrib - UIMA Affects Versions: Trunk Reporter: Maryam Khordad When using any of UIMA addons on a multivalued fields, only the first row of the field gets processed and UIMA update ignores the remaining rows. This bug caused by getTextsToAnalyze method in UIMAUpdateRequestProcessor class. SolrInputDocument .getFieldValue must be changes to olrInputDocument .getFieldValues and the result must be an array not a single variable. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-6611) Auto Refresh Solr
[ https://issues.apache.org/jira/browse/SOLR-6611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) resolved SOLR-6611. - Resolution: Not a Problem Assignee: Stefan Matheis (steffkes) Auto Refresh Solr - Key: SOLR-6611 URL: https://issues.apache.org/jira/browse/SOLR-6611 Project: Solr Issue Type: Bug Components: clients - php Affects Versions: 4.10.1 Reporter: pardeep Assignee: Stefan Matheis (steffkes) Hi, I am new in solr. I have integrated solr and I want to know how can I solr indexing auto refresh when I add new row in database or update record. Please help me. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6152) Pre-populating values into search parameters on the query page of solr admin
[
https://issues.apache.org/jira/browse/SOLR-6152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14150142#comment-14150142
]
Stefan Matheis (steffkes) commented on SOLR-6152:
-
I've heard someone saying me name? ;) I'll do the best i can Dmitry - let me
start with this one:
Currently there is no place that uses a pre-configuration stored in solrconfig
(or somewhere stored in the server, at all) - everything we have it either
persisted in a cookie (auto-refresh at dataimport, timezone at logging and
autoloading-terms at the schema-browser) or in the url (analysis-view,
files-browser or plugins).
Initially we thought about that at some features that were implemented in the
early days - but every feature that would use a persisted state, was based on
some kind of user-preference rather than something that would be valid globally
(auto-refresh at dataimport, as an example). That doesn't mean that i would be
against having something like that (absolutely not!) - only explaining how we
got where we are currently ;
Regarding this issue: Jakob brought up something pretty similar in SOLR-6404 -
where i've already described the place where i'd start digging:
{code:title=http://svn.apache.org/viewvc/lucene/dev/trunk/solr/webapp/web/js/scripts/query.js?view=markup#l209}for(
var key in context.params )
{
if( 'string' === typeof context.params[key] )
{
fields++;
$( '[name=' + key + ']', query_form )
.val( context.params[key] );
}
}{code}
that's pretty basic, but does explain why neither his use-case nor yours work
right now out of the box. you can provide default-values for a bunch of fields
(f.e. the query-field using {{http://host/solr/#/collection1/query?q=test}}) -
that does not work for all fields and especially isn't updated after you change
any input-values. that is something that already works on the analysis screen -
where we could grab a bunch of things (:
Right off the bat, i'd go with the following steps:
* extend the string/input-field limitation, so that it would work with a
checkbox/radiobox as well
* check the analysis view and [how it updates the
url|http://svn.apache.org/viewvc/lucene/dev/trunk/solr/webapp/web/js/scripts/analysis.js?view=markup#l242]
(kinda hacky, explantation below)
* figure out how to handle multi-valued fields (like the Filter-Query)
I know, i'm mentioning your use-case only third (and therefore last) .. for a
comparable simple reason: it's the most complicated one - i didn't look at it
closely, just from what i'd imagine how it could be. obviously that is just a
suggestion and if you feel like starting with that one .. i'm all yours!
Analysis-View: i said 'kinda hacky' because it does something weird, if you
submit the form, it builds the new url - based on all form values - redirects
you there and then executes the actual analysis. sounds strange .. is in fact
strange, but i couldn't figure out another way. because every time you modify
the url (either manually or via javascript) the framework we use
([sammy.js|http://sammyjs.org]) starts it's route matching and all - which
doesn't play well w/ what i've wanted to do there. probably it would be worth a
second look, the longer i'm thinking about this, the more i have the feeling
that i've simply overlooked something, because something like that should exist
- at least, in a more current version.
Pre-populating values into search parameters on the query page of solr admin
Key: SOLR-6152
URL: https://issues.apache.org/jira/browse/SOLR-6152
Project: Solr
Issue Type: Improvement
Components: web gui
Affects Versions: 4.3.1
Reporter: Dmitry Kan
Attachments: prepoluate_query_parameters_query_page.bmp
In some use cases, it is highly desirable to be able to pre-populate the
query page of solr admin with specific values.
In particular use case of mine, the solr admin user must pass a date range
value without which the query would fail.
It isn't easy to remember the value format for non-solr experts, so I would
like to have a way of hooking that value example into the query page.
See the screenshot attached, where I have inserted the fq parameter with date
range into the Raw Query Parameters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-6404) Solr WebGui does not correctly prefill query parameters
[ https://issues.apache.org/jira/browse/SOLR-6404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) resolved SOLR-6404. - Resolution: Duplicate Assignee: Stefan Matheis (steffkes) Solr WebGui does not correctly prefill query parameters --- Key: SOLR-6404 URL: https://issues.apache.org/jira/browse/SOLR-6404 Project: Solr Issue Type: Improvement Components: web gui Affects Versions: 4.9 Reporter: Jakob Furrer Assignee: Stefan Matheis (steffkes) Priority: Minor In my custom application that sends requests to Solr, I log the Solr query requests for debugging purposes. To do so, I append the original query parameters from my SolrJ select request (see org.apache.solr.client.solrj.SolrQuery) to my Solr WebGui URL like this: String debuggingUrl = http://my-machine-name:8080/Solr/#/MyCore/query?; + String.valueOf(solrQuery) + debugQuery=on; When the debuggingUrl is later opened in a web browser, the query parameters are conveniently prefilled in the textfields of the form and the query can be sent and analyzed. Great features. Saved me a lot of time when I was finetuning my queries. Unfortunately, not all parameters that occur in my debuggingUrl are taken over in the web form correctly. Not knowing the full range of possible parameters, I have not performed an exhaustive test, but I can confirm that the following currently fail: [a] defType=edismax There is a check box named edismax in the form, but the box is not pre-checked, while it actually should be. [b] debugQuery=on There is a check box named debugQuery in the form, but the box is not pre-checked, while it actually should be. [c] q.op=AND There is no text field or check box or dropdown item named q.op. Not even after checking on dismax and edismax which both offer additional parameters to be set. However, there should be input option to set this parameter and it should be preset when q.op=AND is defined in the URL. The parameters listed as [a], [b] and [c] are important to my use case, that's why I noticed that they are not correctly handled. However, there might be others that are missing or incorrectly handled. The issue described above can be reproduced using the following URL on a standard example Solr instance on Jetty. http://localhost:8983/solr/#/collection1/query?q=Maxtor%20Samsungfl=id,name,featureswt=jsonindent=truedefType=edismaxq.op=ANDdebugQuery=on -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-5557) Replicatable version from master not shown in slave admin panels
[ https://issues.apache.org/jira/browse/SOLR-5557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) resolved SOLR-5557. - Resolution: Cannot Reproduce Assignee: Stefan Matheis (steffkes) I'm closing this one now, since it seems to work. if it doesn't .. please reopen and add a explaining comment. Replicatable version from master not shown in slave admin panels Key: SOLR-5557 URL: https://issues.apache.org/jira/browse/SOLR-5557 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.6 Reporter: Fred Drake Assignee: Stefan Matheis (steffkes) Priority: Minor The Overview and Replication panels for a slave core include three fields to show what version of the index is used: Master (Searching) Master (Replicable) Slave (Searching) The Master (Replicable) field is left blank. steffkes on IRC suggests that there is a typo somewhere; that the relevant fields are referenced inconsistently as replicatableGeneration and replicableGeneration. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-5419) Solr Admin UI Query Result Does Nothing at Error
[ https://issues.apache.org/jira/browse/SOLR-5419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) resolved SOLR-5419. - Resolution: Not a Problem Assignee: Stefan Matheis (steffkes) I'm closing this issue due no activity/response - in case there is additional information please reopen and add a comment about it. Solr Admin UI Query Result Does Nothing at Error Key: SOLR-5419 URL: https://issues.apache.org/jira/browse/SOLR-5419 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.5.1, 4.6, 4.6.1, 4.7 Reporter: Furkan KAMACI Assignee: Stefan Matheis (steffkes) Priority: Minor Fix For: Trunk, 4.9 Attachments: SOLR-5419.patch, Screen Shot 2014-03-12 at 2.53.50 PM.png When you make a query into Solr via Solr Admin Page and if an error occurs there writes Loading.. and nothing happens. i.e. if you write an invalid Request Handler (something like /select instead of /select) at Query page and even response is 404 Not Found you will see that Loading... is still there and you will not able to understand whether an error occurred or the response is so slow at first glance. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-5236) Arguments with spaces show as broken lines in Solr Admin
[ https://issues.apache.org/jira/browse/SOLR-5236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) resolved SOLR-5236. - Resolution: Cannot Reproduce Assignee: Stefan Matheis (steffkes) i did check it with a current release on mac os (chromium firefox) and it didn't happen - i'm closing this, if it does happen again for someone, please reopen and extend with additional information. Arguments with spaces show as broken lines in Solr Admin - Key: SOLR-5236 URL: https://issues.apache.org/jira/browse/SOLR-5236 Project: Solr Issue Type: Bug Components: web gui Environment: Mac OS X 10.8.4, Solr 4.x branch build #401 Reporter: Cassandra Targett Assignee: Stefan Matheis (steffkes) Priority: Minor Attachments: SOLR-5236.linux.narrowscreen.png, SOLR-5236.linux.widescreen.png, Solr4.x-startArgsWithSpaces.png A screenshot will explain it best, but if you pass arguments at startup with spaces in them, the Solr Admin dashboard shows the arguments as broken lines. This is the command I used to start Solr: java -Dsdfasdf=asdfsdfasdfasd\ asdfsdfasdf\ sdfasdfasdfasdf\ asdfasdfasdf -Dfile.encoding=UTF-8 -jar start.jar -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6395) If the overseer queue is large, then the cloud tree view (admin UI) hangs
[ https://issues.apache.org/jira/browse/SOLR-6395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14150272#comment-14150272 ] Stefan Matheis (steffkes) commented on SOLR-6395: - Tim, i had to check the requests we make on the tree view .. there is currently only one that loads the whole tree information, additional requests happen in case that the user looks at a entries detail. If there is a possibility that we can request only one (the specified) level for the tree .. we could use that to lazy-load nested information, if that helps improving the performance for larger instances? If the overseer queue is large, then the cloud tree view (admin UI) hangs - Key: SOLR-6395 URL: https://issues.apache.org/jira/browse/SOLR-6395 Project: Solr Issue Type: Bug Components: SolrCloud, web gui Reporter: Timothy Potter Assignee: Timothy Potter Of course, an overseer queue that is backed up is a symptom of bigger issues, but if it is, the tree view in the cloud panel becomes almost un-usable, presumably because the UI is trying to pull all the overseer queue child nodes? Be better to lazily load child nodes when the parent znode tree element is opened. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5074) Missing Forward Slash in data-config.xml Makes Entities Disappear
[ https://issues.apache.org/jira/browse/SOLR-5074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14150278#comment-14150278 ] Stefan Matheis (steffkes) commented on SOLR-5074: - Sorry [~thinkcomp], i did miss that issue. i would expect the empty entities-dropdown not being the only problem in that case? the whole configuration would be invalid if you don't place a self-closing xml-tag in that case? can you remember how it did behave in your case? obviously we can try it with a current release and see what happens then - just curious since, like i've mention above, i can't imagine that being the only thing that didn't work? Missing Forward Slash in data-config.xml Makes Entities Disappear - Key: SOLR-5074 URL: https://issues.apache.org/jira/browse/SOLR-5074 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.3 Environment: Linux Reporter: Aaron Greenspan Priority: Minor I mistakenly created an entity that had the following fields: field column=id name=id / field column=description name=blah In the second field, I forgot the trailing forward slash to end the tag. There were no warnings or errors in the log, but the list of entities for the core was blank. It took me a while to figure out that this was probably why. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4917) Logging UI Javascript errors
[ https://issues.apache.org/jira/browse/SOLR-4917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14150284#comment-14150284 ] Stefan Matheis (steffkes) commented on SOLR-4917: - [~thrykol] i'm a little bit to the party .. the patch would apply w/o changes, would you mind verifying that it still behaves as expected? especially with the changes we had regarding the logging setup Logging UI Javascript errors Key: SOLR-4917 URL: https://issues.apache.org/jira/browse/SOLR-4917 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.3 Reporter: Shane Labels: patch Fix For: 4.3 Original Estimate: 1h Remaining Estimate: 1h When logging has not been configured, the logging/level UI throw some JavaScript errors. I submitted a PR via GitHub. The GitHub patch can be found at https://github.com/apache/lucene-solr/pull/10.patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4861) Simple reflected cross site scripting vulnerability
[
https://issues.apache.org/jira/browse/SOLR-4861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14150312#comment-14150312
]
Stefan Matheis (steffkes) commented on SOLR-4861:
-
[~omgclouds] the reference to L465 doesn't apply anymore, looking for the right
spot in current code .. i'd guess it's this one? right now the only place where
something is written to the response:
{code:title=http://svn.apache.org/viewvc/lucene/dev/trunk/solr/core/src/java/org/apache/solr/client/solrj/embedded/JettySolrRunner.java?view=markup#l523}
public static class Servlet404 extends HttpServlet {
@Override
public void service(HttpServletRequest req, HttpServletResponse res)
throws IOException {
res.sendError(404, Can not find: + req.getRequestURI());
}
}
{code}
Simple reflected cross site scripting vulnerability
---
Key: SOLR-4861
URL: https://issues.apache.org/jira/browse/SOLR-4861
Project: Solr
Issue Type: Bug
Components: web gui
Affects Versions: 4.2, 4.3
Environment: Requires web ui / Jetty Solr to be exploited.
Reporter: John Menerick
Labels: security
There exists a simple XSS via the 404 Jetty / Solr code. Within
JettySolrRunner.java, line 465, if someone asks for a non-existent page / url
which contains malicious code, the Can not find can be escaped and
malicious code will be executed on the victim's browser.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4316) Admin UI - SolrCloud - extend core options to collections
[
https://issues.apache.org/jira/browse/SOLR-4316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14112122#comment-14112122
]
Stefan Matheis (steffkes) commented on SOLR-4316:
-
bq. 1. Imagine collection1 which is both a collection as well as a core name.
Once the user has already selected one of them there is no way to indicate what
has been selected (except the fact that different options show depending on
what's selected)
That's right, we already have the problem, that there is no place on the screen
where you can see the complete core-/collection-name (in case it gets truncated
because it's to long for the dropdown ..)
One idea a coworker had: Add another line (mentioning 'core' or 'collection',
depending on the choice) on top of the current label. we would have to extend
the library we use (chosen) to make that happen, because right now it is
prepared to show one line (which is by default the label of the selected option
from the dropdown).
in case the name is something thoughtfully selected (like collection1 ;) that
would look a little bit odd, since it would say
{quote}collection
collection1{quote}
but i guess, that would be acceptable?
Admin UI - SolrCloud - extend core options to collections
-
Key: SOLR-4316
URL: https://issues.apache.org/jira/browse/SOLR-4316
Project: Solr
Issue Type: Improvement
Components: web gui
Affects Versions: 4.1
Reporter: Shawn Heisey
Assignee: Shalin Shekhar Mangar
Fix For: 4.9, 5.0
Attachments: SOLR-4316.patch, solrcloud-admin-ui-menu.png
There are a number of sections available when you are looking at a core in
the UI - Ping, Query, Schema, Config, Replication, Analysis, Schema Browser,
Plugins / Stats, and Dataimport are the ones that I can see.
A list of collections should be available, with as many of those options that
can apply to a collection, If options specific to collections/SolrCloud can
be implemented, those should be there too.
--
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-6404) Solr WebGui does not correctly prefill query parameters
[
https://issues.apache.org/jira/browse/SOLR-6404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14106800#comment-14106800
]
Stefan Matheis (steffkes) commented on SOLR-6404:
-
Jakob that's correct, the current functionality is pretty simple and works only
for textfields (not checkboxes, which would be what {{defType}}
{{debugQuery}} are using) and in case that a field with the very same name
exists (which isn't true for {{q.op}}).
that's the relevant part of the code:
{code:title=http://svn.apache.org/viewvc/lucene/dev/trunk/solr/webapp/web/js/scripts/query.js?view=markup#l209}for(
var key in context.params )
{
if( 'string' === typeof context.params[key] )
{
fields++;
$( '[name=' + key + ']', query_form )
.val( context.params[key] );
}
}{code}
a possible extension would be, to check if the field is a checkbox (rather than
a textfield) and enable/disable it based on the given value. all fields that
don't have an matching field could be combined into the Raw Query Parameters
which is currently the only possibility to send various data from the Query UI
Solr WebGui does not correctly prefill query parameters
---
Key: SOLR-6404
URL: https://issues.apache.org/jira/browse/SOLR-6404
Project: Solr
Issue Type: Improvement
Components: web gui
Affects Versions: 4.9
Reporter: Jakob Furrer
Priority: Minor
In my custom application that sends requests to Solr, I log the Solr query
requests for debugging purposes.
To do so, I append the original query parameters from my SolrJ select request
(see org.apache.solr.client.solrj.SolrQuery) to my Solr WebGui URL like this:
String debuggingUrl = http://my-machine-name:8080/Solr/#/MyCore/query?; +
String.valueOf(solrQuery) + debugQuery=on;
When the debuggingUrl is later opened in a web browser, the query parameters
are conveniently prefilled in the textfields of the form and the query can be
sent and analyzed.
Great features. Saved me a lot of time when I was finetuning my queries.
Unfortunately, not all parameters that occur in my debuggingUrl are taken
over in the web form correctly.
Not knowing the full range of possible parameters, I have not performed an
exhaustive test, but I can confirm that the following currently fail:
[a]
defType=edismax
There is a check box named edismax in the form, but the box is not
pre-checked, while it actually should be.
[b]
debugQuery=on
There is a check box named debugQuery in the form, but the box is not
pre-checked, while it actually should be.
[c]
q.op=AND
There is no text field or check box or dropdown item named q.op.
Not even after checking on dismax and edismax which both offer additional
parameters to be set.
However, there should be input option to set this parameter and it should be
preset when q.op=AND is defined in the URL.
The parameters listed as [a], [b] and [c] are important to my use case,
that's why I noticed that they are not correctly handled.
However, there might be others that are missing or incorrectly handled.
The issue described above can be reproduced using the following URL on a
standard example Solr instance on Jetty.
http://localhost:8983/solr/#/collection1/query?q=Maxtor%20Samsungfl=id,name,featureswt=jsonindent=truedefType=edismaxq.op=ANDdebugQuery=on
--
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-6404) Solr WebGui does not correctly prefill query parameters
[
https://issues.apache.org/jira/browse/SOLR-6404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14106800#comment-14106800
]
Stefan Matheis (steffkes) edited comment on SOLR-6404 at 8/22/14 12:54 PM:
---
Jakob that's correct, the current functionality is pretty simple and works only
for textfields (not checkboxes, which would be what {{defType}}
{{debugQuery}} are using) and in case that a field with the very same name
exists (which isn't true for {{q.op}}).
that's the relevant part of the code:
{code:title=http://svn.apache.org/viewvc/lucene/dev/trunk/solr/webapp/web/js/scripts/query.js?view=markup#l209}for(
var key in context.params )
{
if( 'string' === typeof context.params[key] )
{
fields++;
$( '[name=' + key + ']', query_form )
.val( context.params[key] );
}
}{code}
a possible extension would be, to check if the field is a checkbox (rather than
a textfield) and enable/disable it based on the given value. all fields that
don't have an matching field could be combined into the Raw Query Parameters
which is currently the only possibility to send various data from the Query UI
so, to know for which fields that currently works .. have a look at
http://svn.apache.org/viewvc/lucene/dev/trunk/solr/webapp/web/tpl/query.html?view=markup
and search for {{name=}}
was (Author: steffkes):
Jakob that's correct, the current functionality is pretty simple and works only
for textfields (not checkboxes, which would be what {{defType}}
{{debugQuery}} are using) and in case that a field with the very same name
exists (which isn't true for {{q.op}}).
that's the relevant part of the code:
{code:title=http://svn.apache.org/viewvc/lucene/dev/trunk/solr/webapp/web/js/scripts/query.js?view=markup#l209}for(
var key in context.params )
{
if( 'string' === typeof context.params[key] )
{
fields++;
$( '[name=' + key + ']', query_form )
.val( context.params[key] );
}
}{code}
a possible extension would be, to check if the field is a checkbox (rather than
a textfield) and enable/disable it based on the given value. all fields that
don't have an matching field could be combined into the Raw Query Parameters
which is currently the only possibility to send various data from the Query UI
Solr WebGui does not correctly prefill query parameters
---
Key: SOLR-6404
URL: https://issues.apache.org/jira/browse/SOLR-6404
Project: Solr
Issue Type: Improvement
Components: web gui
Affects Versions: 4.9
Reporter: Jakob Furrer
Priority: Minor
In my custom application that sends requests to Solr, I log the Solr query
requests for debugging purposes.
To do so, I append the original query parameters from my SolrJ select request
(see org.apache.solr.client.solrj.SolrQuery) to my Solr WebGui URL like this:
String debuggingUrl = http://my-machine-name:8080/Solr/#/MyCore/query?; +
String.valueOf(solrQuery) + debugQuery=on;
When the debuggingUrl is later opened in a web browser, the query parameters
are conveniently prefilled in the textfields of the form and the query can be
sent and analyzed.
Great features. Saved me a lot of time when I was finetuning my queries.
Unfortunately, not all parameters that occur in my debuggingUrl are taken
over in the web form correctly.
Not knowing the full range of possible parameters, I have not performed an
exhaustive test, but I can confirm that the following currently fail:
[a]
defType=edismax
There is a check box named edismax in the form, but the box is not
pre-checked, while it actually should be.
[b]
debugQuery=on
There is a check box named debugQuery in the form, but the box is not
pre-checked, while it actually should be.
[c]
q.op=AND
There is no text field or check box or dropdown item named q.op.
Not even after checking on dismax and edismax which both offer additional
parameters to be set.
However, there should be input option to set this parameter and it should be
preset when q.op=AND is defined in the URL.
The parameters listed as [a], [b] and [c] are important to my use case,
that's why I noticed that they are not correctly handled.
However, there might be others that are missing or incorrectly handled.
The issue described above can be reproduced using the following URL on a
standard example Solr instance on Jetty.
http://localhost:8983/solr/#/collection1/query?q=Maxtor%20Samsungfl=id,name,featureswt=jsonindent=truedefType=edismaxq.op=ANDdebugQuery=on
--
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-6199) SolrJ, using SolrInputDocument methods, requires entire document to be loaded into memory
[ https://issues.apache.org/jira/browse/SOLR-6199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14043248#comment-14043248 ] Stefan Matheis (steffkes) commented on SOLR-6199: - [~kwri...@metacarta.com] FYI, you can link issues on JIRA over different projects SolrJ, using SolrInputDocument methods, requires entire document to be loaded into memory - Key: SOLR-6199 URL: https://issues.apache.org/jira/browse/SOLR-6199 Project: Solr Issue Type: Bug Affects Versions: 4.7.3 Reporter: Karl Wright ManifoldCF has historically used Solr's extracting update handler for transmitting binary documents to Solr. Recently, we've included Tika processing of binary documents, and wanted instead to send an (unlimited by ManifoldCF) character stream as a primary content field to Solr instead. Unfortunately, it appears that the SolrInputDocument metaphor for receiving extracted content and metadata requires that all fields be completely converted to String objects. This will cause ManifoldCF to certainly run out of memory at some point, when multiple ManifoldCF threads all try to convert large documents to in-memory strings at the same time. I looked into what would be needed to add streaming support to UpdateRequest and SolrInputDocument. Basically, a legal option would be to set a field value that would be a Reader or a Reader[]. It would be straightforward to implement this, EXCEPT for the fact that SolrCloud apparently makes UpdateRequest copies, and copying a Reader isn't going to work unless there's a backing solid object somewhere. Even then, I could have gotten this to work by using a temporary file for large streams, but there's no signal from SolrCloud when it is done with its copies of UpdateRequest, so there's no place to free any backing storage. If anyone knows a good way to do non-extracting updates without loading entire documents into memory, please let me know. -- 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-6149) Analysis browser not working in solr 4.8.1
[ https://issues.apache.org/jira/browse/SOLR-6149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-6149: Fix Version/s: (was: 4.7.1) 5.0 4.9 Reference to the [post on the mailing-list|https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201406.mbox/%3CCAJ9V1mbgQa9Vh%2Byu%3DdnB1hPjeJT2ESsgXMUHJHV6q0Xr0yW-Bw%40mail.gmail.com%3E] Analysis browser not working in solr 4.8.1 -- Key: SOLR-6149 URL: https://issues.apache.org/jira/browse/SOLR-6149 Project: Solr Issue Type: Bug Components: Schema and Analysis Affects Versions: 4.8.1 Environment: Centos 5.9, java 7 update 60 Reporter: Aman Tandon Priority: Minor Fix For: 4.9, 5.0 I created a custom filter for my field named text_reversed, i tried my custom filter in solr 4.7.1 and i was able to analyse the result, it works fine but in solr 4.8.1 it gaves me error of : Missing required parameter: analysis.fieldvalue. It is also not working with any field, here is the logs of the error Here is the link of the screenshot http://picpaste.com/HrW26A8d.png -- 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-6147) QUERYHANDLER in Solr's admin GUI should be REQUESTHANDLER
[
https://issues.apache.org/jira/browse/SOLR-6147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14019726#comment-14019726
]
Stefan Matheis (steffkes) commented on SOLR-6147:
-
The UI doesn't name things (at least not in this case) .. we just take what the
mbeans-handler contains. afaik as i understand how things are going, this is
coming from the {{Category}} enum in {{org.apache.solr.core.SolrInfoMBean}}
If we change that, the UI will reflect the changes instantly.
QUERYHANDLER in Solr's admin GUI should be REQUESTHANDLER
-
Key: SOLR-6147
URL: https://issues.apache.org/jira/browse/SOLR-6147
Project: Solr
Issue Type: Improvement
Components: web gui
Reporter: David Smiley
Priority: Minor
In the admin UI, go to Plugins / Stats where you'll see a QUERYHANDLER
section. That should be called REQUESTHANDLER, and likewise the URL to it
should match.
--
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-6098) SOLR console displaying JSON does not escape text properly
[ https://issues.apache.org/jira/browse/SOLR-6098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-6098: Affects Version/s: 4.4 SOLR console displaying JSON does not escape text properly -- Key: SOLR-6098 URL: https://issues.apache.org/jira/browse/SOLR-6098 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.4 Reporter: Kingston Duffie Priority: Minor Fix For: 4.5 In the SOLR admin web console, when displaying JSON response for Query, the text is not being HTML escaped, so any text that happens to match HTML markup is being processed as HTML. For example, enter strikehello/strike in the q textbox and the responseHeader will contain: q: body:hello where the hello portion is shown using strikeout. This seems benign, but can be extremely confusing when viewing results, because if your fields happen to contain, for example, f...@bar.com, this will be completely missing (because the browser treats this as an invalid tag). -- 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] [Resolved] (SOLR-6098) SOLR console displaying JSON does not escape text properly
[ https://issues.apache.org/jira/browse/SOLR-6098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) resolved SOLR-6098. - Resolution: Duplicate Fix Version/s: 4.5 Assignee: Stefan Matheis (steffkes) SOLR console displaying JSON does not escape text properly -- Key: SOLR-6098 URL: https://issues.apache.org/jira/browse/SOLR-6098 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.4 Reporter: Kingston Duffie Assignee: Stefan Matheis (steffkes) Priority: Minor Fix For: 4.5 In the SOLR admin web console, when displaying JSON response for Query, the text is not being HTML escaped, so any text that happens to match HTML markup is being processed as HTML. For example, enter strikehello/strike in the q textbox and the responseHeader will contain: q: body:hello where the hello portion is shown using strikeout. This seems benign, but can be extremely confusing when viewing results, because if your fields happen to contain, for example, f...@bar.com, this will be completely missing (because the browser treats this as an invalid tag). -- 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-6098) SOLR console displaying JSON does not escape text properly
[ https://issues.apache.org/jira/browse/SOLR-6098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14003837#comment-14003837 ] Stefan Matheis (steffkes) commented on SOLR-6098: - You're not telling, which release you're referring to? from your description, that sounds a bit like SOLR-5174 which got fixed with 4.5. please let me know if that's your issue as well - in which case upgrading would already fix it and i'm going to close this as duplicate or it's something else and needs to be taken care of SOLR console displaying JSON does not escape text properly -- Key: SOLR-6098 URL: https://issues.apache.org/jira/browse/SOLR-6098 Project: Solr Issue Type: Bug Components: web gui Reporter: Kingston Duffie Priority: Minor In the SOLR admin web console, when displaying JSON response for Query, the text is not being HTML escaped, so any text that happens to match HTML markup is being processed as HTML. For example, enter strikehello/strike in the q textbox and the responseHeader will contain: q: body:hello where the hello portion is shown using strikeout. This seems benign, but can be extremely confusing when viewing results, because if your fields happen to contain, for example, f...@bar.com, this will be completely missing (because the browser treats this as an invalid tag). -- 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-6098) SOLR console displaying JSON does not escape text properly
[ https://issues.apache.org/jira/browse/SOLR-6098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-6098: Component/s: web gui SOLR console displaying JSON does not escape text properly -- Key: SOLR-6098 URL: https://issues.apache.org/jira/browse/SOLR-6098 Project: Solr Issue Type: Bug Components: web gui Reporter: Kingston Duffie Priority: Minor In the SOLR admin web console, when displaying JSON response for Query, the text is not being HTML escaped, so any text that happens to match HTML markup is being processed as HTML. For example, enter strikehello/strike in the q textbox and the responseHeader will contain: q: body:hello where the hello portion is shown using strikeout. This seems benign, but can be extremely confusing when viewing results, because if your fields happen to contain, for example, f...@bar.com, this will be completely missing (because the browser treats this as an invalid tag). -- 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-6097) Posting JSON with results in lost information
[
https://issues.apache.org/jira/browse/SOLR-6097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14003845#comment-14003845
]
Stefan Matheis (steffkes) commented on SOLR-6097:
-
you didn't link those issues .. but since i saw SOLR-6098 after that one and
already commented on that .. i guess they are related?
Posting JSON with results in lost information
-
Key: SOLR-6097
URL: https://issues.apache.org/jira/browse/SOLR-6097
Project: Solr
Issue Type: Bug
Affects Versions: 4.7.2
Reporter: Kingston Duffie
Post the following JSON to add a document:
{
add :
{
commitWithin : 5000,
doc :
{
id : 12345,
body : a b c
}
}
}
The body field is configured in the schema as:
field name=body type=text_hive indexed=true stored=true
required=false multiValued=false/
and
fieldType name=text_hive class=solr.TextField
positionIncrementGap=100
analyzer type=index
tokenizer class=solr.WhitespaceTokenizerFactory/
filter class=solr.WordDelimiterFilterFactory
generateWordParts=1 generateNumberParts=1 catenateWords=1
catenateNumbers=1 catenateAll=1 splitOnCaseChange=1
preserveOriginal=1/
filter class=solr.LowerCaseFilterFactory/
filter class=solr.EdgeNGramFilterFactory minGramSize=1
maxGramSize=15 side=front/
/analyzer
analyzer type=query
tokenizer class=solr.WhitespaceTokenizerFactory/
filter class=solr.WordDelimiterFilterFactory
generateWordParts=1 generateNumberParts=1 catenateWords=1
catenateNumbers=1 catenateAll=1 splitOnCaseChange=1
preserveOriginal=1/
filter class=solr.LowerCaseFilterFactory/
/analyzer
/fieldType
The problem is this: After submitting this post, if you go to the SOLR
console and find this document, the stored body will be missing the contents
between the less-than and greater-than symbols -- i.e., a c.
If you encode the body (i.e., a lt; b gt; c), it will show up with and
symbols. That is, it appears that SOLR is stripping out HTML tags even
though we are not asking it to.
Note that it is not only the storage but also indexing that is affected (as
we originally found the issue because searching for b would not match this
document.
I'm willing to believe that I'm doing something wrong, but I can't see
anywhere in any spec that suggests that strings inside JSON need to be
--
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-5966) Admin UI - menu is fixed, doesn't respect smaller viewports
[ https://issues.apache.org/jira/browse/SOLR-5966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1366#comment-1366 ] Stefan Matheis (steffkes) commented on SOLR-5966: - so we're good to go? i'll commit this ofter the weekend then :) Admin UI - menu is fixed, doesn't respect smaller viewports --- Key: SOLR-5966 URL: https://issues.apache.org/jira/browse/SOLR-5966 Project: Solr Issue Type: Bug Components: web gui Environment: Operating system: windows 7 64-bit, hard disk - 320GB, Memory - 3GB Reporter: Aman Tandon Priority: Minor Attachments: SOLR-5966.patch I am a window 7 user, i am new in solr, i downloaded the setup for solr 4.7.1 and when i start the server and opened the admin interface using this url: http://localhost:8983/solr/#/collection1, then I noticed that on selecting the collection1 from cores menu, I was unable to view the full list for collection1. Please find this google doc link https://drive.google.com/file/d/0B5GzwVkR3aDzNzJheHVmWFRFYzA/edit?usp=sharing containing the screenshot. -- 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-5966) Admin UI - menu is fixed, doesn't respect smaller viewports
[ https://issues.apache.org/jira/browse/SOLR-5966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-5966: Affects Version/s: 4.8 4.3 4.4 4.5 4.6 4.7 Fix Version/s: 5.0 4.9 Assignee: Stefan Matheis (steffkes) Admin UI - menu is fixed, doesn't respect smaller viewports --- Key: SOLR-5966 URL: https://issues.apache.org/jira/browse/SOLR-5966 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.3, 4.4, 4.5, 4.6, 4.7, 4.8 Environment: Operating system: windows 7 64-bit, hard disk - 320GB, Memory - 3GB Reporter: Aman Tandon Assignee: Stefan Matheis (steffkes) Priority: Minor Fix For: 4.9, 5.0 Attachments: SOLR-5966.patch I am a window 7 user, i am new in solr, i downloaded the setup for solr 4.7.1 and when i start the server and opened the admin interface using this url: http://localhost:8983/solr/#/collection1, then I noticed that on selecting the collection1 from cores menu, I was unable to view the full list for collection1. Please find this google doc link https://drive.google.com/file/d/0B5GzwVkR3aDzNzJheHVmWFRFYzA/edit?usp=sharing containing the screenshot. -- 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-6057) Duplicate background-color in #content #analysis #analysis-result .match (analysis.css)
[
https://issues.apache.org/jira/browse/SOLR-6057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1432#comment-1432
]
Stefan Matheis (steffkes) commented on SOLR-6057:
-
a helping hand is always welcome!
i've already added you to the Contributors Group on the Wiki (mail might be
delayed because of the
[outage|http://blogs.apache.org/infra/entry/mail_outage]).
you can always work on patches, which could then be committed by .. well, a
committer : more detailed read is available at
[HowToContribute|https://wiki.apache.org/solr/HowToContribute] - just give me a
ping (either via jira mentions or on irc) and i'll see that we get it done.
Duplicate background-color in #content #analysis #analysis-result .match
(analysis.css)
---
Key: SOLR-6057
URL: https://issues.apache.org/jira/browse/SOLR-6057
Project: Solr
Issue Type: Bug
Reporter: Al Krinker
Priority: Trivial
Inside of solr/webapp/web/css/styles/analysis.css, you can find #content
#analysis #analysis-result .match element with following content:
#content #analysis #analysis-result .match
{
background-color: #e9eff7;
background-color: #f2f2ff;
}
background-color listed twice.
Also, it was very hard for me to see the highlight. Recommend to change it to
background-color: #FF;
--
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-6057) Duplicate background-color in #content #analysis #analysis-result .match (analysis.css)
[
https://issues.apache.org/jira/browse/SOLR-6057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13999766#comment-13999766
]
Stefan Matheis (steffkes) commented on SOLR-6057:
-
[~al.krinker] in fact it's duplicate, not optimal, but still works (second
overwrites first) - i guess your point is more about color, right?
[~shalinmangar] raised a valid point - but not's only true for the highlight of
the analysis screen .. all the light grey stuff, probably combined with 1px
thick lines are not really working on a projector.
i'm not really good at design - so what we have right now, is what i call my
prototype-layout, because normally no one tries to use that in production ..
for a good reason :D
if anyone has a good idea .. might be a simple template for websites, a
screenshot of a existing app that has decent color scheme .. we could use that
as inspiration to come up with something for us.
Duplicate background-color in #content #analysis #analysis-result .match
(analysis.css)
---
Key: SOLR-6057
URL: https://issues.apache.org/jira/browse/SOLR-6057
Project: Solr
Issue Type: Bug
Reporter: Al Krinker
Priority: Trivial
Inside of solr/webapp/web/css/styles/analysis.css, you can find #content
#analysis #analysis-result .match element with following content:
#content #analysis #analysis-result .match
{
background-color: #e9eff7;
background-color: #f2f2ff;
}
background-color listed twice.
Also, it was very hard for me to see the highlight. Recommend to change it to
background-color: #FF;
--
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-6057) Duplicate background-color in #content #analysis #analysis-result .match (analysis.css)
[
https://issues.apache.org/jira/browse/SOLR-6057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14000113#comment-14000113
]
Stefan Matheis (steffkes) commented on SOLR-6057:
-
We tend to assign only Committers as Assignee, so it's obvious who did commit
the code changes for the issue. And there's a related change from INFRA-7675,
which does disable this by default. should still be able to work with, no?
Duplicate background-color in #content #analysis #analysis-result .match
(analysis.css)
---
Key: SOLR-6057
URL: https://issues.apache.org/jira/browse/SOLR-6057
Project: Solr
Issue Type: Bug
Reporter: Al Krinker
Priority: Trivial
Inside of solr/webapp/web/css/styles/analysis.css, you can find #content
#analysis #analysis-result .match element with following content:
#content #analysis #analysis-result .match
{
background-color: #e9eff7;
background-color: #f2f2ff;
}
background-color listed twice.
Also, it was very hard for me to see the highlight. Recommend to change it to
background-color: #FF;
--
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-5284) Solr Admin shows error message in Links GUI, even though no error
[
https://issues.apache.org/jira/browse/SOLR-5284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13995425#comment-13995425
]
Stefan Matheis (steffkes) commented on SOLR-5284:
-
Jeff, i don't know what exactly {{solrctl}} is, but since your screen shows a
{{*.cloudera.com}} hostname, i guess that is something they've added for their
release?
aside that .. you're raising a different issue within this one. the original
one is about Lynx .. which just has no CSS-/Javascript-Handling at all -
therefore is not able to hide/show anything dynamically. if it's in the
HTML-Code .. it's visible, it's not.
if you like to see that kind of functionality, please open another issue - i'm
going to close that one.
Solr Admin shows error message in Links GUI, even though no error
-
Key: SOLR-5284
URL: https://issues.apache.org/jira/browse/SOLR-5284
Project: Solr
Issue Type: Bug
Affects Versions: 4.4
Reporter: Eric Pugh
Priority: Minor
Attachments: Solr_Admin_Error.png, solr-error.png
Using the Links browser, when I browse to /solr/ the default admin interface
shows the SolrCore error message SolrCore Initialization failure, even
though there was no error! The CSS I think isn't properly hiding that
standard div.
--
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] [Resolved] (SOLR-5284) Solr Admin shows error message in Links GUI, even though no error
[ https://issues.apache.org/jira/browse/SOLR-5284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) resolved SOLR-5284. - Resolution: Not a Problem Assignee: Stefan Matheis (steffkes) Solr Admin shows error message in Links GUI, even though no error - Key: SOLR-5284 URL: https://issues.apache.org/jira/browse/SOLR-5284 Project: Solr Issue Type: Bug Affects Versions: 4.4 Reporter: Eric Pugh Assignee: Stefan Matheis (steffkes) Priority: Minor Attachments: Solr_Admin_Error.png, solr-error.png Using the Links browser, when I browse to /solr/ the default admin interface shows the SolrCore error message SolrCore Initialization failure, even though there was no error! The CSS I think isn't properly hiding that standard div. -- 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-6019) Managed schema file does not show up in the Files UI
[ https://issues.apache.org/jira/browse/SOLR-6019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13981767#comment-13981767 ] Stefan Matheis (steffkes) commented on SOLR-6019: - I vaguely remember another issue, which discussed that. not sure about the reasons that were mentioned - i recall it had something to do with confusing the user (or rather, try to avoid that) so in case of using managed schema, it does not have a schema.xml. Managed schema file does not show up in the Files UI -- Key: SOLR-6019 URL: https://issues.apache.org/jira/browse/SOLR-6019 Project: Solr Issue Type: Bug Components: Schema and Analysis, web gui Affects Versions: 4.7.2, 4.8 Reporter: Shalin Shekhar Mangar Attachments: 6019-missing-managed-schema.png When running with the schema-less example, I noticed that the managed-schema file does not show in the Files section of the Admin UI. This can be confusing for a user. To make sure it was not a caching issue on the browser, I closed and opened the UI again in a new tab. I also restarted Solr and still the managed-schema is not visible in the Files section. Interestingly, the schema.xml.bak does show up. A screenshot of the UI is attached. It is possible that this bug affects other managed resources as well such as synonyms but I haven't tested that yet. The schema browser works fine though. -- 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-6019) Managed schema file does not show up in the Files UI
[ https://issues.apache.org/jira/browse/SOLR-6019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13981770#comment-13981770 ] Stefan Matheis (steffkes) commented on SOLR-6019: - found one comment in [ShowFileRequestHandler.java|http://svn.apache.org/viewvc/lucene/dev/trunk/solr/core/src/java/org/apache/solr/handler/admin/ShowFileRequestHandler.java?view=markup#l278] on line 279ff, leading towards SOLR-5455 Managed schema file does not show up in the Files UI -- Key: SOLR-6019 URL: https://issues.apache.org/jira/browse/SOLR-6019 Project: Solr Issue Type: Bug Components: Schema and Analysis, web gui Affects Versions: 4.7.2, 4.8 Reporter: Shalin Shekhar Mangar Attachments: 6019-missing-managed-schema.png When running with the schema-less example, I noticed that the managed-schema file does not show in the Files section of the Admin UI. This can be confusing for a user. To make sure it was not a caching issue on the browser, I closed and opened the UI again in a new tab. I also restarted Solr and still the managed-schema is not visible in the Files section. Interestingly, the schema.xml.bak does show up. A screenshot of the UI is attached. It is possible that this bug affects other managed resources as well such as synonyms but I haven't tested that yet. The schema browser works fine though. -- 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-5994) Add Jetty configuration to serve JavaDocs
[ https://issues.apache.org/jira/browse/SOLR-5994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13975492#comment-13975492 ] Stefan Matheis (steffkes) commented on SOLR-5994: - Was only a first thought, if we put it somewhere else .. i'm fine w/ it. didn't think it was important enough to be placed in the navigation bar on the left. since quite a few people might directly access the UI, they would be skipping the root context. but in case we're setting up our own entry page there, we could integrate it - don't know if/how we could check if another context is active, but i guess this should be double. admin-extra works on a core-level, not sure if that is a proper place to be for such a documentation? maybe in regards to what David said, we could add another block at the starting page, below 'Versions' to put some documentation links? Add Jetty configuration to serve JavaDocs -- Key: SOLR-5994 URL: https://issues.apache.org/jira/browse/SOLR-5994 Project: Solr Issue Type: Improvement Components: documentation, web gui Affects Versions: 4.7 Reporter: Alexandre Rafalovitch Priority: Minor Labels: javadoc Fix For: 5.0 Attachments: SOLR-5994.patch, javadoc-jetty-context.xml It's possible to add another context file for Jetty that will serve Javadocs from the server. This avoids some Javascript issues, makes the documentation more visible, and opens the door for better integration in the future. -- 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] [Resolved] (SOLR-5897) JQuery file listed as version 1.7.2 but actually contains 1.4.3 code
[ https://issues.apache.org/jira/browse/SOLR-5897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) resolved SOLR-5897. - Resolution: Fixed JQuery file listed as version 1.7.2 but actually contains 1.4.3 code Key: SOLR-5897 URL: https://issues.apache.org/jira/browse/SOLR-5897 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.1, 4.2, 4.2.1, 4.3, 4.3.1, 4.4, 4.5, 4.5.1, 4.6, 4.6.1, 4.7 Environment: All Reporter: Jonathan Lampe Assignee: Stefan Matheis (steffkes) Priority: Minor Labels: jquery, war Fix For: 4.9 Attachments: SOLR-5897.patch The example\webapps\solr.war file contains a jquery-1.7.2.min.js file whose name suggests that it is version 1.7.2. However, the file actually contains version 1.4.3 code. (This code may be subject to CVE-2011-4969.) (I think I read something about a functional roll-back from JQuery 1.5.1 to 1.4.3 in other issues - if so, could possibly be related?) -- 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-5557) Replicatable version from master not shown in slave admin panels
[ https://issues.apache.org/jira/browse/SOLR-5557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13975718#comment-13975718 ] Stefan Matheis (steffkes) commented on SOLR-5557: - Sorry for not getting back on this earlier [~freddrake], had a quick look on this and i'm not sure what i thought i was seeing back then :? Can't produce that right now .. i did setup a master + slave, configured replication, made a few commits on the master and i'm seeing the correct versions - on both places, dashboard replication page. since that issue is from December and the only related issue (SOLR-4661) was committed in April .. i'd guess that is still happening for you? If so, let me know. Replicatable version from master not shown in slave admin panels Key: SOLR-5557 URL: https://issues.apache.org/jira/browse/SOLR-5557 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.6 Reporter: Fred Drake Priority: Minor The Overview and Replication panels for a slave core include three fields to show what version of the index is used: Master (Searching) Master (Replicable) Slave (Searching) The Master (Replicable) field is left blank. steffkes on IRC suggests that there is a typo somewhere; that the relevant fields are referenced inconsistently as replicatableGeneration and replicableGeneration. -- 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-5966) Admin UI - menu is fixed, doesn't respect smaller viewports
[ https://issues.apache.org/jira/browse/SOLR-5966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-5966: Summary: Admin UI - menu is fixed, doesn't respect smaller viewports (was: Admin interface issue in solr 4.7.1) Admin UI - menu is fixed, doesn't respect smaller viewports --- Key: SOLR-5966 URL: https://issues.apache.org/jira/browse/SOLR-5966 Project: Solr Issue Type: Bug Components: web gui Environment: Operating system: windows 7 64-bit, hard disk - 320GB, Memory - 3GB Reporter: Aman Tandon Priority: Minor I am a window 7 user, i am new in solr, i downloaded the setup for solr 4.7.1 and when i start the server and opened the admin interface using this url: http://localhost:8983/solr/#/collection1, then I noticed that on selecting the collection1 from cores menu, I was unable to view the full list for collection1. Please find this google doc link https://drive.google.com/file/d/0B5GzwVkR3aDzNzJheHVmWFRFYzA/edit?usp=sharing containing the screenshot. -- 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-5966) Admin UI - menu is fixed, doesn't respect smaller viewports
[ https://issues.apache.org/jira/browse/SOLR-5966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-5966: Attachment: SOLR-5966.patch I've updated the issue title, it's not a windows-specific problem. attached a first version of the patch, which uses an additional class to switch between different 'modes'. one (still) fixed, if the viewport is big enough, the other scrollable, in case you can't see the menu all at once. it's checked when the page loads, the menu changes and when you resize your browser window. Admin UI - menu is fixed, doesn't respect smaller viewports --- Key: SOLR-5966 URL: https://issues.apache.org/jira/browse/SOLR-5966 Project: Solr Issue Type: Bug Components: web gui Environment: Operating system: windows 7 64-bit, hard disk - 320GB, Memory - 3GB Reporter: Aman Tandon Priority: Minor Attachments: SOLR-5966.patch I am a window 7 user, i am new in solr, i downloaded the setup for solr 4.7.1 and when i start the server and opened the admin interface using this url: http://localhost:8983/solr/#/collection1, then I noticed that on selecting the collection1 from cores menu, I was unable to view the full list for collection1. Please find this google doc link https://drive.google.com/file/d/0B5GzwVkR3aDzNzJheHVmWFRFYzA/edit?usp=sharing containing the screenshot. -- 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-5897) JQuery file listed as version 1.7.2 but actually contains 1.4.3 code
[ https://issues.apache.org/jira/browse/SOLR-5897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-5897: Fix Version/s: 4.9 Assignee: Stefan Matheis (steffkes) I'm going to commit this tomorrow JQuery file listed as version 1.7.2 but actually contains 1.4.3 code Key: SOLR-5897 URL: https://issues.apache.org/jira/browse/SOLR-5897 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.1, 4.2, 4.2.1, 4.3, 4.3.1, 4.4, 4.5, 4.5.1, 4.6, 4.6.1, 4.7 Environment: All Reporter: Jonathan Lampe Assignee: Stefan Matheis (steffkes) Priority: Minor Labels: jquery, war Fix For: 4.9 Attachments: SOLR-5897.patch The example\webapps\solr.war file contains a jquery-1.7.2.min.js file whose name suggests that it is version 1.7.2. However, the file actually contains version 1.4.3 code. (This code may be subject to CVE-2011-4969.) (I think I read something about a functional roll-back from JQuery 1.5.1 to 1.4.3 in other issues - if so, could possibly be related?) -- 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-5994) Add Jetty configuration to serve JavaDocs
[
https://issues.apache.org/jira/browse/SOLR-5994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Matheis (steffkes) updated SOLR-5994:
Attachment: SOLR-5994.patch
how about this?
thought first about adding another link, but figured that Documentation
pointing to the homepage is perhaps not the best idea anyway?
at the initial load of the UI, a few lines javascript are checking if
{{/javadoc/}} is available on the same machine, if not, the link gets changed
to the published javadocs on l.a.o
Add Jetty configuration to serve JavaDocs
--
Key: SOLR-5994
URL: https://issues.apache.org/jira/browse/SOLR-5994
Project: Solr
Issue Type: Improvement
Components: documentation, web gui
Affects Versions: 4.7
Reporter: Alexandre Rafalovitch
Priority: Minor
Labels: javadoc
Fix For: 5.0
Attachments: SOLR-5994.patch, javadoc-jetty-context.xml
It's possible to add another context file for Jetty that will serve Javadocs
from the server.
This avoids some Javascript issues, makes the documentation more visible, and
opens the door for better integration in the future.
--
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-5994) Add Jetty configuration to serve JavaDocs
[ https://issues.apache.org/jira/browse/SOLR-5994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13974097#comment-13974097 ] Stefan Matheis (steffkes) commented on SOLR-5994: - i vaguely remembered another issue which aimed to change the default jetty page - i'm linking those two, just in case, so that nothing gets lost Add Jetty configuration to serve JavaDocs -- Key: SOLR-5994 URL: https://issues.apache.org/jira/browse/SOLR-5994 Project: Solr Issue Type: Improvement Components: documentation, web gui Affects Versions: 4.7 Reporter: Alexandre Rafalovitch Priority: Minor Labels: javadoc Fix For: 5.0 Attachments: SOLR-5994.patch, javadoc-jetty-context.xml It's possible to add another context file for Jetty that will serve Javadocs from the server. This avoids some Javascript issues, makes the documentation more visible, and opens the door for better integration in the future. -- 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] [Resolved] (SOLR-5953) Analysis not correctly shown when using also HTMLStripCharFilterFactory
[
https://issues.apache.org/jira/browse/SOLR-5953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Matheis (steffkes) resolved SOLR-5953.
-
Resolution: Duplicate
Assignee: Stefan Matheis (steffkes)
This issue was already reported and got fixed within 4.7.1 which was released
yesterday.
Analysis not correctly shown when using also HTMLStripCharFilterFactory
---
Key: SOLR-5953
URL: https://issues.apache.org/jira/browse/SOLR-5953
Project: Solr
Issue Type: Bug
Components: web gui
Affects Versions: 4.7
Reporter: Zaccheo Bagnati
Assignee: Stefan Matheis (steffkes)
Priority: Minor
When analyzing a field with only HTMLStripCharFilterFactory and
StandardTokenizerFactory, the analysis page doesn't show output for
StandardTokenizerFactory even if json response seems to be correct.
To reproduce:
This is the schema:
?xml version=1.0 ?
schema name=${solr.core.name} version=1.5
types
fieldType name=long class=solr.TrieLongField precisionStep=0
positionIncrementGap=0/
fieldType name=testhtml class=solr.TextField
analyzer
charFilter class=solr.HTMLStripCharFilterFactory/
tokenizer class=solr.StandardTokenizerFactory/
/analyzer
/fieldType
fieldType name=test class=solr.TextField
analyzer
tokenizer class=solr.StandardTokenizerFactory/
/analyzer
/fieldType
/types
fields
field name=_version_ type=long indexed=true stored=true/
field name=id type=long indexed=true stored=true
multiValued=false /
field name=test type=test indexed=true stored=true
multiValued=false /
field name=testhtml type=testhtml indexed=true stored=true
multiValued=false /
/fields
!-- field to use to determine and enforce document uniqueness. --
uniqueKeyid/uniqueKey
!-- field for the QueryParser to use when an explicit fieldname is absent
--
defaultSearchFieldtest/defaultSearchField
/schema
Go to analysis page, choose testhtml field and insert a b in Field Value
(Index).
The output shown for HTMLSCF is correct (a b), but nothing is shown in the
output of ST.
If you choose test field, with only ST, it works as expected.
The json, inspected with firebug, seems correct, I think it is only a
graphical issue.
--
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-5897) JQuery file listed as version 1.7.2 but actually contains 1.4.3 code
[ https://issues.apache.org/jira/browse/SOLR-5897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-5897: Attachment: SOLR-5897.patch That's actually right - looks like the file only got renamed. Patch attached JQuery file listed as version 1.7.2 but actually contains 1.4.3 code Key: SOLR-5897 URL: https://issues.apache.org/jira/browse/SOLR-5897 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.1, 4.2, 4.2.1, 4.3, 4.3.1, 4.4, 4.5, 4.5.1, 4.6, 4.6.1, 4.7 Environment: All Reporter: Jonathan Lampe Priority: Minor Labels: jquery, war Attachments: SOLR-5897.patch The example\webapps\solr.war file contains a jquery-1.7.2.min.js file whose name suggests that it is version 1.7.2. However, the file actually contains version 1.4.3 code. (This code may be subject to CVE-2011-4969.) (I think I read something about a functional roll-back from JQuery 1.5.1 to 1.4.3 in other issues - if so, could possibly be related?) -- 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-5897) JQuery file listed as version 1.7.2 but actually contains 1.4.3 code
[ https://issues.apache.org/jira/browse/SOLR-5897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13945235#comment-13945235 ] Stefan Matheis (steffkes) edited comment on SOLR-5897 at 3/24/14 3:44 PM: -- That's actually right - looks like the file only got renamed in [r1311442|http://svn.apache.org/r1311442]. Patch attached was (Author: steffkes): That's actually right - looks like the file only got renamed. Patch attached JQuery file listed as version 1.7.2 but actually contains 1.4.3 code Key: SOLR-5897 URL: https://issues.apache.org/jira/browse/SOLR-5897 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.1, 4.2, 4.2.1, 4.3, 4.3.1, 4.4, 4.5, 4.5.1, 4.6, 4.6.1, 4.7 Environment: All Reporter: Jonathan Lampe Priority: Minor Labels: jquery, war Attachments: SOLR-5897.patch The example\webapps\solr.war file contains a jquery-1.7.2.min.js file whose name suggests that it is version 1.7.2. However, the file actually contains version 1.4.3 code. (This code may be subject to CVE-2011-4969.) (I think I read something about a functional roll-back from JQuery 1.5.1 to 1.4.3 in other issues - if so, could possibly be related?) -- 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-5800) Admin UI - Analysis form doesn't render results correctly when a CharFilter is used.
[
https://issues.apache.org/jira/browse/SOLR-5800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Matheis (steffkes) updated SOLR-5800:
Fix Version/s: 4.7.1
Admin UI - Analysis form doesn't render results correctly when a CharFilter
is used.
Key: SOLR-5800
URL: https://issues.apache.org/jira/browse/SOLR-5800
Project: Solr
Issue Type: Bug
Components: web gui
Affects Versions: 4.7
Reporter: Timothy Potter
Assignee: Stefan Matheis (steffkes)
Priority: Minor
Fix For: 4.8, 5.0, 4.7.1
Attachments: SOLR-5800-sample.json, SOLR-5800.patch
I have an example in Solr In Action that uses the
PatternReplaceCharFilterFactory and now it doesn't work in 4.7.0.
Specifically, the fieldType is:
fieldType name=text_microblog class=solr.TextField
positionIncrementGap=100
analyzer
charFilter class=solr.PatternReplaceCharFilterFactory
pattern=([a-zA-Z])\1+
replacement=$1$1/
tokenizer class=solr.WhitespaceTokenizerFactory/
filter class=solr.WordDelimiterFilterFactory
generateWordParts=1
splitOnCaseChange=0
splitOnNumerics=0
stemEnglishPossessive=1
preserveOriginal=0
catenateWords=1
generateNumberParts=1
catenateNumbers=0
catenateAll=0
types=wdfftypes.txt/
filter class=solr.StopFilterFactory
ignoreCase=true
words=lang/stopwords_en.txt
/
filter class=solr.LowerCaseFilterFactory/
filter class=solr.ASCIIFoldingFilterFactory/
filter class=solr.KStemFilterFactory/
/analyzer
/fieldType
The PatternReplaceCharFilterFactory (PRCF) is used to collapse
repeated letters in a term down to a max of 2, such as #yu would
be #yumm
When I run some text through this analyzer using the Analysis form,
the output is as if the resulting text is unavailable to the
tokenizer. In other words, the only results being displayed in the
output on the form is for the PRCF
This example stopped working in 4.7.0 and I've verified it worked
correctly in 4.6.1.
Initially, I thought this might be an issue with the actual analysis,
but the analyzer actually works when indexing / querying. Then,
looking at the JSON response in the Developer console with Chrome, I
see the JSON that comes back includes output for all the components in
my chain (see below) ... so looks like a UI rendering issue to me?
{responseHeader:{status:0,QTime:24},analysis:{field_types:{text_microblog:{index:[org.apache.lucene.analysis.pattern.PatternReplaceCharFilter,#Yumm
:) Drinking a latte at Caffe Grecco in SF's historic North Beach...
Learning text analysis with #SolrInAction by @ManningBooks on my i-Pad
foo5,org.apache.lucene.analysis.core.WhitespaceTokenizer,[{text:#Yumm,raw_bytes:[23
59 75 6d
6d],start:0,end:6,position:1,positionHistory:[1],type:word},{text::),raw_bytes:[3a
29],start:7,end:9,position:2,positionHistory:[2],type:word},{text:Drinking,raw_bytes:[44
72 69 6e 6b 69 6e
67],start:10,end:18,position:3,positionHistory:[3],type:word},{text:a,raw_bytes:[61],start:19,end:20,position:4,positionHistory:[4],type:word},{text:latte,raw_bytes:[6c
...
the JSON returned to the browser has evidence that the full analysis chain
was applied, so this seems to just be a rendering issue.
--
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] [Resolved] (SOLR-5870) Admin UI - Reload on Core Admin doesn't show errors
[ https://issues.apache.org/jira/browse/SOLR-5870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) resolved SOLR-5870. - Resolution: Fixed Admin UI - Reload on Core Admin doesn't show errors --- Key: SOLR-5870 URL: https://issues.apache.org/jira/browse/SOLR-5870 Project: Solr Issue Type: Bug Components: web gui Reporter: Stefan Matheis (steffkes) Assignee: Stefan Matheis (steffkes) Priority: Minor Fix For: 4.8, 5.0 Attachments: SOLR-5870.patch Christopher, friend of mine, made me realize, that the 'Reload' Button on the Core-Admin Screen doesn't show errors, if there are any - caused by a core reload. -- 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-5870) Admin UI - Reload on Core Admin doesn't show errors
[ https://issues.apache.org/jira/browse/SOLR-5870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-5870: Fix Version/s: 4.7.1 Admin UI - Reload on Core Admin doesn't show errors --- Key: SOLR-5870 URL: https://issues.apache.org/jira/browse/SOLR-5870 Project: Solr Issue Type: Bug Components: web gui Reporter: Stefan Matheis (steffkes) Assignee: Stefan Matheis (steffkes) Priority: Minor Fix For: 4.8, 5.0, 4.7.1 Attachments: SOLR-5870.patch Christopher, friend of mine, made me realize, that the 'Reload' Button on the Core-Admin Screen doesn't show errors, if there are any - caused by a core reload. -- 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-5870) Admin UI - Reload on Core Admin doesn't show errors
[ https://issues.apache.org/jira/browse/SOLR-5870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-5870: Attachment: SOLR-5870.patch Admin UI - Reload on Core Admin doesn't show errors --- Key: SOLR-5870 URL: https://issues.apache.org/jira/browse/SOLR-5870 Project: Solr Issue Type: Bug Components: web gui Reporter: Stefan Matheis (steffkes) Assignee: Stefan Matheis (steffkes) Priority: Minor Fix For: 4.8, 5.0 Attachments: SOLR-5870.patch Christopher, friend of mine, made me realize, that the 'Reload' Button on the Core-Admin Screen doesn't show errors, if there are any - caused by a core reload. -- 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-5870) Admin UI - Reload on Core Admin doesn't show errors
Stefan Matheis (steffkes) created SOLR-5870: --- Summary: Admin UI - Reload on Core Admin doesn't show errors Key: SOLR-5870 URL: https://issues.apache.org/jira/browse/SOLR-5870 Project: Solr Issue Type: Bug Components: web gui Reporter: Stefan Matheis (steffkes) Assignee: Stefan Matheis (steffkes) Priority: Minor Fix For: 4.8, 5.0 Attachments: SOLR-5870.patch Christopher, friend of mine, made me realize, that the 'Reload' Button on the Core-Admin Screen doesn't show errors, if there are any - caused by a core reload. -- 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] [Resolved] (SOLR-5800) Admin UI - Analysis form doesn't render results correctly when a CharFilter is used.
[
https://issues.apache.org/jira/browse/SOLR-5800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Matheis (steffkes) resolved SOLR-5800.
-
Resolution: Fixed
Admin UI - Analysis form doesn't render results correctly when a CharFilter
is used.
Key: SOLR-5800
URL: https://issues.apache.org/jira/browse/SOLR-5800
Project: Solr
Issue Type: Bug
Components: web gui
Affects Versions: 4.7
Reporter: Timothy Potter
Assignee: Stefan Matheis (steffkes)
Priority: Minor
Fix For: 4.8, 5.0
Attachments: SOLR-5800-sample.json, SOLR-5800.patch
I have an example in Solr In Action that uses the
PatternReplaceCharFilterFactory and now it doesn't work in 4.7.0.
Specifically, the fieldType is:
fieldType name=text_microblog class=solr.TextField
positionIncrementGap=100
analyzer
charFilter class=solr.PatternReplaceCharFilterFactory
pattern=([a-zA-Z])\1+
replacement=$1$1/
tokenizer class=solr.WhitespaceTokenizerFactory/
filter class=solr.WordDelimiterFilterFactory
generateWordParts=1
splitOnCaseChange=0
splitOnNumerics=0
stemEnglishPossessive=1
preserveOriginal=0
catenateWords=1
generateNumberParts=1
catenateNumbers=0
catenateAll=0
types=wdfftypes.txt/
filter class=solr.StopFilterFactory
ignoreCase=true
words=lang/stopwords_en.txt
/
filter class=solr.LowerCaseFilterFactory/
filter class=solr.ASCIIFoldingFilterFactory/
filter class=solr.KStemFilterFactory/
/analyzer
/fieldType
The PatternReplaceCharFilterFactory (PRCF) is used to collapse
repeated letters in a term down to a max of 2, such as #yu would
be #yumm
When I run some text through this analyzer using the Analysis form,
the output is as if the resulting text is unavailable to the
tokenizer. In other words, the only results being displayed in the
output on the form is for the PRCF
This example stopped working in 4.7.0 and I've verified it worked
correctly in 4.6.1.
Initially, I thought this might be an issue with the actual analysis,
but the analyzer actually works when indexing / querying. Then,
looking at the JSON response in the Developer console with Chrome, I
see the JSON that comes back includes output for all the components in
my chain (see below) ... so looks like a UI rendering issue to me?
{responseHeader:{status:0,QTime:24},analysis:{field_types:{text_microblog:{index:[org.apache.lucene.analysis.pattern.PatternReplaceCharFilter,#Yumm
:) Drinking a latte at Caffe Grecco in SF's historic North Beach...
Learning text analysis with #SolrInAction by @ManningBooks on my i-Pad
foo5,org.apache.lucene.analysis.core.WhitespaceTokenizer,[{text:#Yumm,raw_bytes:[23
59 75 6d
6d],start:0,end:6,position:1,positionHistory:[1],type:word},{text::),raw_bytes:[3a
29],start:7,end:9,position:2,positionHistory:[2],type:word},{text:Drinking,raw_bytes:[44
72 69 6e 6b 69 6e
67],start:10,end:18,position:3,positionHistory:[3],type:word},{text:a,raw_bytes:[61],start:19,end:20,position:4,positionHistory:[4],type:word},{text:latte,raw_bytes:[6c
...
the JSON returned to the browser has evidence that the full analysis chain
was applied, so this seems to just be a rendering issue.
--
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-5800) Admin UI - Analysis form doesn't render results correctly when a CharFilter is used.
[
https://issues.apache.org/jira/browse/SOLR-5800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931586#comment-13931586
]
Stefan Matheis (steffkes) commented on SOLR-5800:
-
Hey Doug, that depends a bit - 'the next available release' i'd say, might be
4.7.1 if it's needed otherwise it would be 4.8
Admin UI - Analysis form doesn't render results correctly when a CharFilter
is used.
Key: SOLR-5800
URL: https://issues.apache.org/jira/browse/SOLR-5800
Project: Solr
Issue Type: Bug
Components: web gui
Affects Versions: 4.7
Reporter: Timothy Potter
Assignee: Stefan Matheis (steffkes)
Priority: Minor
Fix For: 4.8, 5.0
Attachments: SOLR-5800-sample.json, SOLR-5800.patch
I have an example in Solr In Action that uses the
PatternReplaceCharFilterFactory and now it doesn't work in 4.7.0.
Specifically, the fieldType is:
fieldType name=text_microblog class=solr.TextField
positionIncrementGap=100
analyzer
charFilter class=solr.PatternReplaceCharFilterFactory
pattern=([a-zA-Z])\1+
replacement=$1$1/
tokenizer class=solr.WhitespaceTokenizerFactory/
filter class=solr.WordDelimiterFilterFactory
generateWordParts=1
splitOnCaseChange=0
splitOnNumerics=0
stemEnglishPossessive=1
preserveOriginal=0
catenateWords=1
generateNumberParts=1
catenateNumbers=0
catenateAll=0
types=wdfftypes.txt/
filter class=solr.StopFilterFactory
ignoreCase=true
words=lang/stopwords_en.txt
/
filter class=solr.LowerCaseFilterFactory/
filter class=solr.ASCIIFoldingFilterFactory/
filter class=solr.KStemFilterFactory/
/analyzer
/fieldType
The PatternReplaceCharFilterFactory (PRCF) is used to collapse
repeated letters in a term down to a max of 2, such as #yu would
be #yumm
When I run some text through this analyzer using the Analysis form,
the output is as if the resulting text is unavailable to the
tokenizer. In other words, the only results being displayed in the
output on the form is for the PRCF
This example stopped working in 4.7.0 and I've verified it worked
correctly in 4.6.1.
Initially, I thought this might be an issue with the actual analysis,
but the analyzer actually works when indexing / querying. Then,
looking at the JSON response in the Developer console with Chrome, I
see the JSON that comes back includes output for all the components in
my chain (see below) ... so looks like a UI rendering issue to me?
{responseHeader:{status:0,QTime:24},analysis:{field_types:{text_microblog:{index:[org.apache.lucene.analysis.pattern.PatternReplaceCharFilter,#Yumm
:) Drinking a latte at Caffe Grecco in SF's historic North Beach...
Learning text analysis with #SolrInAction by @ManningBooks on my i-Pad
foo5,org.apache.lucene.analysis.core.WhitespaceTokenizer,[{text:#Yumm,raw_bytes:[23
59 75 6d
6d],start:0,end:6,position:1,positionHistory:[1],type:word},{text::),raw_bytes:[3a
29],start:7,end:9,position:2,positionHistory:[2],type:word},{text:Drinking,raw_bytes:[44
72 69 6e 6b 69 6e
67],start:10,end:18,position:3,positionHistory:[3],type:word},{text:a,raw_bytes:[61],start:19,end:20,position:4,positionHistory:[4],type:word},{text:latte,raw_bytes:[6c
...
the JSON returned to the browser has evidence that the full analysis chain
was applied, so this seems to just be a rendering issue.
--
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-5419) Solr Admin UI Query Result Does Nothing at Error
[
https://issues.apache.org/jira/browse/SOLR-5419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Matheis (steffkes) updated SOLR-5419:
Attachment: Screen Shot 2014-03-12 at 2.53.50 PM.png
Furkan, if i'm not mistaken, the patch doesn't change anything? since it
actually is triggered on the {{complete}}-event, it covers the {{success}} as
well as the {{error}} case. all the defined {{content_generator}} depend on
{{xhr.responseText}} and highlighting is only applied if the response is
successful - so it basically does that already.
running trunk in fact does what you say it doesn't? see the attached
screenshot, using r1576737 therefore - w/o your patch?
i'd guess you see something on your browsers console bar in case the Loading
.. isn't removed?
Solr Admin UI Query Result Does Nothing at Error
Key: SOLR-5419
URL: https://issues.apache.org/jira/browse/SOLR-5419
Project: Solr
Issue Type: Bug
Components: web gui
Affects Versions: 4.5.1, 4.6, 4.6.1, 4.7
Reporter: Furkan KAMACI
Priority: Minor
Fix For: 4.8
Attachments: SOLR-5419.patch, Screen Shot 2014-03-12 at 2.53.50 PM.png
When you make a query into Solr via Solr Admin Page and if an error occurs
there writes Loading.. and nothing happens.
i.e. if you write an invalid Request Handler (something like /select
instead of /select) at Query page and even response is 404 Not Found you will
see that Loading... is still there and you will not able to understand
whether an error occurred or the response is so slow at first glance.
--
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-5800) Admin UI - Analysis form doesn't render results correctly when a CharFilter is used.
[
https://issues.apache.org/jira/browse/SOLR-5800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13925890#comment-13925890
]
Stefan Matheis (steffkes) commented on SOLR-5800:
-
[~tim.potter] did you have a chance? otherwise i would commit that one tomorrow
Admin UI - Analysis form doesn't render results correctly when a CharFilter
is used.
Key: SOLR-5800
URL: https://issues.apache.org/jira/browse/SOLR-5800
Project: Solr
Issue Type: Bug
Components: web gui
Affects Versions: 4.7
Reporter: Timothy Potter
Assignee: Stefan Matheis (steffkes)
Priority: Minor
Fix For: 4.8, 5.0
Attachments: SOLR-5800-sample.json, SOLR-5800.patch
I have an example in Solr In Action that uses the
PatternReplaceCharFilterFactory and now it doesn't work in 4.7.0.
Specifically, the fieldType is:
fieldType name=text_microblog class=solr.TextField
positionIncrementGap=100
analyzer
charFilter class=solr.PatternReplaceCharFilterFactory
pattern=([a-zA-Z])\1+
replacement=$1$1/
tokenizer class=solr.WhitespaceTokenizerFactory/
filter class=solr.WordDelimiterFilterFactory
generateWordParts=1
splitOnCaseChange=0
splitOnNumerics=0
stemEnglishPossessive=1
preserveOriginal=0
catenateWords=1
generateNumberParts=1
catenateNumbers=0
catenateAll=0
types=wdfftypes.txt/
filter class=solr.StopFilterFactory
ignoreCase=true
words=lang/stopwords_en.txt
/
filter class=solr.LowerCaseFilterFactory/
filter class=solr.ASCIIFoldingFilterFactory/
filter class=solr.KStemFilterFactory/
/analyzer
/fieldType
The PatternReplaceCharFilterFactory (PRCF) is used to collapse
repeated letters in a term down to a max of 2, such as #yu would
be #yumm
When I run some text through this analyzer using the Analysis form,
the output is as if the resulting text is unavailable to the
tokenizer. In other words, the only results being displayed in the
output on the form is for the PRCF
This example stopped working in 4.7.0 and I've verified it worked
correctly in 4.6.1.
Initially, I thought this might be an issue with the actual analysis,
but the analyzer actually works when indexing / querying. Then,
looking at the JSON response in the Developer console with Chrome, I
see the JSON that comes back includes output for all the components in
my chain (see below) ... so looks like a UI rendering issue to me?
{responseHeader:{status:0,QTime:24},analysis:{field_types:{text_microblog:{index:[org.apache.lucene.analysis.pattern.PatternReplaceCharFilter,#Yumm
:) Drinking a latte at Caffe Grecco in SF's historic North Beach...
Learning text analysis with #SolrInAction by @ManningBooks on my i-Pad
foo5,org.apache.lucene.analysis.core.WhitespaceTokenizer,[{text:#Yumm,raw_bytes:[23
59 75 6d
6d],start:0,end:6,position:1,positionHistory:[1],type:word},{text::),raw_bytes:[3a
29],start:7,end:9,position:2,positionHistory:[2],type:word},{text:Drinking,raw_bytes:[44
72 69 6e 6b 69 6e
67],start:10,end:18,position:3,positionHistory:[3],type:word},{text:a,raw_bytes:[61],start:19,end:20,position:4,positionHistory:[4],type:word},{text:latte,raw_bytes:[6c
...
the JSON returned to the browser has evidence that the full analysis chain
was applied, so this seems to just be a rendering issue.
--
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-5810) State of external collections not displayed in cloud graph panel
[ https://issues.apache.org/jira/browse/SOLR-5810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-5810: Component/s: web gui State of external collections not displayed in cloud graph panel Key: SOLR-5810 URL: https://issues.apache.org/jira/browse/SOLR-5810 Project: Solr Issue Type: Improvement Components: SolrCloud, web gui Reporter: Timothy Potter External collections (SOLR-5473) are not displayed in the Cloud - graph panel, which makes it very hard to see which external collections have problems, such as after a downed node comes back online. -- 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-5800) Analysis form doesn't render analys results correctly when a CharFilter is used.
[
https://issues.apache.org/jira/browse/SOLR-5800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13917385#comment-13917385
]
Stefan Matheis (steffkes) commented on SOLR-5800:
-
after a bit digging, it's clear that SOLR-4612 is responsible for the chance -
to remove the empty columns, i've used the first element to distinguish how
many columns the table might have .. i can of the PatternReplaceCharFilter
that's only .. one.
if i'm not mistaken, the fix should be, that we loop over all records to get
the over all column count - working on it.
Analysis form doesn't render analys results correctly when a CharFilter is
used.
Key: SOLR-5800
URL: https://issues.apache.org/jira/browse/SOLR-5800
Project: Solr
Issue Type: Bug
Components: web gui
Affects Versions: 4.7
Reporter: Timothy Potter
Priority: Minor
Attachments: SOLR-5800-sample.json
I have an example in Solr In Action that uses the
PatternReplaceCharFilterFactory and now it doesn't work in 4.7.0.
Specifically, the fieldType is:
fieldType name=text_microblog class=solr.TextField
positionIncrementGap=100
analyzer
charFilter class=solr.PatternReplaceCharFilterFactory
pattern=([a-zA-Z])\1+
replacement=$1$1/
tokenizer class=solr.WhitespaceTokenizerFactory/
filter class=solr.WordDelimiterFilterFactory
generateWordParts=1
splitOnCaseChange=0
splitOnNumerics=0
stemEnglishPossessive=1
preserveOriginal=0
catenateWords=1
generateNumberParts=1
catenateNumbers=0
catenateAll=0
types=wdfftypes.txt/
filter class=solr.StopFilterFactory
ignoreCase=true
words=lang/stopwords_en.txt
/
filter class=solr.LowerCaseFilterFactory/
filter class=solr.ASCIIFoldingFilterFactory/
filter class=solr.KStemFilterFactory/
/analyzer
/fieldType
The PatternReplaceCharFilterFactory (PRCF) is used to collapse
repeated letters in a term down to a max of 2, such as #yu would
be #yumm
When I run some text through this analyzer using the Analysis form,
the output is as if the resulting text is unavailable to the
tokenizer. In other words, the only results being displayed in the
output on the form is for the PRCF
This example stopped working in 4.7.0 and I've verified it worked
correctly in 4.6.1.
Initially, I thought this might be an issue with the actual analysis,
but the analyzer actually works when indexing / querying. Then,
looking at the JSON response in the Developer console with Chrome, I
see the JSON that comes back includes output for all the components in
my chain (see below) ... so looks like a UI rendering issue to me?
{responseHeader:{status:0,QTime:24},analysis:{field_types:{text_microblog:{index:[org.apache.lucene.analysis.pattern.PatternReplaceCharFilter,#Yumm
:) Drinking a latte at Caffe Grecco in SF's historic North Beach...
Learning text analysis with #SolrInAction by @ManningBooks on my i-Pad
foo5,org.apache.lucene.analysis.core.WhitespaceTokenizer,[{text:#Yumm,raw_bytes:[23
59 75 6d
6d],start:0,end:6,position:1,positionHistory:[1],type:word},{text::),raw_bytes:[3a
29],start:7,end:9,position:2,positionHistory:[2],type:word},{text:Drinking,raw_bytes:[44
72 69 6e 6b 69 6e
67],start:10,end:18,position:3,positionHistory:[3],type:word},{text:a,raw_bytes:[61],start:19,end:20,position:4,positionHistory:[4],type:word},{text:latte,raw_bytes:[6c
...
the JSON returned to the browser has evidence that the full analysis chain
was applied, so this seems to just be a rendering issue.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5800) Admin UI - Analysis form doesn't render results correctly when a CharFilter is used.
[
https://issues.apache.org/jira/browse/SOLR-5800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Matheis (steffkes) updated SOLR-5800:
Summary: Admin UI - Analysis form doesn't render results correctly when a
CharFilter is used. (was: Analysis form doesn't render analys results
correctly when a CharFilter is used.)
Admin UI - Analysis form doesn't render results correctly when a CharFilter
is used.
Key: SOLR-5800
URL: https://issues.apache.org/jira/browse/SOLR-5800
Project: Solr
Issue Type: Bug
Components: web gui
Affects Versions: 4.7
Reporter: Timothy Potter
Priority: Minor
Attachments: SOLR-5800-sample.json
I have an example in Solr In Action that uses the
PatternReplaceCharFilterFactory and now it doesn't work in 4.7.0.
Specifically, the fieldType is:
fieldType name=text_microblog class=solr.TextField
positionIncrementGap=100
analyzer
charFilter class=solr.PatternReplaceCharFilterFactory
pattern=([a-zA-Z])\1+
replacement=$1$1/
tokenizer class=solr.WhitespaceTokenizerFactory/
filter class=solr.WordDelimiterFilterFactory
generateWordParts=1
splitOnCaseChange=0
splitOnNumerics=0
stemEnglishPossessive=1
preserveOriginal=0
catenateWords=1
generateNumberParts=1
catenateNumbers=0
catenateAll=0
types=wdfftypes.txt/
filter class=solr.StopFilterFactory
ignoreCase=true
words=lang/stopwords_en.txt
/
filter class=solr.LowerCaseFilterFactory/
filter class=solr.ASCIIFoldingFilterFactory/
filter class=solr.KStemFilterFactory/
/analyzer
/fieldType
The PatternReplaceCharFilterFactory (PRCF) is used to collapse
repeated letters in a term down to a max of 2, such as #yu would
be #yumm
When I run some text through this analyzer using the Analysis form,
the output is as if the resulting text is unavailable to the
tokenizer. In other words, the only results being displayed in the
output on the form is for the PRCF
This example stopped working in 4.7.0 and I've verified it worked
correctly in 4.6.1.
Initially, I thought this might be an issue with the actual analysis,
but the analyzer actually works when indexing / querying. Then,
looking at the JSON response in the Developer console with Chrome, I
see the JSON that comes back includes output for all the components in
my chain (see below) ... so looks like a UI rendering issue to me?
{responseHeader:{status:0,QTime:24},analysis:{field_types:{text_microblog:{index:[org.apache.lucene.analysis.pattern.PatternReplaceCharFilter,#Yumm
:) Drinking a latte at Caffe Grecco in SF's historic North Beach...
Learning text analysis with #SolrInAction by @ManningBooks on my i-Pad
foo5,org.apache.lucene.analysis.core.WhitespaceTokenizer,[{text:#Yumm,raw_bytes:[23
59 75 6d
6d],start:0,end:6,position:1,positionHistory:[1],type:word},{text::),raw_bytes:[3a
29],start:7,end:9,position:2,positionHistory:[2],type:word},{text:Drinking,raw_bytes:[44
72 69 6e 6b 69 6e
67],start:10,end:18,position:3,positionHistory:[3],type:word},{text:a,raw_bytes:[61],start:19,end:20,position:4,positionHistory:[4],type:word},{text:latte,raw_bytes:[6c
...
the JSON returned to the browser has evidence that the full analysis chain
was applied, so this seems to just be a rendering issue.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5800) Admin UI - Analysis form doesn't render results correctly when a CharFilter is used.
[
https://issues.apache.org/jira/browse/SOLR-5800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Matheis (steffkes) updated SOLR-5800:
Attachment: SOLR-5800.patch
[~tim.potter], [~Mr.HTZ] would you mind giving this patch a try? at least your
provided example works (again) and looks like expected, while still maintaing
the correct column count (as initially tried on SOLR-4612)
Admin UI - Analysis form doesn't render results correctly when a CharFilter
is used.
Key: SOLR-5800
URL: https://issues.apache.org/jira/browse/SOLR-5800
Project: Solr
Issue Type: Bug
Components: web gui
Affects Versions: 4.7
Reporter: Timothy Potter
Priority: Minor
Attachments: SOLR-5800-sample.json, SOLR-5800.patch
I have an example in Solr In Action that uses the
PatternReplaceCharFilterFactory and now it doesn't work in 4.7.0.
Specifically, the fieldType is:
fieldType name=text_microblog class=solr.TextField
positionIncrementGap=100
analyzer
charFilter class=solr.PatternReplaceCharFilterFactory
pattern=([a-zA-Z])\1+
replacement=$1$1/
tokenizer class=solr.WhitespaceTokenizerFactory/
filter class=solr.WordDelimiterFilterFactory
generateWordParts=1
splitOnCaseChange=0
splitOnNumerics=0
stemEnglishPossessive=1
preserveOriginal=0
catenateWords=1
generateNumberParts=1
catenateNumbers=0
catenateAll=0
types=wdfftypes.txt/
filter class=solr.StopFilterFactory
ignoreCase=true
words=lang/stopwords_en.txt
/
filter class=solr.LowerCaseFilterFactory/
filter class=solr.ASCIIFoldingFilterFactory/
filter class=solr.KStemFilterFactory/
/analyzer
/fieldType
The PatternReplaceCharFilterFactory (PRCF) is used to collapse
repeated letters in a term down to a max of 2, such as #yu would
be #yumm
When I run some text through this analyzer using the Analysis form,
the output is as if the resulting text is unavailable to the
tokenizer. In other words, the only results being displayed in the
output on the form is for the PRCF
This example stopped working in 4.7.0 and I've verified it worked
correctly in 4.6.1.
Initially, I thought this might be an issue with the actual analysis,
but the analyzer actually works when indexing / querying. Then,
looking at the JSON response in the Developer console with Chrome, I
see the JSON that comes back includes output for all the components in
my chain (see below) ... so looks like a UI rendering issue to me?
{responseHeader:{status:0,QTime:24},analysis:{field_types:{text_microblog:{index:[org.apache.lucene.analysis.pattern.PatternReplaceCharFilter,#Yumm
:) Drinking a latte at Caffe Grecco in SF's historic North Beach...
Learning text analysis with #SolrInAction by @ManningBooks on my i-Pad
foo5,org.apache.lucene.analysis.core.WhitespaceTokenizer,[{text:#Yumm,raw_bytes:[23
59 75 6d
6d],start:0,end:6,position:1,positionHistory:[1],type:word},{text::),raw_bytes:[3a
29],start:7,end:9,position:2,positionHistory:[2],type:word},{text:Drinking,raw_bytes:[44
72 69 6e 6b 69 6e
67],start:10,end:18,position:3,positionHistory:[3],type:word},{text:a,raw_bytes:[61],start:19,end:20,position:4,positionHistory:[4],type:word},{text:latte,raw_bytes:[6c
...
the JSON returned to the browser has evidence that the full analysis chain
was applied, so this seems to just be a rendering issue.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5800) Admin UI - Analysis form doesn't render results correctly when a CharFilter is used.
[
https://issues.apache.org/jira/browse/SOLR-5800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Matheis (steffkes) updated SOLR-5800:
Fix Version/s: 5.0
4.8
Admin UI - Analysis form doesn't render results correctly when a CharFilter
is used.
Key: SOLR-5800
URL: https://issues.apache.org/jira/browse/SOLR-5800
Project: Solr
Issue Type: Bug
Components: web gui
Affects Versions: 4.7
Reporter: Timothy Potter
Priority: Minor
Fix For: 4.8, 5.0
Attachments: SOLR-5800-sample.json, SOLR-5800.patch
I have an example in Solr In Action that uses the
PatternReplaceCharFilterFactory and now it doesn't work in 4.7.0.
Specifically, the fieldType is:
fieldType name=text_microblog class=solr.TextField
positionIncrementGap=100
analyzer
charFilter class=solr.PatternReplaceCharFilterFactory
pattern=([a-zA-Z])\1+
replacement=$1$1/
tokenizer class=solr.WhitespaceTokenizerFactory/
filter class=solr.WordDelimiterFilterFactory
generateWordParts=1
splitOnCaseChange=0
splitOnNumerics=0
stemEnglishPossessive=1
preserveOriginal=0
catenateWords=1
generateNumberParts=1
catenateNumbers=0
catenateAll=0
types=wdfftypes.txt/
filter class=solr.StopFilterFactory
ignoreCase=true
words=lang/stopwords_en.txt
/
filter class=solr.LowerCaseFilterFactory/
filter class=solr.ASCIIFoldingFilterFactory/
filter class=solr.KStemFilterFactory/
/analyzer
/fieldType
The PatternReplaceCharFilterFactory (PRCF) is used to collapse
repeated letters in a term down to a max of 2, such as #yu would
be #yumm
When I run some text through this analyzer using the Analysis form,
the output is as if the resulting text is unavailable to the
tokenizer. In other words, the only results being displayed in the
output on the form is for the PRCF
This example stopped working in 4.7.0 and I've verified it worked
correctly in 4.6.1.
Initially, I thought this might be an issue with the actual analysis,
but the analyzer actually works when indexing / querying. Then,
looking at the JSON response in the Developer console with Chrome, I
see the JSON that comes back includes output for all the components in
my chain (see below) ... so looks like a UI rendering issue to me?
{responseHeader:{status:0,QTime:24},analysis:{field_types:{text_microblog:{index:[org.apache.lucene.analysis.pattern.PatternReplaceCharFilter,#Yumm
:) Drinking a latte at Caffe Grecco in SF's historic North Beach...
Learning text analysis with #SolrInAction by @ManningBooks on my i-Pad
foo5,org.apache.lucene.analysis.core.WhitespaceTokenizer,[{text:#Yumm,raw_bytes:[23
59 75 6d
6d],start:0,end:6,position:1,positionHistory:[1],type:word},{text::),raw_bytes:[3a
29],start:7,end:9,position:2,positionHistory:[2],type:word},{text:Drinking,raw_bytes:[44
72 69 6e 6b 69 6e
67],start:10,end:18,position:3,positionHistory:[3],type:word},{text:a,raw_bytes:[61],start:19,end:20,position:4,positionHistory:[4],type:word},{text:latte,raw_bytes:[6c
...
the JSON returned to the browser has evidence that the full analysis chain
was applied, so this seems to just be a rendering issue.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-5800) Admin UI - Analysis form doesn't render results correctly when a CharFilter is used.
[
https://issues.apache.org/jira/browse/SOLR-5800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Matheis (steffkes) reassigned SOLR-5800:
---
Assignee: Stefan Matheis (steffkes)
Admin UI - Analysis form doesn't render results correctly when a CharFilter
is used.
Key: SOLR-5800
URL: https://issues.apache.org/jira/browse/SOLR-5800
Project: Solr
Issue Type: Bug
Components: web gui
Affects Versions: 4.7
Reporter: Timothy Potter
Assignee: Stefan Matheis (steffkes)
Priority: Minor
Fix For: 4.8, 5.0
Attachments: SOLR-5800-sample.json, SOLR-5800.patch
I have an example in Solr In Action that uses the
PatternReplaceCharFilterFactory and now it doesn't work in 4.7.0.
Specifically, the fieldType is:
fieldType name=text_microblog class=solr.TextField
positionIncrementGap=100
analyzer
charFilter class=solr.PatternReplaceCharFilterFactory
pattern=([a-zA-Z])\1+
replacement=$1$1/
tokenizer class=solr.WhitespaceTokenizerFactory/
filter class=solr.WordDelimiterFilterFactory
generateWordParts=1
splitOnCaseChange=0
splitOnNumerics=0
stemEnglishPossessive=1
preserveOriginal=0
catenateWords=1
generateNumberParts=1
catenateNumbers=0
catenateAll=0
types=wdfftypes.txt/
filter class=solr.StopFilterFactory
ignoreCase=true
words=lang/stopwords_en.txt
/
filter class=solr.LowerCaseFilterFactory/
filter class=solr.ASCIIFoldingFilterFactory/
filter class=solr.KStemFilterFactory/
/analyzer
/fieldType
The PatternReplaceCharFilterFactory (PRCF) is used to collapse
repeated letters in a term down to a max of 2, such as #yu would
be #yumm
When I run some text through this analyzer using the Analysis form,
the output is as if the resulting text is unavailable to the
tokenizer. In other words, the only results being displayed in the
output on the form is for the PRCF
This example stopped working in 4.7.0 and I've verified it worked
correctly in 4.6.1.
Initially, I thought this might be an issue with the actual analysis,
but the analyzer actually works when indexing / querying. Then,
looking at the JSON response in the Developer console with Chrome, I
see the JSON that comes back includes output for all the components in
my chain (see below) ... so looks like a UI rendering issue to me?
{responseHeader:{status:0,QTime:24},analysis:{field_types:{text_microblog:{index:[org.apache.lucene.analysis.pattern.PatternReplaceCharFilter,#Yumm
:) Drinking a latte at Caffe Grecco in SF's historic North Beach...
Learning text analysis with #SolrInAction by @ManningBooks on my i-Pad
foo5,org.apache.lucene.analysis.core.WhitespaceTokenizer,[{text:#Yumm,raw_bytes:[23
59 75 6d
6d],start:0,end:6,position:1,positionHistory:[1],type:word},{text::),raw_bytes:[3a
29],start:7,end:9,position:2,positionHistory:[2],type:word},{text:Drinking,raw_bytes:[44
72 69 6e 6b 69 6e
67],start:10,end:18,position:3,positionHistory:[3],type:word},{text:a,raw_bytes:[61],start:19,end:20,position:4,positionHistory:[4],type:word},{text:latte,raw_bytes:[6c
...
the JSON returned to the browser has evidence that the full analysis chain
was applied, so this seems to just be a rendering issue.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
