[
https://issues.apache.org/jira/browse/TIKA-1657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14729480#comment-14729480
]
Tim Allison edited comment on TIKA-1657 at 9/3/15 6:10 PM:
-----------------------------------------------------------
bq. then I'd say that's what we ought to give them back!
I think we do want to give people at least 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?
bq. {{--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. Or we could specify that in the config.
bq. detectors, translators, optional mimeRegistry resource
Y, take a look at the attachment from 20 min ago for the current output.
bq. service loaders?
The dynamic loading param y. Otherwise, n. I haven't done the deserialization
yet. What do we want to specify about service loaders in the config?
was (Author: [email protected]):
bq. then I'd say that's what we ought to give them back!
I think we do want to give people at least 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?
bq. {{--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. Or we could specify that in the config.
bq. 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)
