I have catched case of this bug. If DIHs exist in solrconfig.xml as dataimport, dataimport_0, dataimport_1 ..., then it can show them but if DIHs exist as dataimport_0, dataimport_1, dataimport_2 ... then cannot display them.

Buğra Yıldırım i'm not entirely sure i understand what you're saying this this. does the new ui require a thing named "dataimport" to work? is the amount of configurations relevant? what exactly does "not work" mean in this case? do you get a error message (on screen) or something like that?

Thanks for the screenshots Buğra Yıldırım - still trying to confirm your initial report.

Does it matter if the configuration does use dataimport? obviously the old ui is able to list all of them, no matter how they are named. but i'm curious what's the case for the new ui.

sorry for my bad expressions. I have added screenshots. screenshot-1 is new UI. It does not display dataimports. I switch old UI then I can see dataimports.(screenshot-2).
My definitions of requesthandler in solrconfig.xml is below:

<requestHandler name="/dataimport_0"
class="org.apache.solr.handler.dataimport.DataImportHandler">
<lst name="defaults">
<str name="config">data-config_0.xml</str>
</lst>
</requestHandler>
<requestHandler name="/dataimport_1"
class="org.apache.solr.handler.dataimport.DataImportHandler">
<lst name="defaults">
<str name="config">data-config_1.xml</str>
</lst>
</requestHandler>
<requestHandler name="/dataimport_2"
class="org.apache.solr.handler.dataimport.DataImportHandler">
<lst name="defaults">
<str name="config">data-config_2.xml</str>
</lst>
</requestHandler>
<requestHandler name="/dataimport_3"
class="org.apache.solr.handler.dataimport.DataImportHandler">
<lst name="defaults">
<str name="config">data-config_3.xml</str>
</lst>
</requestHandler>
<requestHandler name="/dataimport_4"
class="org.apache.solr.handler.dataimport.DataImportHandler">
<lst name="defaults">
<str name="config">data-config_4.xml</str>
</lst>
</requestHandler>
<requestHandler name="/dataimport_5"
class="org.apache.solr.handler.dataimport.DataImportHandler">
<lst name="defaults">
<str name="config">data-config_5.xml</str>
</lst>
</requestHandler>
<requestHandler name="/dataimport_6"
class="org.apache.solr.handler.dataimport.DataImportHandler">
<lst name="defaults">
<str name="config">data-config_6.xml</str>
</lst>
</requestHandler>
<requestHandler name="/dataimport_7"
class="org.apache.solr.handler.dataimport.DataImportHandler">
<lst name="defaults">
<str name="config">data-config_7.xml</str>
</lst>
</requestHandler>
<requestHandler name="/dataimport_8"
class="org.apache.solr.handler.dataimport.DataImportHandler">
<lst name="defaults">
<str name="config">data-config_8.xml</str>
</lst>
</requestHandler>
<requestHandler name="/dataimport_9"
class="org.apache.solr.handler.dataimport.DataImportHandler">
<lst name="defaults">
<str name="config">data-config_9.xml</str>
</lst>
</requestHandler>
<requestHandler name="/dataimport_a"
class="org.apache.solr.handler.dataimport.DataImportHandler">
<lst name="defaults">
<str name="config">data-config_a.xml</str>
</lst>
</requestHandler>
<requestHandler name="/dataimport_b"
class="org.apache.solr.handler.dataimport.DataImportHandler">
<lst name="defaults">
<str name="config">data-config_b.xml</str>
</lst>
</requestHandler>
<requestHandler name="/dataimport_c"
class="org.apache.solr.handler.dataimport.DataImportHandler">
<lst name="defaults">
<str name="config">data-config_c.xml</str>
</lst>
</requestHandler>
<requestHandler name="/dataimport_d"
class="org.apache.solr.handler.dataimport.DataImportHandler">
<lst name="defaults">
<str name="config">data-config_d.xml</str>
</lst>
</requestHandler>
<requestHandler name="/dataimport_e"
class="org.apache.solr.handler.dataimport.DataImportHandler">
<lst name="defaults">
<str name="config">data-config_e.xml</str>
</lst>
</requestHandler>
<requestHandler name="/dataimport_f"
class="org.apache.solr.handler.dataimport.DataImportHandler">
<lst name="defaults">
<str name="config">data-config_f.xml</str>
</lst>
</requestHandler>

No need to excuse yourself, bug reports are appreciated and helpful - i'm just trying to figure out what's the actual problem at hand. if the new ui is able at all to show dataimport handler, if it does require a specific name to be included in the list of defined handlers or if the problem is located elsewhere.

which is why i've asked if you have (or otherwise could) checked if it does work, if one of the handlers is named dataimport w/o any pre- or suffix. your two screenshots do show, that it does not work at all - but in a case, where none of the handlers are named as such.

I have added new screenshot. If DIH definitions in solrconfig.xml like below, new UI can display it. Differences of below definitions from above definitions is that below definitions include dataimport(without suffix). (screenshot3 --> new, screenshot4 --> old)

<requestHandler name="/dataimport"
class="org.apache.solr.handler.dataimport.DataImportHandler">
<lst name="defaults">
<str name="config">data-config.xml</str>
</lst>
</requestHandler>

<requestHandler name="/dataimport_0"
class="org.apache.solr.handler.dataimport.DataImportHandler">
<lst name="defaults">
<str name="config">data-config_0.xml</str>
</lst>
</requestHandler>

<requestHandler name="/dataimport_1"
class="org.apache.solr.handler.dataimport.DataImportHandler">
<lst name="defaults">
<str name="config">data-config_1.xml</str>
</lst>
</requestHandler>

<requestHandler name="/dataimport_2"
class="org.apache.solr.handler.dataimport.DataImportHandler">
<lst name="defaults">
<str name="config">data-config_2.xml</str>
</lst>
</requestHandler>

<requestHandler name="/dataimport_3"
class="org.apache.solr.handler.dataimport.DataImportHandler">
<lst name="defaults">
<str name="config">data-config_3.xml</str>
</lst>
</requestHandler>

<requestHandler name="/dataimport_4"
class="org.apache.solr.handler.dataimport.DataImportHandler">
<lst name="defaults">
<str name="config">data-config_4.xml</str>
</lst>
</requestHandler>

<requestHandler name="/dataimport_5"
class="org.apache.solr.handler.dataimport.DataImportHandler">
<lst name="defaults">
<str name="config">data-config_5.xml</str>
</lst>
</requestHandler>

<requestHandler name="/dataimport_6"
class="org.apache.solr.handler.dataimport.DataImportHandler">
<lst name="defaults">
<str name="config">data-config_6.xml</str>
</lst>
</requestHandler>

<requestHandler name="/dataimport_7"
class="org.apache.solr.handler.dataimport.DataImportHandler">
<lst name="defaults">
<str name="config">data-config_7.xml</str>
</lst>
</requestHandler>

<requestHandler name="/dataimport_8"
class="org.apache.solr.handler.dataimport.DataImportHandler">
<lst name="defaults">
<str name="config">data-config_8.xml</str>
</lst>
</requestHandler>

<requestHandler name="/dataimport_9"
class="org.apache.solr.handler.dataimport.DataImportHandler">
<lst name="defaults">
<str name="config">data-config_9.xml</str>
</lst>
</requestHandler>

<requestHandler name="/dataimport_a"
class="org.apache.solr.handler.dataimport.DataImportHandler">
<lst name="defaults">
<str name="config">data-config_a.xml</str>
</lst>
</requestHandler>

<requestHandler name="/dataimport_b"
class="org.apache.solr.handler.dataimport.DataImportHandler">
<lst name="defaults">
<str name="config">data-config_b.xml</str>
</lst>
</requestHandler>

<requestHandler name="/dataimport_c"
class="org.apache.solr.handler.dataimport.DataImportHandler">
<lst name="defaults">
<str name="config">data-config_c.xml</str>
</lst>
</requestHandler>

<requestHandler name="/dataimport_d"
class="org.apache.solr.handler.dataimport.DataImportHandler">
<lst name="defaults">
<str name="config">data-config_d.xml</str>
</lst>
</requestHandler>

<requestHandler name="/dataimport_e"
class="org.apache.solr.handler.dataimport.DataImportHandler">
<lst name="defaults">
<str name="config">data-config_e.xml</str>
</lst>
</requestHandler>

<requestHandler name="/dataimport_f"
class="org.apache.solr.handler.dataimport.DataImportHandler">
<lst name="defaults">
<str name="config">data-config_f.xml</str>
</lst>
</requestHandler>

I was going to report this bug as well, but saw this post.

The issue is that it does list both / all DataImportHandlers you have listed in your config, but the are all associated with the first list of defaults.

In my case I have two defined as below. They both show up named properly in the new UI but load the config only from the first handler /dataimport. when I click on /dataimport-date-range I see the last run time, details and config from /dataimport.

I also see the "No dataimporthandlers defined message" briefly then my handlers show, but I am sure that is because we are now using AngularJS and they are being lazy loaded.

<requestHandler name="/dataimport" class="solr.DataImportHandler">
<lst name="defaults">
<str name="config">solr-data-config.xml</str>
</lst>
</requestHandler>

<requestHandler name="/dataimport-date-range" class="solr.DataImportHandler">
<lst name="defaults">
<str name="config">solr-data-date-range-config.xml</str>
</lst>
</requestHandler>

Shawn McCorkell thanks for joining, i'm not entirely sure if the first part of your comment is really the same issue? Obviously i can be closely related, but we're talking about not showing any handlers at all - unless you have one named dataimport (at least it looks that way)

They both show up named properly in the new UI but load the config only from the first handler /dataimport. when I click on /dataimport-date-range I see the last run time, details and config from /dataimport.

that would mean, when you have dataimport-date-range selected you can't trigger a import on that as well? given your description i'd guess it will trigger the (default) dataimport instead of the selected one. can you confirm that?

although i'm pretty sure you're right about lazy loading the list of handlers.

I noticed one thing. I select dataimport_0 and then run full import but request goes to dataimport instead of dataimport_0(screenshot5) . If dataimport does not exist and all dataimport handlers take a suffix, The message - Sorry, no dataimport-handler defined! - is displayed because of request goes to dataimport and it is not exist.I also added correct flow from old ui as screenshot6.

the underlying Angular service connects to /solr/$COLLECTION/dataimport, rather than /solr/$COLLECTION/$YOUR_DATAIMPORT_HANDLER. That's a bug.

Also, if it can't parse the XML, it fails, setting hasHandlers = false, showing the 'now handlers found' message. That's a bug also.

Patch that:

• fixes the dataimport service to use the correct URL for non /dataimport named handlers
• doesn't set hasHandlers=false if the config isn't XML

This patch is against trunk, but should work against other versions also. Apply it against the root of a Solr source checkout, then run 'ant server'. Once you've done that, you'll be able to use the normal bin/solr commands.

I guess it is a different issue, but still related to the changes in the new UI and probably due to the same bug as the original issue.

You are correct, you cannot trigger any other data import handler you have configured, they all read from the /dataimport config and show related info even though the name displayed is the name of the other handler.

There is no way to trigger your other handlers from the new UI unless you switch to the old one.

I believe the patch explained below will fix my issue as well.

I have the similar problem. I have two DIH's but in the new UI doesn't load the right configuration. In the new UI "dataimport-cacheable" and "dataimport" load data-config.xml

<!-- DataImportHandler -->
  <requestHandler name="/dataimport-cacheable" class="solr.DataImportHandler">
      <lst name="invariants">
          <str name="user">${datasource.user}</str> 
          <str name="password">${datasource.password}</str> 
          <str name="url">${datasource.url}</str> 
      </lst>
      <lst name="defaults">
          <str name="config">data-config-full.xml</str>
      </lst>
  </requestHandler>

  <requestHandler name="/dataimport" class="solr.DataImportHandler">
      <lst name="invariants">
          <str name="user">${datasource.user}</str> 
          <str name="password">${datasource.password}</str> 
          <str name="url">${datasource.url}</str> 
      </lst>
      <lst name="defaults">
          <str name="config">data-config.xml</str>
      </lst>
  </requestHandler>

This is the same issue I was mentioning above. It is related to this bug.

Please try the patch attached here. I never use DIH, so cannot really test it in earnest. If it works, I'll commit it and it can be a part of 6.0.1 or 6.1, which ever comes first.

I've used the patch in master branch and doesn't work fine. Now I can see in UI the right config for each DIH but when I try to execute full-import or delta-import doesn't work and no messages in solr.log (SOLR6.png)

solr version 6.0.1 has been released but the problem continues.

I have a serious lack of spare time at the moment, and on top of that, I've never used the DIH.

Please feel free to try and provide a patch, in the meantime.

Commit 6dd228c117cf058e08d1666396ad86758ec971c9 in lucene-solr's branch refs/heads/master from Alexandre Rafalovitch
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6dd228c ]

SOLR-8993: Admin UI support multiple DIH handlers
Updated Upayavira's patch to the master and fixed one missing parameter

Commit 1dd50d0747d5876309e8de76cc3981257850c5f5 in lucene-solr's branch refs/heads/master from Alexandre Rafalovitch
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1dd50d0 ]

SOLR-8993: Refresh status after we get handlers

Commit d7ba1e1efff48e2906cd6499570a3e25a90e6926 in lucene-solr's branch refs/heads/branch_6x from Alexandre Rafalovitch
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d7ba1e1 ]

SOLR-8993: Admin UI support multiple DIH handlers

Fixed and tested against modified db example. Used Upayavira's original patch with two small extra fixes (one missed parameter in the POST call, one unnecessary and erroneous status call).

Bulk close resolved issues after 6.2.0 release.