Solr
  1. Solr
  2. SOLR-85

[PATCH] Add update form to the admin screen

    Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: update
    • Labels:
      None

      Description

      It would be nice to have a webform to update solr via a http interface instead of using the post.sh.

      1. solr-85-with-104.patch
        5 kB
        Ryan McKinley
      2. solr-85-with-104.patch
        10 kB
        Ryan McKinley
      3. solr-85-with-104.patch
        9 kB
        Ryan McKinley
      4. SOLR-85-UpdatForms-RequestHandlers.patch
        29 kB
        Ryan McKinley
      5. SOLR-85-UpdatForms-RequestHandlers.patch
        43 kB
        Ryan McKinley
      6. solr-85.FINAL.diff
        5 kB
        Thorsten Scherler
      7. solr-85.diff
        2 kB
        Thorsten Scherler
      8. solr-85.diff
        5 kB
        Thorsten Scherler
      9. solar-85.with.file.upload.diff
        8 kB
        Thorsten Scherler
      10. solar-85.with.file.upload.diff
        12 kB
        Thorsten Scherler
      11. solar-85.with.file.upload.diff
        12 kB
        Thorsten Scherler
      12. solar-85.with.file.upload.diff
        12 kB
        Thorsten Scherler
      13. solar-85.png
        235 kB
        Thorsten Scherler
      14. solar-85.png
        30 kB
        Thorsten Scherler

        Issue Links

          Activity

          Hide
          Thorsten Scherler added a comment -

          Screenshot of the extended admin screen

          Show
          Thorsten Scherler added a comment - Screenshot of the extended admin screen
          Hide
          Thorsten Scherler added a comment -

          Patch for the update form

          Show
          Thorsten Scherler added a comment - Patch for the update form
          Hide
          Thorsten Scherler added a comment -

          The former version did not contain the new servlet, this one does.

          Show
          Thorsten Scherler added a comment - The former version did not contain the new servlet, this one does.
          Hide
          Thorsten Scherler added a comment -

          Final version of patch.

          Show
          Thorsten Scherler added a comment - Final version of patch.
          Hide
          Thorsten Scherler added a comment -

          The last patch is compatible with ASF Granted License!!! I forgot to check the box. Sorry.

          Show
          Thorsten Scherler added a comment - The last patch is compatible with ASF Granted License!!! I forgot to check the box. Sorry.
          Hide
          Thorsten Scherler added a comment -

          This new feature allows you to update your solr instance via web. For your convenience I add the a commit button to commit directly afterwards.
          Just add your update statement into the form and submit.

          Try with
          <add>
          <doc>
          <field name="id">SP2514N</field>
          <field name="name">Samsung SpinPoint P120 SP2514N - hard drive - 250 GB - ATA-133</field>
          <field name="manu">Samsung Electronics Co. Ltd.</field>
          <field name="cat">electronics</field>
          <field name="cat">hard drive</field>
          <field name="features">7200RPM, 8MB cache, IDE Ultra ATA-133</field>
          <field name="features">NoiseGuard, SilentSeek technology, Fluid Dynamic Bearing (FDB) motor</field>
          <field name="price">92</field>
          <field name="popularity">6</field>
          <field name="inStock">true</field>
          </doc>

          </add>

          Show
          Thorsten Scherler added a comment - This new feature allows you to update your solr instance via web. For your convenience I add the a commit button to commit directly afterwards. Just add your update statement into the form and submit. Try with <add> <doc> <field name="id">SP2514N</field> <field name="name">Samsung SpinPoint P120 SP2514N - hard drive - 250 GB - ATA-133</field> <field name="manu">Samsung Electronics Co. Ltd.</field> <field name="cat">electronics</field> <field name="cat">hard drive</field> <field name="features">7200RPM, 8MB cache, IDE Ultra ATA-133</field> <field name="features">NoiseGuard, SilentSeek technology, Fluid Dynamic Bearing (FDB) motor</field> <field name="price">92</field> <field name="popularity">6</field> <field name="inStock">true</field> </doc> </add>
          Hide
          Hoss Man added a comment -

          having a way to send updates using a more standard CGI/form-encoding POST mechanism is probably a good idea ... but i'm not sure if i'm keen on putting a form for sending updates on the admin page.

          the ability to query from the admin page is mainly a debugging tool, and a way to play with query options untill you find a URL template that works well for your index... but the update side of things doesn't really have the same usage.

          (I guess there's really no down side to having a form though)

          Show
          Hoss Man added a comment - having a way to send updates using a more standard CGI/form-encoding POST mechanism is probably a good idea ... but i'm not sure if i'm keen on putting a form for sending updates on the admin page. the ability to query from the admin page is mainly a debugging tool, and a way to play with query options untill you find a URL template that works well for your index... but the update side of things doesn't really have the same usage. (I guess there's really no down side to having a form though)
          Hide
          Thorsten Scherler added a comment -

          The solar-85.with.file.upload.diff is further extending the current patch and makes the old diffs obsolete. I sadly have no power to remove the obsolete attachments. Sorry.

          This patch is providing a way to upload a update document.

          On Fri, 2006-12-15 at 04:57 +0100, Zaheed Haque wrote:
          ...
          > Maybe you can add a "file upload" button. what I mean is
          > that lets say
          > you have a file data.xml or data.txt or data.tar.gzip (maybe gzip or
          > tar format can be done later)
          > with many solr records..like ..
          >
          > <doc>
          > </doc>
          > etc.. more..
          > <doc>
          > </doc>
          >
          > Then you could uplaod that file and "presto" you updated the index..
          > that would be cool. I still would like to have the current textarea
          > box its cool to be able to delete a <doc></doc> directly ot update a
          > <doc> directly..
          >

          The current implementation is assuming the uploaded file is an xml document.

          Show
          Thorsten Scherler added a comment - The solar-85.with.file.upload.diff is further extending the current patch and makes the old diffs obsolete. I sadly have no power to remove the obsolete attachments. Sorry. This patch is providing a way to upload a update document. On Fri, 2006-12-15 at 04:57 +0100, Zaheed Haque wrote: ... > Maybe you can add a "file upload" button. what I mean is > that lets say > you have a file data.xml or data.txt or data.tar.gzip (maybe gzip or > tar format can be done later) > with many solr records..like .. > > <doc> > </doc> > etc.. more.. > <doc> > </doc> > > Then you could uplaod that file and "presto" you updated the index.. > that would be cool. I still would like to have the current textarea > box its cool to be able to delete a <doc></doc> directly ot update a > <doc> directly.. > The current implementation is assuming the uploaded file is an xml document.
          Hide
          Thorsten Scherler added a comment -

          @Hoss yeah I understand your concerns and actually the update form is a wee bit apart from the rest of the forms in admin area.
          It is more a general approach rather then focused on the examples.

          Maybe this whole patch good be better packaged as plugin but I am still new to solr and I am not sure how I good patch the web.xml with a plugin. Any pointers appreciated.

          The next thing on my list is to write a small cli based on httpclient to send the update docs as alternative of the post.sh.

          BTW the patch needs
          lib/commons-fileupload-1.1.1.jar -> http://jakarta.apache.org/site/downloads/downloads_commons-fileupload.cgi
          lib/commons-io-1.2.jar -> http://jakarta.apache.org/site/downloads/downloads_commons-io.cgi

          Show
          Thorsten Scherler added a comment - @Hoss yeah I understand your concerns and actually the update form is a wee bit apart from the rest of the forms in admin area. It is more a general approach rather then focused on the examples. Maybe this whole patch good be better packaged as plugin but I am still new to solr and I am not sure how I good patch the web.xml with a plugin. Any pointers appreciated. The next thing on my list is to write a small cli based on httpclient to send the update docs as alternative of the post.sh. BTW the patch needs lib/commons-fileupload-1.1.1.jar -> http://jakarta.apache.org/site/downloads/downloads_commons-fileupload.cgi lib/commons-io-1.2.jar -> http://jakarta.apache.org/site/downloads/downloads_commons-io.cgi
          Hide
          Thorsten Scherler added a comment -

          New screenshot including the new features.

          Show
          Thorsten Scherler added a comment - New screenshot including the new features.
          Hide
          Yonik Seeley added a comment -

          Cool stuff Thorsten! Things like this can increase the user-friendliness of Solr and make it easier to learn.
          To be safe though, perhaps there should be an "update" page so someone doesn't change an index with a single errant click?
          And make it easy to disable the update page from solrconfig.xml, and put a comment telling people how it can be disabled.
          "commit" and "optimize" buttons would be nice!

          Does commons-fileupload handle multi-part posts? The ability to send a CSV file from a browser to Solr is something I've been meaning to look into.

          Some ideas for a "future" update page (doesn't need to be in this patch)

          • something that helps you build the XML... select a field, input value(s), and have a "generate request" button so you can see what is about to be sent.
          • show some update statistics... number of pending documents, etc
          • support for future update syntaxes (CSV?)
          • ability to select files to upload
          Show
          Yonik Seeley added a comment - Cool stuff Thorsten! Things like this can increase the user-friendliness of Solr and make it easier to learn. To be safe though, perhaps there should be an "update" page so someone doesn't change an index with a single errant click? And make it easy to disable the update page from solrconfig.xml, and put a comment telling people how it can be disabled. "commit" and "optimize" buttons would be nice! Does commons-fileupload handle multi-part posts? The ability to send a CSV file from a browser to Solr is something I've been meaning to look into. Some ideas for a "future" update page (doesn't need to be in this patch) something that helps you build the XML... select a field, input value(s), and have a "generate request" button so you can see what is about to be sent. show some update statistics... number of pending documents, etc support for future update syntaxes (CSV?) ability to select files to upload
          Hide
          Hoss Man added a comment -

          There really isn't any easy way for a "plugin" to modify the web.xml to register new servlets ... but i think this would definitely be a usefull enough feature to include in the core – i'm just not fond of having hte form on the main page ... linking to an explicit "update" page with a form like the one you made with a text area and file upload options would be fine ... it could also incorporate options for triggering the new bulk-loading options Yonik has been working on in SOLR-66 as well.

          Show
          Hoss Man added a comment - There really isn't any easy way for a "plugin" to modify the web.xml to register new servlets ... but i think this would definitely be a usefull enough feature to include in the core – i'm just not fond of having hte form on the main page ... linking to an explicit "update" page with a form like the one you made with a text area and file upload options would be fine ... it could also incorporate options for triggering the new bulk-loading options Yonik has been working on in SOLR-66 as well.
          Hide
          Thorsten Scherler added a comment -

          Well this issue can be seen as enabler for SOLR-66.

          Especially the upload part.
          @Yonik, yes the commons-fileupload.jar handles the multi-part posts:

          ServletFileUpload upload = new ServletFileUpload(factory);
          // Parse the request
          List iter;
          try

          { iter = upload.parseRequest(request); }

          catch (FileUploadException e)

          { throw new IOException( "FileUploadException\nStack: " + e); }

          We then wrap the file and open an input stream, which we pass to the core.
          InputStream stream = item.getInputStream();
          commandReader = new BufferedReader(new InputStreamReader(stream));
          core.update(commandReader, responseWriter);

          I reckon we could test the mime-type of the file before posting it to the core.update.
          This way we can generate xml out of csv like in SOLR-66.

          So instead making SOLR-66 a servlet on its on it should become something like a solr.input.plugin. A input plugin is code that is transforming incoming input to solr internal xml markup used fo updates.

          Now lets assume the csv has a register input plugin then we need to change
          core.update(commandReader, responseWriter);
          to something like
          InputPlugin plugin = core.lookupPlugin(stream);
          core.update(plugin.getReader(), responseWriter);

          The lookup would be done done via a register that contains all input plugins and their mime-type pairs. This way one can imagine not only cvs or xml as input data. Imagine one want to use a SQL backend to update solr, with a sql input plugin that would become an easy task.

          the only hard thing is how to auto determine (configure) the plugins used for certain streams. As a workaround one could add the plugin as input parameter.

          WDYT?

          Show
          Thorsten Scherler added a comment - Well this issue can be seen as enabler for SOLR-66 . Especially the upload part. @Yonik, yes the commons-fileupload.jar handles the multi-part posts: ServletFileUpload upload = new ServletFileUpload(factory); // Parse the request List iter; try { iter = upload.parseRequest(request); } catch (FileUploadException e) { throw new IOException( "FileUploadException\nStack: " + e); } We then wrap the file and open an input stream, which we pass to the core. InputStream stream = item.getInputStream(); commandReader = new BufferedReader(new InputStreamReader(stream)); core.update(commandReader, responseWriter); I reckon we could test the mime-type of the file before posting it to the core.update. This way we can generate xml out of csv like in SOLR-66 . So instead making SOLR-66 a servlet on its on it should become something like a solr.input.plugin. A input plugin is code that is transforming incoming input to solr internal xml markup used fo updates. Now lets assume the csv has a register input plugin then we need to change core.update(commandReader, responseWriter); to something like InputPlugin plugin = core.lookupPlugin(stream); core.update(plugin.getReader(), responseWriter); The lookup would be done done via a register that contains all input plugins and their mime-type pairs. This way one can imagine not only cvs or xml as input data. Imagine one want to use a SQL backend to update solr, with a sql input plugin that would become an easy task. the only hard thing is how to auto determine (configure) the plugins used for certain streams. As a workaround one could add the plugin as input parameter. WDYT?
          Hide
          Thorsten Scherler added a comment -

          On Fri, 2006-12-15 at 09:08 -0800, Yonik Seeley (JIRA) wrote:
          Yonik Seeley commented on SOLR-85:
          > ----------------------------------
          >
          > Cool stuff Thorsten!

          Cheers.

          > Things like this can increase the user-friendliness of Solr and make it easier to learn.

          Yeah, and play around platform independent.

          > To be safe though, perhaps there should be an "update" page so someone doesn't change an index with a single errant click?

          Done this, updated patch attached.

          > And make it easy to disable the update page from solrconfig.xml,

          Done this:
          ...
          <!-- config for the admin interface -->
          <admin>
          ...
          <!-- You can disable/enable the upload of update commands
          via the update.jsp -->
          <enableUpload>true</enableUpload>
          </admin>

          > and put a comment telling people how it can be disabled.

          I added further comments on the pages (index + update) how to change the behavior.

          > "commit" and "optimize" buttons would be nice!

          There is a commit checkbox, if you check it, after your update statements it will do as well a commit.

          Not sure about the optimize button, what will it do?

          >
          > Some ideas for a "future" update page (doesn't need to be in this patch)
          > - something that helps you build the XML... select a field, input value(s), and have a "generate request" button so you can see what is about to be sent.

          yeah that would be nice

          > - show some update statistics... number of pending documents, etc

          yeah

          > - support for future update syntaxes (CSV?)

          see my comment before, I reckon the best way would be that the cvs becomes an input plugin and returns xml instead actually handle the request. Then the default input plugin (if no other input plugin is selected) would be a xml plugin, treating the Stream as is.

          > - ability to select files to upload

          you mean, more then one file? Yeah, should not be too hard.

          Anyway like you stated "future update page", maybe best to apply this patch and we open a new one for the mentioned enhancements.

          WDYT?

          Show
          Thorsten Scherler added a comment - On Fri, 2006-12-15 at 09:08 -0800, Yonik Seeley (JIRA) wrote: Yonik Seeley commented on SOLR-85 : > ---------------------------------- > > Cool stuff Thorsten! Cheers. > Things like this can increase the user-friendliness of Solr and make it easier to learn. Yeah, and play around platform independent. > To be safe though, perhaps there should be an "update" page so someone doesn't change an index with a single errant click? Done this, updated patch attached. > And make it easy to disable the update page from solrconfig.xml, Done this: ... <!-- config for the admin interface --> <admin> ... <!-- You can disable/enable the upload of update commands via the update.jsp --> <enableUpload>true</enableUpload> </admin> > and put a comment telling people how it can be disabled. I added further comments on the pages (index + update) how to change the behavior. > "commit" and "optimize" buttons would be nice! There is a commit checkbox, if you check it, after your update statements it will do as well a commit. Not sure about the optimize button, what will it do? > > Some ideas for a "future" update page (doesn't need to be in this patch) > - something that helps you build the XML... select a field, input value(s), and have a "generate request" button so you can see what is about to be sent. yeah that would be nice > - show some update statistics... number of pending documents, etc yeah > - support for future update syntaxes (CSV?) see my comment before, I reckon the best way would be that the cvs becomes an input plugin and returns xml instead actually handle the request. Then the default input plugin (if no other input plugin is selected) would be a xml plugin, treating the Stream as is. > - ability to select files to upload you mean, more then one file? Yeah, should not be too hard. Anyway like you stated "future update page", maybe best to apply this patch and we open a new one for the mentioned enhancements. WDYT?
          Hide
          Thorsten Scherler added a comment -

          Changing sysout to log.
          Removing obsolete variables.

          Show
          Thorsten Scherler added a comment - Changing sysout to log. Removing obsolete variables.
          Hide
          Thorsten Scherler added a comment -

          Always using <results/> as surrounding tag.
          When in multiPart mode the commit field needs to be read within the multiPart processing.

          Show
          Thorsten Scherler added a comment - Always using <results/> as surrounding tag. When in multiPart mode the commit field needs to be read within the multiPart processing.
          Hide
          Ryan McKinley added a comment -

          With SOLR-104, forms can add a "stream.body" that gets passed as a ContentStream to the request handler

          <form action="/update" method="post" >
          <textarea name="stream.body" >
          <add>
          <doc>
          <field name="id">SOLR1000</field>
          <field name="name">Solr, the Enterprise Search Server</field>
          </doc>
          </add>
          </textarea>
          <input type="submit" />
          </form>

          Show
          Ryan McKinley added a comment - With SOLR-104 , forms can add a "stream.body" that gets passed as a ContentStream to the request handler <form action="/update" method="post" > <textarea name="stream.body" > <add> <doc> <field name="id">SOLR1000</field> <field name="name">Solr, the Enterprise Search Server</field> </doc> </add> </textarea> <input type="submit" /> </form>
          Hide
          Ryan McKinley added a comment -

          just posted solr-85-with-104.patch

          This uses SOLR-104 to pass the content with stream.body.

          This patch includes some small modification to SOLR-104, including:

          • it call rsp.setException(e)
          • it lets you add the 'commit' or 'optimize' command to XmlUpdate
          • XmlUpdate uses req.getCore() rather then SolrCore.getSolrCore() where possible
          Show
          Ryan McKinley added a comment - just posted solr-85-with-104.patch This uses SOLR-104 to pass the content with stream.body. This patch includes some small modification to SOLR-104 , including: it call rsp.setException(e) it lets you add the 'commit' or 'optimize' command to XmlUpdate XmlUpdate uses req.getCore() rather then SolrCore.getSolrCore() where possible
          Hide
          Thorsten Scherler added a comment -

          Hi Ryan,

          sorry for coming back so late on this, but I need to finish up the first version of a customer project.

          Anyway, I saw that SOLR-104 is now applied meaning your last patch on this issue should work fine, right.

          Are they any other blocker on this issue?

          salu2

          Show
          Thorsten Scherler added a comment - Hi Ryan, sorry for coming back so late on this, but I need to finish up the first version of a customer project. Anyway, I saw that SOLR-104 is now applied meaning your last patch on this issue should work fine, right. Are they any other blocker on this issue? salu2
          Hide
          Ryan McKinley added a comment -

          the last patch (solr-85-with-104.patch) should work fine

          no blocker issues

          ryan

          Show
          Ryan McKinley added a comment - the last patch (solr-85-with-104.patch) should work fine no blocker issues ryan
          Hide
          Yonik Seeley added a comment -

          Ryan, see Thorsten's last patch: solar-85.with.file.upload.diff
          that addressed some previous comments (separate update page, able to be disabled from solrconfig, etc)

          Show
          Yonik Seeley added a comment - Ryan, see Thorsten's last patch: solar-85.with.file.upload.diff that addressed some previous comments (separate update page, able to be disabled from solrconfig, etc)
          Hide
          Ryan McKinley added a comment -

          oops, i was looking at: solr-85.FINAL.diff

          Show
          Ryan McKinley added a comment - oops, i was looking at: solr-85.FINAL.diff
          Hide
          Yonik Seeley added a comment -

          If you click on "Manage Attachments" (do you have that link?) it shows the date each attachment was added.
          That's why I prefer versions of a patch all added under the same name... then JIRA takes care of telling me which is newest by graying out the old ones.

          Show
          Yonik Seeley added a comment - If you click on "Manage Attachments" (do you have that link?) it shows the date each attachment was added. That's why I prefer versions of a patch all added under the same name... then JIRA takes care of telling me which is newest by graying out the old ones.
          Hide
          Ryan McKinley added a comment -

          Ok, this one is based on solar-85.with.file.upload.diff!

          It also adds a few minor fixes / adjustments to SOLR-104

          Show
          Ryan McKinley added a comment - Ok, this one is based on solar-85.with.file.upload.diff! It also adds a few minor fixes / adjustments to SOLR-104
          Hide
          Ryan McKinley added a comment -

          slight change so it applies cleanly after SOLR-145

          Show
          Ryan McKinley added a comment - slight change so it applies cleanly after SOLR-145
          Hide
          Hoss Man added a comment -

          I have two reservcations about this patch...

          1) duplicate code cut/paste from CommitRequestHandler in XmlUpdateRequestHandler ... I agree that it would be nice if XmlUpdateRequestHandler had that functionality, but it seems like it would be better to either refactor it into a utility method, or make XmlUpdateRequestHandler extend CommitRequestHandler and call super.handleRequestBody at the end of it's own handleRequestBody.

          2) the upload form assumes /update/xml is a registered requestHandler name which is a bit brittle if people want to register it with a differnet name, and also makes hte form fairly unusable if/when people register new update handlers – i'm sure yonik will polish his csv handler any day now

          ... a more reusable mechanism would probably be if instead of a simple <enableUpload>true</enableUpload> we had something like...

          <uploadFormHandlers>
          <handler name="/update/xml">Upload XML</handler>
          <handler name="/update/foo/bar/baz">Upload CSV</handler>
          </uploadFormHandler

          ...admin.jsp would link to the upload form if any uploadHandlers/handler entries exist .. and update.jsp would loop over all of them making a seperate form for each.

          Show
          Hoss Man added a comment - I have two reservcations about this patch... 1) duplicate code cut/paste from CommitRequestHandler in XmlUpdateRequestHandler ... I agree that it would be nice if XmlUpdateRequestHandler had that functionality, but it seems like it would be better to either refactor it into a utility method, or make XmlUpdateRequestHandler extend CommitRequestHandler and call super.handleRequestBody at the end of it's own handleRequestBody. 2) the upload form assumes /update/xml is a registered requestHandler name which is a bit brittle if people want to register it with a differnet name, and also makes hte form fairly unusable if/when people register new update handlers – i'm sure yonik will polish his csv handler any day now ... a more reusable mechanism would probably be if instead of a simple <enableUpload>true</enableUpload> we had something like... <uploadFormHandlers> <handler name="/update/xml">Upload XML</handler> <handler name="/update/foo/bar/baz">Upload CSV</handler> </uploadFormHandler ...admin.jsp would link to the upload form if any uploadHandlers/handler entries exist .. and update.jsp would loop over all of them making a seperate form for each.
          Hide
          Ryan McKinley added a comment -

          >
          > 1) duplicate code cut/paste from CommitRequestHandler in XmlUpdateRequestHandler

          I moved the common code to a new file RequestHandlerUtils.java

          > 2) the upload form assumes /update/xml is a registered requestHandler name which...

          I may have gone completely mad with this one, so a sanity check would be good!

          I made a "FormRequestHandler" that returns an HTML form for a given path if it has been registered. For example, if you had:

          <requestHandler name="/admin/form" class="...FormRequestHandler" >
          <lst name="invariants">
          <str name="wt">raw</str>
          </lst>
          <lst name="forms">
          <str name="/update/xml">forms/update/xml.html</str>
          <srr name="/update/csv">forms/update/csv.html</str>
          </lst>
          </requestHandler>

          hitting:
          http://localhost:8983/solr/admin/form?path=/update/xml

          returns the html sitting in $

          {solr.home}

          /conf/forms/update/xml.html

          It replaces $

          {path}

          with the registered path.

          • - - - - - -

          Since the admin RequestHandler config scheme gets pretty unruly if you have to configure it is solrconfig.xml, I added a flag to the <admin> section to set where you want all the standard ones

          <admin>
          <registerStandardHandlers>/admin</registerStandardHandlers>
          ...
          </admin>

          If you put "false" it will not register the default paths. It will not overwrite any existing paths either. that is, if you manually register, "/admin/file" it will not put in the default one

          • - - - -

          The AdminHandlersSetupHelper automatically finds forms in the conf/forms/ directory that match registered handlers and registers them with the FormRequestHandler.

          • - - - - -

          I'm putting this up mostly for a sanity check. If you like the direction, i'll add more comments, documentation and clean things up.

          thanks

          Show
          Ryan McKinley added a comment - > > 1) duplicate code cut/paste from CommitRequestHandler in XmlUpdateRequestHandler I moved the common code to a new file RequestHandlerUtils.java > 2) the upload form assumes /update/xml is a registered requestHandler name which... I may have gone completely mad with this one, so a sanity check would be good! I made a "FormRequestHandler" that returns an HTML form for a given path if it has been registered. For example, if you had: <requestHandler name="/admin/form" class="...FormRequestHandler" > <lst name="invariants"> <str name="wt">raw</str> </lst> <lst name="forms"> <str name="/update/xml">forms/update/xml.html</str> <srr name="/update/csv">forms/update/csv.html</str> </lst> </requestHandler> hitting: http://localhost:8983/solr/admin/form?path=/update/xml returns the html sitting in $ {solr.home} /conf/forms/update/xml.html It replaces $ {path} with the registered path. - - - - - - Since the admin RequestHandler config scheme gets pretty unruly if you have to configure it is solrconfig.xml, I added a flag to the <admin> section to set where you want all the standard ones <admin> <registerStandardHandlers>/admin</registerStandardHandlers> ... </admin> If you put "false" it will not register the default paths. It will not overwrite any existing paths either. that is, if you manually register, "/admin/file" it will not put in the default one - - - - The AdminHandlersSetupHelper automatically finds forms in the conf/forms/ directory that match registered handlers and registers them with the FormRequestHandler. - - - - - I'm putting this up mostly for a sanity check. If you like the direction, i'll add more comments, documentation and clean things up. thanks
          Hide
          Ryan McKinley added a comment -

          At least for now, I'm going to include this in SOLR-162 - the two issues depend on so much of the same stuff it is easier then maintaing two issues (at least for now)

          Show
          Ryan McKinley added a comment - At least for now, I'm going to include this in SOLR-162 - the two issues depend on so much of the same stuff it is easier then maintaing two issues (at least for now)
          Hide
          Thorsten Scherler added a comment -

          Hi Ryan,

          I just did a quick check of the current trunk and could not found the patch includes (as I understood it from your last comment).

          How can I help to get the patch into the trunk?

          Show
          Thorsten Scherler added a comment - Hi Ryan, I just did a quick check of the current trunk and could not found the patch includes (as I understood it from your last comment). How can I help to get the patch into the trunk?
          Hide
          Ryan McKinley added a comment -

          This patch and SOLR-142 need to figure out how to deal with arbitrary path mapping. Since the update command is not fixed to /update and we also want to support /update/csv, we need some way to deal with that.

          I think the best option would be to configure the admin links from solrconfig.xml. perhaps something like:

          <admin>
          <defaultQuery>solr</defaultQuery>
          <header>
          <links name="solr">
          <link name="Schema" path="/admin/file?file=schema.xml" />
          <link name="Config" path="/admin/file?file=solrconfig.xml" />
          <link name="Analysis" path="/admin/analysis.jsp" />
          <br/>
          <link name="Statistics" path="/admin/stats.jsp" />
          <link name="Info" path="/admin/registry.jsp" />
          <link name="Distribution" path="/admin/distributiondump.jsp" />
          <link name="Ping" path="/admin/ping" />
          <link name="Logging" path="/admin/logging.jsp" />
          </links>
          <links name="update">
          <link name="Update" path="/admin/?show=update.html" />
          <link name="CSV" path="/admin/?show=updatecsv.html" />
          </links>
          <links name="App server">
          <link name="Properties" path="/admin/properties" />
          <link name="Thread Dump" path="/admin/threaddump.jsp" />
          </links>
          </header>
          ...

          check: http://www.nabble.com/-jira--Created%3A-%28SOLR-142%29-RawResponseWriter---replace--admin-get-file.jsp-tf3176309.html#a10235374

          Show
          Ryan McKinley added a comment - This patch and SOLR-142 need to figure out how to deal with arbitrary path mapping. Since the update command is not fixed to /update and we also want to support /update/csv, we need some way to deal with that. I think the best option would be to configure the admin links from solrconfig.xml. perhaps something like: <admin> <defaultQuery>solr</defaultQuery> <header> <links name="solr"> <link name="Schema" path="/admin/file?file=schema.xml" /> <link name="Config" path="/admin/file?file=solrconfig.xml" /> <link name="Analysis" path="/admin/analysis.jsp" /> <br/> <link name="Statistics" path="/admin/stats.jsp" /> <link name="Info" path="/admin/registry.jsp" /> <link name="Distribution" path="/admin/distributiondump.jsp" /> <link name="Ping" path="/admin/ping" /> <link name="Logging" path="/admin/logging.jsp" /> </links> <links name="update"> <link name="Update" path="/admin/?show=update.html" /> <link name="CSV" path="/admin/?show=updatecsv.html" /> </links> <links name="App server"> <link name="Properties" path="/admin/properties" /> <link name="Thread Dump" path="/admin/threaddump.jsp" /> </links> </header> ... check: http://www.nabble.com/-jira--Created%3A-%28SOLR-142%29-RawResponseWriter---replace--admin-get-file.jsp-tf3176309.html#a10235374
          Hide
          Erick Erickson added a comment -

          Cleaning up old JIRAs, re-open if necessary.

          Show
          Erick Erickson added a comment - Cleaning up old JIRAs, re-open if necessary.

            People

            • Assignee:
              Unassigned
              Reporter:
              Thorsten Scherler
            • Votes:
              2 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development