Solr
  1. Solr
  2. SOLR-1163

Solr Explorer - A generic GWT client for Solr

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.3
    • Fix Version/s: None
    • Component/s: web gui
    • Labels:
      None

      Description

      The attached patch is a GWT generic client for solr. It is currently standalone, meaning that once built, one can open the generated HTML file in a browser and communicate with any deployed solr. It is configured with it's own configuration file, where one can configure the solr instance/core to connect to. Since it's currently standalone and completely client side based, it uses JSON with padding (cross-side scripting) to connect to remote solr servers. Some of the supported features:

      • Simple query search
      • Sorting - one can dynamically define new sort criterias
      • Search results are rendered very much like Google search results are rendered. It is also possible to view all stored field values for every hit.
      • Custom hit rendering - It is possible to show thumbnails (images) per hit and also customize a view for a hit based on html templates
      • Faceting - one can dynamically define field and query facets via the UI. it is also possible to pre-configure these facets in the configuration file.
      • Highlighting - you can dynamically configure highlighting. it can also be pre-configured in the configuration file
      • Spellchecking - you can dynamically configure spell checking. Can also be done in the configuration file. Supports collation. It is also possible to send "build" and "reload" commands.
      • Data import handler - if used, it is possible to send a "full-import" and "status" command ("delta-import" is not implemented yet, but it's easy to add)
      • Console - For development time, there's a small console which can help to better understand what's going on behind the scenes. One can use it to:
        • view the client logs
        • browse the solr scheme
        • View a break down of the current search context
        • View a break down of the query URL that is sent to solr
        • View the raw JSON response returning from Solr

      This client is actually a platform that can be greatly extended for more things. The goal is to have a client where the explorer part is just one view of it. Other future views include: Monitoring, Administration, Query Builder, DataImportHandler configuration, and more...

      To get a better view of what's currently possible. We've set up a public version of this client at: http://search.jteam.nl/explorer. This client is configured with one solr instance where crawled YouTube movies where indexed. You can also check out a screencast for this deployed client: http://search.jteam.nl/help

      The patch created a new folder in the contrib. directory. Since the patch doesn't contain binaries, an additional zip file is provides that needs to be extract to add all the required graphics. This module is maven2 based and is configured in such a way that all GWT related tools/libraries are automatically downloaded when the modules is compiled. One of the artifacts of the build is a war file which can be deployed in any servlet container.

      NOTE: this client works best on WebKit based browsers (for performance reason) but also works on firefox and ie 7+. That said, it should be taken into account that it is still under development.

      1. SOLR-1163.zip
        1.58 MB
        Uri Boness
      2. SOLR-1163.zip
        2.91 MB
        Uri Boness
      3. solr-explorer.patch
        605 kB
        Uri Boness
      4. graphics.zip
        66 kB
        Uri Boness
      5. solr-explorer.patch
        605 kB
        Uri Boness

        Activity

        Hide
        Jan Høydahl added a comment -

        Long time since any activity. For those interested, we have put up a recent version of the explorer on GitHub:
        https://github.com/cominvent/solr-explorer

        Show
        Jan Høydahl added a comment - Long time since any activity. For those interested, we have put up a recent version of the explorer on GitHub: https://github.com/cominvent/solr-explorer
        Hide
        Lance Norskog added a comment - - edited

        Any plans to continue with this? If not, check out Vaadin. It's a UI widget toolkit layer on GWT, with an Eclipse UI builder.

        Show
        Lance Norskog added a comment - - edited Any plans to continue with this? If not, check out Vaadin . It's a UI widget toolkit layer on GWT, with an Eclipse UI builder.
        Hide
        Lance Norskog added a comment -

        A deployment suggestion: since the solr-explorer.xml file has to be in the war file, please add an ant rule that takes a file name (from the command line or property) and places that into the war as /solr-explorer.xml ? This would make it easy to make different war files for different projects.

        Show
        Lance Norskog added a comment - A deployment suggestion: since the solr-explorer.xml file has to be in the war file, please add an ant rule that takes a file name (from the command line or property) and places that into the war as /solr-explorer.xml ? This would make it easy to make different war files for different projects.
        Hide
        Uri Boness added a comment -

        @Peter

        Try removing the trailing slash in the URL (I know.... in the next version I'll make sure to handle these edge cases)

        @Lance
        Indeed the limitation of the current version is that it uses XSS for the communication with Solr. This limits it to GET methods. In the upcoming release, since a server side layer is added, this will be solved and all communication will be done using POST via a proxy servlet.

        The next version is basically ready... the only thing that I still have to fix are some UI issues with IE and a few with Chrome.

        Show
        Uri Boness added a comment - @Peter Try removing the trailing slash in the URL (I know.... in the next version I'll make sure to handle these edge cases) @Lance Indeed the limitation of the current version is that it uses XSS for the communication with Solr. This limits it to GET methods. In the upcoming release, since a server side layer is added, this will be solved and all communication will be done using POST via a proxy servlet. The next version is basically ready... the only thing that I still have to fix are some UI issues with IE and a few with Chrome.
        Hide
        Peter Sturge added a comment -

        Hi Uri,

        The configuration for url connections in

        {solr-explorer.xml}

        looks pretty straightforward. For the example instance, there is no 'named' core, so I used an empty string here.
        For my own core, I used the name ('active'), and the URLs work fine when put straight into a browser:

        So, this works:

        { http://localhost:8983/solr/active/select/?&q=*:*&wt=json&indent=on}

        But this gives the JSON timeout error:

        solr-explorer.xml [excerpt]
            <solr-core name="active">
        
                <server baseUrl="http://localhost:8983/solr/"/>
        
                <search>
                    <default-query>*:*</default-query>
                </search>
        
                <hit-rendering>
                    <title-field default="[unknown]">name</title-field>
                    <summary-field default="No special features">features</summary-field>
                </hit-rendering>
            </solr-core>
        

        (in FireFox 3.6)

        Thanks,
        Peter

        Show
        Peter Sturge added a comment - Hi Uri, The configuration for url connections in {solr-explorer.xml} looks pretty straightforward. For the example instance, there is no 'named' core, so I used an empty string here. For my own core, I used the name ('active'), and the URLs work fine when put straight into a browser: So, this works: { http://localhost:8983/solr/active/select/?&q=*:*&wt=json&indent=on} But this gives the JSON timeout error: solr-explorer.xml [excerpt] <solr-core name= "active" > <server baseUrl= "http: //localhost:8983/solr/" /> <search> < default -query>*:*</ default -query> </search> <hit-rendering> <title-field default = "[unknown]" >name</title-field> <summary-field default = "No special features" >features</summary-field> </hit-rendering> </solr-core> (in FireFox 3.6) Thanks, Peter
        Hide
        Lance Norskog added a comment -

        That works great.

        Another problem I've encountered is that I'm making facets that are 2000-3000 characters long. This does not work with a GET, so it needs a POST.
        Of course, this is not a common use case.

        Show
        Lance Norskog added a comment - That works great. Another problem I've encountered is that I'm making facets that are 2000-3000 characters long. This does not work with a GET, so it needs a POST. Of course, this is not a common use case.
        Hide
        Uri Boness added a comment -

        Hi Peter,

        The explorer communicates with Solr via http request json calls. In the current version there's a 5 seconds timeout on this connection attempt (this will change to be configurable in the upcoming version). Since you're using the example directory and the index is small, assuming you're running on localhost, the only reason I can think of for this timeout is simple bad configuration. The solr-explorer.xml defines the core and the base solr URL to connect to it... make sure this URL is indeed correct.

        Logging is current available, but not at connection time. Once you're logged in, solr explorer has a "firebug-like" console with a logging tab (which gives you an insight at what's going on).

        Cheers,
        Uri

        Show
        Uri Boness added a comment - Hi Peter, The explorer communicates with Solr via http request json calls. In the current version there's a 5 seconds timeout on this connection attempt (this will change to be configurable in the upcoming version). Since you're using the example directory and the index is small, assuming you're running on localhost, the only reason I can think of for this timeout is simple bad configuration. The solr-explorer.xml defines the core and the base solr URL to connect to it... make sure this URL is indeed correct. Logging is current available, but not at connection time. Once you're logged in, solr explorer has a "firebug-like" console with a logging tab (which gives you an insight at what's going on). Cheers, Uri
        Hide
        Peter Sturge added a comment -

        Hi Uri,

        Really like what you've done here. +1 +vote!

        I've had a go on your demo site and that looks cool.

        When I download and try to connect to a core (I've tried my own core, and the Solr 'example'), I always get:

        'Could not load solr core ('corename'): The JSON request failed or timed out'

        If I turn on Firebug, the only msg I get is this:

        reference to undefined property window[c + x$]
        [Break on this error] function DKd(h,d,e,b,f){var c=gM+CKd++;i...)}},5000);document.body.appendChild(g)}\n

        There doesn't seem to be any log/debug of what the problem might be. Are there any logging options that can be enabled?

        Many thanks,
        Peter

        Show
        Peter Sturge added a comment - Hi Uri, Really like what you've done here. +1 +vote! I've had a go on your demo site and that looks cool. When I download and try to connect to a core (I've tried my own core, and the Solr 'example'), I always get: 'Could not load solr core ('corename'): The JSON request failed or timed out' If I turn on Firebug, the only msg I get is this: reference to undefined property window [c + x$] [Break on this error] function DKd(h,d,e,b,f){var c=gM+CKd++;i...)}},5000);document.body.appendChild(g)}\n There doesn't seem to be any log/debug of what the problem might be. Are there any logging options that can be enabled? Many thanks, Peter
        Hide
        Lance Norskog added a comment -

        No, that's fine, I'll try it!

        Show
        Lance Norskog added a comment - No, that's fine, I'll try it!
        Hide
        David Smiley added a comment -

        Uri, you're comment about the downside of developing something based on JIRA patches is so true. I realize this is a bit of a tangent, but I think a git w/ github model could bring about more velocity on Solr improvement. Unfortunately the interest among Solr committers appears to be anemic.

        Show
        David Smiley added a comment - Uri, you're comment about the downside of developing something based on JIRA patches is so true. I realize this is a bit of a tangent, but I think a git w/ github model could bring about more velocity on Solr improvement. Unfortunately the interest among Solr committers appears to be anemic.
        Hide
        Uri Boness added a comment -

        @Lance

        Oh... right... indeed that's a bug . Since I don't want to add another patch for this version, perhaps you can fix it yourself and rebuild it (now with the ant build it should be easier). to fix it, simply look at the org.apache.solr.explorer.client.manager.solr.search.SolrQueryBuilder, line: 232... the method escapeLuceneQuery... change the following line:

        .replace("[", "\\]")
        

        to

        .replace("]", "\\]")
        

        Sorry for pushing this bug fix on you.... I just want to focus on the next version release and continue all bug fixes on that one. does this make sense? Or should I upload another patch for it?

        Show
        Uri Boness added a comment - @Lance Oh... right... indeed that's a bug . Since I don't want to add another patch for this version, perhaps you can fix it yourself and rebuild it (now with the ant build it should be easier). to fix it, simply look at the org.apache.solr.explorer.client.manager.solr.search.SolrQueryBuilder , line: 232... the method escapeLuceneQuery ... change the following line: .replace( "[" , "\\]" ) to .replace( "]" , "\\]" ) Sorry for pushing this bug fix on you.... I just want to focus on the next version release and continue all bug fixes on that one. does this make sense? Or should I upload another patch for it?
        Hide
        Lance Norskog added a comment -

        .bq In the new version this will be configured per core & request type
        Great! I'm used to large indexes and have done facet queries that took half an hour

        .bq What is the problem exactly with the facet filters? they are not escaped or are they escaped incorrectly?
        The query name_s: with leftbracket followed by stuff
        became name_s: backslash-backslash-rightbracket followed by stuff

        The leftbracket got changed to right-bracket and got 2 escapes. As an old Unix coder, I know all about extra escapes. But switching the left-bracket to a right-bracket is a more strange bug.

        Show
        Lance Norskog added a comment - .bq In the new version this will be configured per core & request type Great! I'm used to large indexes and have done facet queries that took half an hour .bq What is the problem exactly with the facet filters? they are not escaped or are they escaped incorrectly? The query name_s: with leftbracket followed by stuff became name_s: backslash-backslash-rightbracket followed by stuff The leftbracket got changed to right-bracket and got 2 escapes. As an old Unix coder, I know all about extra escapes. But switching the left-bracket to a right-bracket is a more strange bug.
        Hide
        Uri Boness added a comment -

        @Lance
        there was always a timeout in solr explorer which is set to 5 seconds. In the new version this will be configured per core & request type (for example, building a spellcheck index differs in the time takes between different cores and configurations)
        What is the problem exactly with the facet filters? they are not escaped or are they escaped incorrectly? Currently, (as noted below) I'm not using the _

        {!raw f=X}

        value_ query but escape the query explicitly.

        @Erik
        Yes, I know... this version of the explorer is still from the 1.3 release days so I need to update it to use the query parser functionality.

        I don't want to spend too much time on this version, and soon I'll put a new version in which I'll apply all changes and bug fixes (that's the downside of developing something based on JIRA patches). To speed up things, I'll put aside the whole server side support for dynamic configuration and first issue a release of the new version that works with xml configuration (as it works now). One thing to take into consideration is that the new xml configuration is somewhat not BWC as it also reflects the change in the explorer architecture.

        Show
        Uri Boness added a comment - @Lance there was always a timeout in solr explorer which is set to 5 seconds. In the new version this will be configured per core & request type (for example, building a spellcheck index differs in the time takes between different cores and configurations) What is the problem exactly with the facet filters? they are not escaped or are they escaped incorrectly? Currently, (as noted below) I'm not using the _ {!raw f=X} value_ query but escape the query explicitly. @Erik Yes, I know... this version of the explorer is still from the 1.3 release days so I need to update it to use the query parser functionality. I don't want to spend too much time on this version, and soon I'll put a new version in which I'll apply all changes and bug fixes (that's the downside of developing something based on JIRA patches). To speed up things, I'll put aside the whole server side support for dynamic configuration and first issue a release of the new version that works with xml configuration (as it works now). One thing to take into consideration is that the new xml configuration is somewhat not BWC as it also reflects the change in the explorer architecture.
        Hide
        Erik Hatcher added a comment -

        For drilling into facets using fq, the queries really should be in the form of fq=

        {!raw f=field_name}

        value to avoid query parser escaping/quoting issues.

        Show
        Erik Hatcher added a comment - For drilling into facets using fq, the queries really should be in the form of fq= {!raw f=field_name} value to avoid query parser escaping/quoting issues.
        Hide
        Lance Norskog added a comment -

        Thank you! Editing works great.

        Is there a new timeout feature? I'm getting timeouts loading large cores.

        There is a slight problem in searching for facet values. I'm indexing logs, so my facets have weird names.
        This facet from field 'name_s':
        [http-8080-Processor8]

        created this search (which I cannot figure out how embed in the wiki):
        name_s: \ \ ]http\ -8080\ -Processor8]
        Pretend that the previous line has no spaces, and that is what Explorer sent in as the facet query. It should be backslash-leftbracket, not backslash-backslash-rightbracket. And the final rightbracket should probably be escaped also?

        Show
        Lance Norskog added a comment - Thank you! Editing works great. Is there a new timeout feature? I'm getting timeouts loading large cores. There is a slight problem in searching for facet values. I'm indexing logs, so my facets have weird names. This facet from field 'name_s': [http-8080-Processor8] created this search (which I cannot figure out how embed in the wiki): name_s: \ \ ]http\ -8080\ -Processor8] Pretend that the previous line has no spaces, and that is what Explorer sent in as the facet query. It should be backslash-leftbracket, not backslash-backslash-rightbracket. And the final rightbracket should probably be escaped also?
        Uri Boness made changes -
        Attachment SOLR-1163.zip [ 12443793 ]
        Hide
        Uri Boness added a comment -

        Fixed the issues where editing a query/field facet fails.

        Show
        Uri Boness added a comment - Fixed the issues where editing a query/field facet fails.
        Hide
        Uri Boness added a comment -

        Ok, I see the problem. If there is any way to make this more flexible? For example, a list of places to look?

        Can you give an example of where you'd like to look for the config files? Do you mean you want to have multiple files in different locations and merge them, or just define possible locations and the first solr-explorer.xml that is found in one of the location is loaded.

        Yes. Most multicore sites use the same schema etc. for all of their cores, so a default template would be very useful.

        I understand this need.. makes sense. I can add it to the todo list for later on. There are quite a lot of other features to implement which relate to the configuration and they have higher priority (get rid of the xml configuration for example). Once we have a solid configuration mechanism we can then add this feature as well.

        Creating facets works. I edited an existing facet with the left-button pulldown. I changed the query. When I saved it, I got this popup error:

        A bug indeed. I'll soon add a new version with a fix to this (it appears that the same bug occurs for the field facets as well)

        Show
        Uri Boness added a comment - Ok, I see the problem. If there is any way to make this more flexible? For example, a list of places to look? Can you give an example of where you'd like to look for the config files? Do you mean you want to have multiple files in different locations and merge them, or just define possible locations and the first solr-explorer.xml that is found in one of the location is loaded. Yes. Most multicore sites use the same schema etc. for all of their cores, so a default template would be very useful. I understand this need.. makes sense. I can add it to the todo list for later on. There are quite a lot of other features to implement which relate to the configuration and they have higher priority (get rid of the xml configuration for example). Once we have a solid configuration mechanism we can then add this feature as well. Creating facets works. I edited an existing facet with the left-button pulldown. I changed the query. When I saved it, I got this popup error: A bug indeed. I'll soon add a new version with a fix to this (it appears that the same bug occurs for the field facets as well)
        Hide
        Lance Norskog added a comment - - edited

        The solr-explorer.xml is configured in the host html file SolrExplorer.html as a gwtoolbox:property <meta> tag. Currently the value needs to be relative to SolrExplorer.html, though I'm planning to make it more flexible so when deploying on a web server it'd be possible to put it anywhere on that server (it will not be possible to load it from external server due to XSS limitations).

        Ok, I see the problem. If there is any way to make this more flexible? For example, a list of places to look?

        As I understand, you basically want to be able to define default config template which you can base your specific configurations on. Did I get it right?

        Yes. Most multicore sites use the same schema etc. for all of their cores, so a default template would be very useful.

        Can you elaborate on this one... I didn't experience problems when defining query facets. How do you define them? Can you give an example of a facet that failed?

        Creating facets works. I edited an existing facet with the left-button pulldown. I changed the query. When I saved it, I got this popup error:

        Error occured: (TypeError): h is undefined
         stack: hLb([object Object],[object Object],[object Object])@http://localhost:9963/solr-explorer/explorer/558095973C1D0840259C75524EE8A354.cache.html:4251
        $Kb([object Object],[object Object])@http://localhost:9963/solr-explorer/explorer/558095973C1D0840259C75524EE8A354.cache.html:2487
        ([object Object])@http://localhost:9963/solr-explorer/explorer/558095973C1D0840259C75524EE8A354.cache.html:4293
        @http://localhost:9963/solr/errors/select?version=2.2&q=*:*&start=0&facet=on&facet.query=stamp_dt:%5B*%20TO%20*%5D&wt=json&indent=true&json.wrf=callback7:104
         fileName: http://localhost:9963/solr-explorer/explorer/558095973C1D0840259C75524EE8A354.cache.html
         lineNumber: 4251
        
        Show
        Lance Norskog added a comment - - edited The solr-explorer.xml is configured in the host html file SolrExplorer.html as a gwtoolbox:property <meta> tag. Currently the value needs to be relative to SolrExplorer.html, though I'm planning to make it more flexible so when deploying on a web server it'd be possible to put it anywhere on that server (it will not be possible to load it from external server due to XSS limitations). Ok, I see the problem. If there is any way to make this more flexible? For example, a list of places to look? As I understand, you basically want to be able to define default config template which you can base your specific configurations on. Did I get it right? Yes. Most multicore sites use the same schema etc. for all of their cores, so a default template would be very useful. Can you elaborate on this one... I didn't experience problems when defining query facets. How do you define them? Can you give an example of a facet that failed? Creating facets works. I edited an existing facet with the left-button pulldown. I changed the query. When I saved it, I got this popup error: Error occured: (TypeError): h is undefined stack: hLb([object Object],[object Object],[object Object])@http://localhost:9963/solr-explorer/explorer/558095973C1D0840259C75524EE8A354.cache.html:4251 $Kb([object Object],[object Object])@http://localhost:9963/solr-explorer/explorer/558095973C1D0840259C75524EE8A354.cache.html:2487 ([object Object])@http://localhost:9963/solr-explorer/explorer/558095973C1D0840259C75524EE8A354.cache.html:4293 @http://localhost:9963/solr/errors/select?version=2.2&q=*:*&start=0&facet=on&facet.query=stamp_dt:%5B*%20TO%20*%5D&wt=json&indent=true&json.wrf=callback7:104 fileName: http://localhost:9963/solr-explorer/explorer/558095973C1D0840259C75524EE8A354.cache.html lineNumber: 4251
        Hide
        Uri Boness added a comment -

        Hi Lance,

        How do you set the directory for solr-explorer.xml file?

        The solr-explorer.xml is configured in the host html file SolrExplorer.html as a gwtoolbox:property <meta> tag. Currently the value needs to be relative to SolrExplorer.html, though I'm planning to make it more flexible so when deploying on a web server it'd be possible to put it anywhere on that server (it will not be possible to load it from external server due to XSS limitations).

        Also, an improvement: for multicore, one common configuration for many cores would help And some default core, or name wildcarding.

        As I understand, you basically want to be able to define default config template which you can base your specific configurations on. Did I get it right?

        Also, it still has the bug in editing query facets

        Can you elaborate on this one... I didn't experience problems when defining query facets. How do you define them? Can you give an example of a facet that failed?

        Show
        Uri Boness added a comment - Hi Lance, How do you set the directory for solr-explorer.xml file? The solr-explorer.xml is configured in the host html file SolrExplorer.html as a gwtoolbox:property <meta> tag. Currently the value needs to be relative to SolrExplorer.html, though I'm planning to make it more flexible so when deploying on a web server it'd be possible to put it anywhere on that server (it will not be possible to load it from external server due to XSS limitations). Also, an improvement: for multicore, one common configuration for many cores would help And some default core, or name wildcarding. As I understand, you basically want to be able to define default config template which you can base your specific configurations on. Did I get it right? Also, it still has the bug in editing query facets Can you elaborate on this one... I didn't experience problems when defining query facets. How do you define them? Can you give an example of a facet that failed?
        Hide
        Lance Norskog added a comment -

        Thanks!

        How do you set the directory for solr-explorer.xml file?

        Also, an improvement: for multicore, one common configuration for many cores would help And some default core, or name wildcarding.

        Also, it still has the bug in editing query facets

        Show
        Lance Norskog added a comment - Thanks! How do you set the directory for solr-explorer.xml file? Also, an improvement: for multicore, one common configuration for many cores would help And some default core, or name wildcarding. Also, it still has the bug in editing query facets
        Uri Boness made changes -
        Attachment SOLR-1163.zip [ 12443375 ]
        Hide
        Uri Boness added a comment -

        A flavor of the current version with the following changes:

        1. Ant script instead of maven pom
        2. Jar dependencies are included
        3. Upgraded GWT to 2.0.3
        4. Upgraded GWToolbox to 2.0.0-SNAPSHOT

        A few notes:

        • Attaching as zip instead of a patch as there are quite a few binary files (jars and graphics). The content can be dropped anywhere and built (so it does not depend on solr per se).
        • To keep the zip file somewhat small in size, I didn't include the GWT libraries in it. When running the build for the first time, it will try to download the gwt libs from maven central repository. This will only be done once... the libs will not be downloaded if they already exist in the lib folder
        • two main ant targets:
          • build - will clean and rebuild the application. The process places its artifacts under target folder
          • dist - will build and create distributable artifact of the application under the dist folder. There are two artifact there - a standalone version (just open the SolrExplorer.html file in the browser) and a war file.
        Show
        Uri Boness added a comment - A flavor of the current version with the following changes: 1. Ant script instead of maven pom 2. Jar dependencies are included 3. Upgraded GWT to 2.0.3 4. Upgraded GWToolbox to 2.0.0-SNAPSHOT A few notes: Attaching as zip instead of a patch as there are quite a few binary files (jars and graphics). The content can be dropped anywhere and built (so it does not depend on solr per se). To keep the zip file somewhat small in size, I didn't include the GWT libraries in it. When running the build for the first time, it will try to download the gwt libs from maven central repository. This will only be done once... the libs will not be downloaded if they already exist in the lib folder two main ant targets: build - will clean and rebuild the application. The process places its artifacts under target folder dist - will build and create distributable artifact of the application under the dist folder. There are two artifact there - a standalone version (just open the SolrExplorer.html file in the browser) and a war file.
        Hide
        Lance Norskog added a comment -

        what I'll do, is take the current patch and move it to ant and make it workable (though it is going to change quite a lot in the next version)

        +1! It's a really handy tool as-is. The best is the enemy of the good.

        Show
        Lance Norskog added a comment - what I'll do, is take the current patch and move it to ant and make it workable (though it is going to change quite a lot in the next version) +1! It's a really handy tool as-is. The best is the enemy of the good.
        Hide
        Uri Boness added a comment -

        yeah... our repository has changed and some libs are missing in the new one.

        Thing is, the current patch version is quite out dated and the new version it will also have completely different dependencies.

        what I'll do, is take the current patch and move it to ant and make it workable (though it is going to change quite a lot in the next version)

        Show
        Uri Boness added a comment - yeah... our repository has changed and some libs are missing in the new one. Thing is, the current patch version is quite out dated and the new version it will also have completely different dependencies. what I'll do, is take the current patch and move it to ant and make it workable (though it is going to change quite a lot in the next version)
        Hide
        Grant Ingersoll added a comment -

        1) org.gwtoolbox:gwtoolbox-ioc-core:jar:0.6.1

        Try downloading the file manually from the project website.

        Then, install it using the command:
        mvn install:install-file -DgroupId=org.gwtoolbox -DartifactId=gwtoolbox-ioc-core -Dversion=0.6.1 -Dpackaging=jar -Dfile=/path/to/file

        Alternatively, if you host your own repository you can deploy the file there:
        mvn deploy:deploy-file -DgroupId=org.gwtoolbox -DartifactId=gwtoolbox-ioc-core -Dversion=0.6.1 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

        Path to dependency:
        1) org.apache.solr:solr-explorer:war:1.0-SNAPSHOT
        2) org.gwtoolbox:gwtoolbox-ioc-core:jar:0.6.1

        2) org.gwtoolbox:gwtoolbox-widget:jar:0.4.1

        Try downloading the file manually from the project website.

        Then, install it using the command:
        mvn install:install-file -DgroupId=org.gwtoolbox -DartifactId=gwtoolbox-widget -Dversion=0.4.1 -Dpackaging=jar -Dfile=/path/to/file

        Alternatively, if you host your own repository you can deploy the file there:
        mvn deploy:deploy-file -DgroupId=org.gwtoolbox -DartifactId=gwtoolbox-widget -Dversion=0.4.1 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

        Path to dependency:
        1) org.apache.solr:solr-explorer:war:1.0-SNAPSHOT
        2) org.gwtoolbox:gwtoolbox-widget:jar:0.4.1

        Looks like it isn't finding the JTeam repo properly. Anyone else having that problem?

        Show
        Grant Ingersoll added a comment - 1) org.gwtoolbox:gwtoolbox-ioc-core:jar:0.6.1 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.gwtoolbox -DartifactId=gwtoolbox-ioc-core -Dversion=0.6.1 -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.gwtoolbox -DartifactId=gwtoolbox-ioc-core -Dversion=0.6.1 -Dpackaging=jar -Dfile=/path/to/file -Durl= [url] -DrepositoryId= [id] Path to dependency: 1) org.apache.solr:solr-explorer:war:1.0-SNAPSHOT 2) org.gwtoolbox:gwtoolbox-ioc-core:jar:0.6.1 2) org.gwtoolbox:gwtoolbox-widget:jar:0.4.1 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.gwtoolbox -DartifactId=gwtoolbox-widget -Dversion=0.4.1 -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.gwtoolbox -DartifactId=gwtoolbox-widget -Dversion=0.4.1 -Dpackaging=jar -Dfile=/path/to/file -Durl= [url] -DrepositoryId= [id] Path to dependency: 1) org.apache.solr:solr-explorer:war:1.0-SNAPSHOT 2) org.gwtoolbox:gwtoolbox-widget:jar:0.4.1 Looks like it isn't finding the JTeam repo properly. Anyone else having that problem?
        Hide
        Uri Boness added a comment -

        So, how hard would it be to get this in Ant instead of Maven? I don't see Solr converting to Maven anytime soon and I certainly am against 2 build systems.

        Figured this one out already, the new version will solely be based on Ant

        As for the dependencies, the two main dependencies are indeed GWT and GWToolbox. Spring is not really a must as I can use pure Servlets for the backend. That said, integrating with Spring as the backend might still be an option just to simplify things... but I still need to figure whether we really need it or we can just do without it.

        Show
        Uri Boness added a comment - So, how hard would it be to get this in Ant instead of Maven? I don't see Solr converting to Maven anytime soon and I certainly am against 2 build systems. Figured this one out already, the new version will solely be based on Ant As for the dependencies, the two main dependencies are indeed GWT and GWToolbox. Spring is not really a must as I can use pure Servlets for the backend. That said, integrating with Spring as the backend might still be an option just to simplify things... but I still need to figure whether we really need it or we can just do without it.
        Hide
        Grant Ingersoll added a comment -

        So, how hard would it be to get this in Ant instead of Maven? I don't see Solr converting to Maven anytime soon and I certainly am against 2 build systems.

        Also, dependency-wise, I see:
        GWT
        GWToolbox – which has dependencies on Spring. So, now we're effectively adding GWT and Spring into this Solr contrib, right? Not against it, just want it to know for sure what we are getting into.

        Show
        Grant Ingersoll added a comment - So, how hard would it be to get this in Ant instead of Maven? I don't see Solr converting to Maven anytime soon and I certainly am against 2 build systems. Also, dependency-wise, I see: GWT GWToolbox – which has dependencies on Spring. So, now we're effectively adding GWT and Spring into this Solr contrib, right? Not against it, just want it to know for sure what we are getting into.
        Hide
        Uri Boness added a comment -

        Right... ok... so I think a separate war is definitely the preferred way by all. And yes, putting it in contrib and integrating it with the embedded Jetty of the examples would be ideal.

        So a decision is made

        Thanks guys, for helping me get there.

        Show
        Uri Boness added a comment - Right... ok... so I think a separate war is definitely the preferred way by all. And yes, putting it in contrib and integrating it with the embedded Jetty of the examples would be ideal. So a decision is made Thanks guys, for helping me get there.
        Hide
        Erik Hatcher added a comment -

        even with a separate WAR, we can still have this built into Solr's example webapps directory so only a single Jetty is needed and Solr Explorer works out of the box with a single Jetty.

        Show
        Erik Hatcher added a comment - even with a separate WAR, we can still have this built into Solr's example webapps directory so only a single Jetty is needed and Solr Explorer works out of the box with a single Jetty.
        Hide
        Hoss Man added a comment -

        I vote for a separate war: primarily because i think it would be a good way to encourage/force us to make sure that all the functionality needed to power a good GUI is exposed via RequestHandlers, (wheich will help make it easy for other people to write their own custom tools for controlling solr in non-standartd ways).

        If it lives in the same war, it's too easy to just directly access "public" Java level APIs that don't have an HTTP corollary.

        That said: i don't see any downside to it being a "contrib" living right in the solr code base.

        Show
        Hoss Man added a comment - I vote for a separate war: primarily because i think it would be a good way to encourage/force us to make sure that all the functionality needed to power a good GUI is exposed via RequestHandlers, (wheich will help make it easy for other people to write their own custom tools for controlling solr in non-standartd ways). If it lives in the same war, it's too easy to just directly access "public" Java level APIs that don't have an HTTP corollary. That said: i don't see any downside to it being a "contrib" living right in the solr code base.
        Hide
        Uri Boness added a comment -

        The only downside to this is that it requires extra setup. A lot of people (incl. myself) like to use the bundled jetty instance for development and only deploy solr in a different servlet container in production. In that sense, it would be nice to get something ready out of the box with solr distribution (or at least that it would be easy to set it up with the examples directory).

        Show
        Uri Boness added a comment - The only downside to this is that it requires extra setup. A lot of people (incl. myself) like to use the bundled jetty instance for development and only deploy solr in a different servlet container in production. In that sense, it would be nice to get something ready out of the box with solr distribution (or at least that it would be easy to set it up with the examples directory).
        Hide
        Lance Norskog added a comment -

        +1 on a separate war file. Solr Explorer is a large standalone piece that does not need to be in lockstep with the Solr/Lucene internals.

        This is a great candidate for a separate "Solr Apps Project": something hosted on SourceForge/Google/Github with large standalone projects like clustering, Tika, archiving logs as a web service, archiving IM sessions via Jabber, etc. It would be a better home that Solr JIRA patches.

        Show
        Lance Norskog added a comment - +1 on a separate war file. Solr Explorer is a large standalone piece that does not need to be in lockstep with the Solr/Lucene internals. This is a great candidate for a separate "Solr Apps Project": something hosted on SourceForge/Google/Github with large standalone projects like clustering, Tika, archiving logs as a web service, archiving IM sessions via Jabber, etc. It would be a better home that Solr JIRA patches.
        Hide
        Uri Boness added a comment -

        yeah... I'm leaning toward that option as well. First, it's less intrusive, but also, using a proxy servlet I won't need to use XSS for the communication (which opens up all the XML-only api for me).

        Show
        Uri Boness added a comment - yeah... I'm leaning toward that option as well. First, it's less intrusive, but also, using a proxy servlet I won't need to use XSS for the communication (which opens up all the XML-only api for me).
        Hide
        Erik Hatcher added a comment -

        I vote for separate .war that can be installed with or without Solr in the same container.

        Show
        Erik Hatcher added a comment - I vote for separate .war that can be installed with or without Solr in the same container.
        Hide
        Uri Boness added a comment -

        working on a new improved patch for the explorer. But I'm at a bit of a dilemma here regarding exactly it should integrate with Solr. There are basically 3 options:

        1. Tight integration, where the explorer will be bound to each core and there will be a dedicated URL for it (say /corename/explorer). This is nice as the user gets this functionality out of the box, but on the other hand, I'm not sure users want it to be there out of the box (most of the time, if not always, the explorer will not be used as the final UI, but more of a temporary one, just to have something up and running... in production I can imagine users will not need it). This tight integration also means quite a lot of changes to the current configuration, well, first the dispatch filter will need to change a bit, but also a default request handler will need to be defined for all cores.

        2. The other option is to keep the explorer as an external tool. The idea is to have it as a separate war file which can be deployed in the same servlet container as solr. I'm working on removing the current xml configuration and make it more dynamic. So when the user enters the application, she can configure a core by following a wizard-like process... this wizard will create a configuration which will be saved on the server for future "logins".

        3. Well, the third option is just to leave things as they are now. That is, there is on configuration file which defines all the solr cores the explorer can communicate with. This configuration file is loaded when the web page is loaded. Like option 2, this is also a standalone mode.

        any comments?

        Show
        Uri Boness added a comment - working on a new improved patch for the explorer. But I'm at a bit of a dilemma here regarding exactly it should integrate with Solr. There are basically 3 options: 1. Tight integration, where the explorer will be bound to each core and there will be a dedicated URL for it (say /corename/explorer). This is nice as the user gets this functionality out of the box, but on the other hand, I'm not sure users want it to be there out of the box (most of the time, if not always, the explorer will not be used as the final UI, but more of a temporary one, just to have something up and running... in production I can imagine users will not need it). This tight integration also means quite a lot of changes to the current configuration, well, first the dispatch filter will need to change a bit, but also a default request handler will need to be defined for all cores. 2. The other option is to keep the explorer as an external tool. The idea is to have it as a separate war file which can be deployed in the same servlet container as solr. I'm working on removing the current xml configuration and make it more dynamic. So when the user enters the application, she can configure a core by following a wizard-like process... this wizard will create a configuration which will be saved on the server for future "logins". 3. Well, the third option is just to leave things as they are now. That is, there is on configuration file which defines all the solr cores the explorer can communicate with. This configuration file is loaded when the web page is loaded. Like option 2, this is also a standalone mode. any comments?
        Hide
        Uri Boness added a comment -

        Actually I've been working on a new version for the explorer which I plan to put soon as a patch here.

        Show
        Uri Boness added a comment - Actually I've been working on a new version for the explorer which I plan to put soon as a patch here.
        Hide
        Grant Ingersoll added a comment - - edited

        Uri,

        Is this patch still up to date?

        Show
        Grant Ingersoll added a comment - - edited Uri, Is this patch still up to date?
        Hide
        Uri Boness added a comment -

        Hi Lance,

        Great feedback, thanks!

        You did not mention the console button at the lower right corner. This is very very useful!

        (well, you always have to leave some room for surprises )

        Obviously the two issues are bugs. I'll try to find some time this week to fix them and upload a new patch.

        Cheers,
        Uri

        Show
        Uri Boness added a comment - Hi Lance, Great feedback, thanks! You did not mention the console button at the lower right corner. This is very very useful! (well, you always have to leave some room for surprises ) Obviously the two issues are bugs. I'll try to find some time this week to fix them and upload a new patch. Cheers, Uri
        Hide
        Lance Norskog added a comment -

        Also, spellcheck build gets an error in the Solr servlet. It needs a query string; what for, I don't know.

        INFO: [] webapp=/solr path=/select params={spellcheck=true&json.wrf=callback21&i
        ndent=true&start=0&q=&wt=json&spellcheck.build=true} status=500 QTime=23
        Aug 31, 2009 5:00:05 PM org.apache.solr.common.SolrException log
        SEVERE: java.lang.NullPointerException
                at java.io.StringReader.<init>(StringReader.java:33)
                at org.apache.lucene.queryParser.QueryParser.parse(QueryParser.java:173)
        
                at org.apache.solr.search.LuceneQParser.parse(LuceneQParserPlugin.java:7
        8)
                at org.apache.solr.search.QParser.getQuery(QParser.java:131)
                at org.apache.solr.handler.component.QueryComponent.prepare(QueryCompone
        nt.java:89)
                at org.apache.solr.handler.component.SearchHandler.handleRequestBody(Sea
        rchHandler.java:174)
                at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandl
        erBase.java:131)
                at org.apache.solr.core.SolrCore.execute(SolrCore.java:1299)
                at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter
        .java:338)
                at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilte
        r.java:241)
                at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(Servlet
        Handler.java:1089)
                at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:3
        65)
                at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.jav
        a:216)
                at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:1
        81)
                at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:7
        12)
                at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
        
                at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHand
        lerCollection.java:211)
                at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.
        java:114)
                at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:1
        39)
                at org.mortbay.jetty.Server.handle(Server.java:285)
                at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:50
        2)
                at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpCo
        nnection.java:821)
                at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513)
                at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:208)
                at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378)
                at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.
        java:226)
                at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool
        .java:442)
        
        
        Show
        Lance Norskog added a comment - Also, spellcheck build gets an error in the Solr servlet. It needs a query string; what for, I don't know. INFO: [] webapp=/solr path=/select params={spellcheck= true &json.wrf=callback21&i ndent= true &start=0&q=&wt=json&spellcheck.build= true } status=500 QTime=23 Aug 31, 2009 5:00:05 PM org.apache.solr.common.SolrException log SEVERE: java.lang.NullPointerException at java.io.StringReader.<init>(StringReader.java:33) at org.apache.lucene.queryParser.QueryParser.parse(QueryParser.java:173) at org.apache.solr.search.LuceneQParser.parse(LuceneQParserPlugin.java:7 8) at org.apache.solr.search.QParser.getQuery(QParser.java:131) at org.apache.solr.handler.component.QueryComponent.prepare(QueryCompone nt.java:89) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(Sea rchHandler.java:174) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandl erBase.java:131) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1299) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter .java:338) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilte r.java:241) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(Servlet Handler.java:1089) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:3 65) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.jav a:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:1 81) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:7 12) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHand lerCollection.java:211) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection. java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:1 39) at org.mortbay.jetty.Server.handle(Server.java:285) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:50 2) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpCo nnection.java:821) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:208) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378) at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector. java:226) at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool .java:442)
        Hide
        Lance Norskog added a comment -

        Hi Uri-

        (You did not mention the console button at the lower right corner. This is very very useful!)

        Editing a query facet did not work for me. After I made one with 'New Facet' plus-sign, I tried to edit it. I got this message:

        Error occured: (TypeError): h is undefined
        
         fileName: http://localhost:8983/solr-explorer/org.apache.solr.explorer.SolrExplorer/D95BC0B1FD429F7CB277268102D19B3E.cache.html
         lineNumber: 2057
         stack: vVc([object Object],[object Object],[object Object])@http://localhost:8983/solr-explorer/org.apache.solr.explorer.SolrExplorer/D95BC0B1FD429F7CB277268102D19B3E.cache.html:2057
        zVc([object Object],[object Object])@http://localhost:8983/solr-explorer/org.apache.solr.explorer.SolrExplorer/D95BC0B1FD429F7CB277268102D19B3E.cache.html:2049
        ([object Object])@http://localhost:8983/solr-explorer/org.apache.solr.explorer.SolrExplorer/D95BC0B1FD429F7CB277268102D19B3E.cache.html:2993
        @http://localhost:8983/solr/select?version=2.2&q=*:*&start=0&facet=on&facet.query=samsung&wt=json&indent=true&json.wrf=callback6:160
        
        Show
        Lance Norskog added a comment - Hi Uri- (You did not mention the console button at the lower right corner. This is very very useful!) Editing a query facet did not work for me. After I made one with 'New Facet' plus-sign, I tried to edit it. I got this message: Error occured: (TypeError): h is undefined fileName: http: //localhost:8983/solr-explorer/org.apache.solr.explorer.SolrExplorer/D95BC0B1FD429F7CB277268102D19B3E.cache.html lineNumber: 2057 stack: vVc([object Object ],[object Object ],[object Object ])@http: //localhost:8983/solr-explorer/org.apache.solr.explorer.SolrExplorer/D95BC0B1FD429F7CB277268102D19B3E.cache.html:2057 zVc([object Object ],[object Object ])@http: //localhost:8983/solr-explorer/org.apache.solr.explorer.SolrExplorer/D95BC0B1FD429F7CB277268102D19B3E.cache.html:2049 ([object Object ])@http: //localhost:8983/solr-explorer/org.apache.solr.explorer.SolrExplorer/D95BC0B1FD429F7CB277268102D19B3E.cache.html:2993 @http: //localhost:8983/solr/select?version=2.2&q=*:*&start=0&facet=on&facet.query=samsung&wt=json&indent= true &json.wrf=callback6:160
        Hide
        Uri Boness added a comment -

        Hi Kaoul,

        The solr explorer is a maven project. This patch adds a new folder in the contrib director. Once patched, you can go to the contrib/solrexplorer directory and build the maven project (ie. mvn clean package). One of the artifacts of the build is the directory where the application sits in.

        It's a stand-alone application that runs in the browser. As such, to run the application all you need to do is to open the SolrExplorer.html file in your browser.

        To configure the application you can customize the solr-explorer.xml which sits in the same directory.

        The main reason I made this patch is to contribute this whole code base to the Solr project and hopefully make it an integral part of Solr. If you want to use this tool without concerning yourself with the patch, you can also download it from:

        http://www.jteam.nl/news/solrexplorer

        I'm still working on the user documentation there, but it's a working version nonetheless.

        Show
        Uri Boness added a comment - Hi Kaoul, The solr explorer is a maven project. This patch adds a new folder in the contrib director. Once patched, you can go to the contrib/solrexplorer directory and build the maven project ( ie. mvn clean package ). One of the artifacts of the build is the directory where the application sits in. It's a stand-alone application that runs in the browser. As such, to run the application all you need to do is to open the SolrExplorer.html file in your browser. To configure the application you can customize the solr-explorer.xml which sits in the same directory. The main reason I made this patch is to contribute this whole code base to the Solr project and hopefully make it an integral part of Solr. If you want to use this tool without concerning yourself with the patch, you can also download it from: http://www.jteam.nl/news/solrexplorer I'm still working on the user documentation there, but it's a working version nonetheless.
        Hide
        kaoul kae added a comment -

        I'm new to GWT and would like to know how to setup this application for solr. Could you make a little step by step how-to as I don't know what to do with the patch. Does it go in solr src ? In a gwt project ? Where do I need to patch ?

        In advance, thank you.

        Show
        kaoul kae added a comment - I'm new to GWT and would like to know how to setup this application for solr. Could you make a little step by step how-to as I don't know what to do with the patch. Does it go in solr src ? In a gwt project ? Where do I need to patch ? In advance, thank you.
        Hide
        Lance Norskog added a comment -

        Voted! I'm an American, so no democracy jokes, please.

        About licensing - does Google put any license restrictions on distributed code?

        Show
        Lance Norskog added a comment - Voted! I'm an American, so no democracy jokes, please. About licensing - does Google put any license restrictions on distributed code?
        Hide
        Uri Boness added a comment -

        Does a GWT client application have a clean license?

        If having a pure Apache 2 license is considered to be clean, then yes.

        Are there any other GWT apps in the Apache project?

        No as far as I know. But you do have LucidGaze which is a Solr monitoring tool and I think it's also a GWT application.

        +1. This is great.

        Thanks, you can also vote for it

        The Simile project has some nice data explorer UIs. The Simile-Widget gallery displays them.

        Thanks for the suggestion. I know this project, but from my experience some of their widgets don't perform really well. Personally, when it comes to data visualization I think flash is the best technology we have at the moment and it's quite easy to interact with it via Javascript and GWT (that's how Google does for most of their applications/services: analytics, finances, etc..)

        Show
        Uri Boness added a comment - Does a GWT client application have a clean license? If having a pure Apache 2 license is considered to be clean, then yes. Are there any other GWT apps in the Apache project? No as far as I know. But you do have LucidGaze which is a Solr monitoring tool and I think it's also a GWT application. +1. This is great. Thanks, you can also vote for it The Simile project has some nice data explorer UIs. The Simile-Widget gallery displays them. Thanks for the suggestion. I know this project, but from my experience some of their widgets don't perform really well. Personally, when it comes to data visualization I think flash is the best technology we have at the moment and it's quite easy to interact with it via Javascript and GWT (that's how Google does for most of their applications/services: analytics, finances, etc..)
        Hide
        Lance Norskog added a comment -

        Does a GWT client application have a clean license? Are there any other GWT apps in the Apache project?

        +1. This is great.

        The Simile project has some nice data explorer UIs. The Simile-Widget gallery displays them.

        Show
        Lance Norskog added a comment - Does a GWT client application have a clean license? Are there any other GWT apps in the Apache project? +1. This is great. The Simile project has some nice data explorer UIs. The Simile-Widget gallery displays them.
        Hide
        Uri Boness added a comment -

        Thanks Yonik.

        The console is in the application. If you look down at the lower right corner, you'll find a small console icon (a la FireBug), click on it and the console will open up.

        Where do I see it fitting? Well, if http://localhost:8983/solr/admin is for the admin page, then I guess http://localhost:8983/solr/explorer can be for the explorer. I don't know, what do you think?

        Show
        Uri Boness added a comment - Thanks Yonik. The console is in the application. If you look down at the lower right corner, you'll find a small console icon (a la FireBug), click on it and the console will open up. Where do I see it fitting? Well, if http://localhost:8983/solr/admin is for the admin page, then I guess http://localhost:8983/solr/explorer can be for the explorer. I don't know, what do you think?
        Hide
        Yonik Seeley added a comment -

        I just got a chance to check out your demo site... cool stuff Uri!
        Is the Console on that demo site somewhere, or is it command line?
        I'll have to leave other technical comments to people who know more about GUIs.... but where do you see this fitting? Default search screen when you hit http://localhost:8983/solr/??? or something else?

        Show
        Yonik Seeley added a comment - I just got a chance to check out your demo site... cool stuff Uri! Is the Console on that demo site somewhere, or is it command line? I'll have to leave other technical comments to people who know more about GUIs.... but where do you see this fitting? Default search screen when you hit http://localhost:8983/solr/??? or something else?
        Uri Boness made changes -
        Attachment solr-explorer.patch [ 12408059 ]
        Hide
        Uri Boness added a comment -

        fixed the groupId in the pom

        Show
        Uri Boness added a comment - fixed the groupId in the pom
        Uri Boness made changes -
        Field Original Value New Value
        Attachment solr-explorer.patch [ 12408005 ]
        Attachment graphics.zip [ 12408006 ]
        Uri Boness created issue -

          People

          • Assignee:
            Unassigned
            Reporter:
            Uri Boness
          • Votes:
            10 Vote for this issue
            Watchers:
            10 Start watching this issue

            Dates

            • Created:
              Updated:

              Development