Re: Another Elasticsearch patch to allow the long URI

Hi, Karl. Karl Wright wrote: >I have now updated (I think) everything that this patch actually has, save >for one deprecated field substitution (the "types" field is now the "doc_" I've confirmed the updated sources via git://git.apache.org/manifoldcf.git, to find some problem in the following

Re: Another Elasticsearch patch to allow the long URI

Hi, Karl. Karl Wrightさんは書きました: >field). I would like to know more about this. Does the "types" field no >longer work? Should we send both, in order to be sure that the connector >works with most versions of ElasticSearch? Please help clarify so that I >can finish this off. The "types" field

Re: Another Elasticsearch patch to allow the long URI

Hi, Karl. Karl Wright wrote: >Hi - I'm still waiting for this patch to be attached to a ticket. That is >the only way I believe we're allowed to accept it legally. Do you ask me to send the patch to the JIRA ticket? I can't access the JIRA because of our firewall. Sorry. What can I do without

Re: Another Elasticsearch patch to allow the long URI

Hi, Karl. Karl Wrightさんは書きました: >I agree it is unlikely that the JDK will lose support for SHA-1 because it >is used commonly, as is MD5. So please feel free to use it. I know. I think that SHA-1 is better on the whole. I don't care that apache-manifoldcf-elastic-id-2.patch.gz is discarded.

Re: Another Elasticsearch patch to allow the long URI

Hi, There. Shirai Takashi/ 白井隆 wrote: >I can use SHA-256 with Elasticsearch connector. I've prepared the patch to support SHA-256. It minimizes changes, to avoid the global effects. It seems unbeautiful to include the try-catch clause. I can't decide which is better. Nintendo, Co.,

Re: Another Elasticsearch patch to allow the long URI

Hi, Horn. Jörn Franke wrote: >Makes sense I don't think that it's easy. >>> Maybe use SHA-256 or later. SHA-1 is obsolete and one never knows when it >>> will be removed from JDK. I also know SHA-1 is dangerous. Someone can generate the string which is hashed into the same SHA-1 to pretend

Re: Another Elasticsearch patch to allow the long URI

Hi, Karl. Karl Wright wrote: >Backwards compatibility means that we very likely have to >use the hash approach, and not use the decoding approach. Do you object to the decoding? It may be useless for the users with the alphabetical language. But it's useful for the users with the multibyte

Re: Another Elasticsearch patch to allow the long URI

Hi, Jorn. Jörn Franke wrote: >Maybe use SHA-256 or later. SHA-1 is obsolete and one never knows when it will >be removed from JDK. SHA-1 is used in the ManifoldCF existent class. (org.apache.manifoldcf.core.system.ManifoldCF) If "SHA" is replaced "SHA-256" in this class, the default algorism is

Another Elasticsearch patch to allow the long URI

Hi, there. I've found another trouble in Elasticsearch connector. Elasticsearch output connector use the URI string as ID. Elasticsearch allows the length of ID no more than 512 bytes. If the URL length is too long, it causes HTTP 400 error. I prepare two solutions with this attached patch. The

Re: Patch contribution to support Ingest-Attachment for Elasticsearch

Hi, there. Shirai Takashi wrote: >ManifoldCF can use mapping-attachments plugin for Elasticsearch connector. >But it is obsolete, to recommend ingest-attachment plugin instead. >I try to support this plugin with the attached patch. Sorry, I have some mistake with this patch. Please replace it

Patch contribution to support Ingest-Attachment for Elasticsearch

Hi, there. ManifoldCF can use mapping-attachments plugin for Elasticsearch connector. But it is obsolete, to recommend ingest-attachment plugin instead. I try to support this plugin with the attached patch. The patch is made for 2.18. Though I can also make the patch by 'git format-patch' if