[
https://issues.apache.org/jira/browse/TIKA-1657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14729480#comment-14729480
]
Tim Allison commented on TIKA-1657:
-----------------------------------
>> then I'd say that's what we ought to give them back!
I think we do want to give people the option of dumping the full list so that
they can discover parameter options that are currently effectively hidden. I
suspect once we make parameterization easier, we'll be adding many more
parameters to the parsers.
If we just give them what they gave us...the logic is impeccable and I was
initially hoping to do this, but what is the use case? Why would they want to
serialize a config that they already have?
>>{{--make-static-config}} Y, I like that quite a bit. Here's the config
>>file, don't do any service loading...process only this literally.
>>detectors, etc.
Y, take a look at the attachment from 20 min ago for the current output.
> Allow easier XML serialization of TikaConfig
> --------------------------------------------
>
> Key: TIKA-1657
> URL: https://issues.apache.org/jira/browse/TIKA-1657
> Project: Tika
> Issue Type: Improvement
> Reporter: Tim Allison
> Priority: Minor
> Fix For: 1.11
>
> Attachments: TIKA-1558-blacklist-effective.xml
>
>
> In TIKA-1418, we added an example for how to dump the config file so that
> users could easily modify it. I think we should go further and make this an
> option at the tika-core level with hooks for tika-app and tika-server. I
> propose adding a main() to TikaConfig that will print the xml config file
> that Tika is currently using to stdout.
> I'd like to put this into core so that e.g. Solr's DIH users can get by
> without having to download tika-app separately.
> There's every chance that I've not accounted for issues with dynamic loading
> etc. Also, I'd be ok with only having this available in tika-app and
> tika-server if there are good reasons.
> Feedback?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
