Uploaded image for project: 'Tika'
  1. Tika
  2. TIKA-1657

Allow easier XML serialization of TikaConfig

    Details

    • Type: Improvement
    • Status: Resolved
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.13
    • Component/s: None
    • Labels:
      None

      Description

      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?

      1. TIKA-1558-blacklist-effective.xml
        21 kB
        Tim Allison
      2. TIKA-1657v1.patch
        33 kB
        Tim Allison

        Issue Links

          Activity

          Hide
          davemeikle Dave Meikle added a comment -
          • Pushed to 1.11 following 1.10 release
          Show
          davemeikle Dave Meikle added a comment - Pushed to 1.11 following 1.10 release
          Hide
          tallison@mitre.org Tim Allison added a comment - - edited

          I looked at this a bit today, I'm now backing off to putting this only in tika-app with the "-c" option printing to STDOUT.

          In order to maintain round-trip-ability (xml -> TikaConfig -> xml), we'll need to store a few more things, which makes things a bit ugly...we may need to store the original "include" mime-types/parsers as well as the "exclude" mime-types/parsers...I think:

          1. getMimeRegistryResource() in TikaConfig (String, trivial)
          2. getServiceLoadingIsDynamic() in TikaConfig (boolean, trivial, just plumbing for pass through)...Does this only apply at the root level, er, child of <properties>?
          3. getExcludedTypes() in ParserDecorator (fairly trivial)
          4. getOriginalIncludedTypes() in ParserDecorator (trivial, but ugly)
          5. getExcludedParsers() in CompositeParser (fairly trivial)
          6. getOriginalIncludedParsers() in CompositeParser (trivial, but ugly)

          Does this look ok? Any other recommendations? Is there a more elegant way to represent a ParserDecorator in xml?

          Plan B: store only the excluded and assume that they were included in the "included"...

          There may be more items that arise as I progress on this, of course.

          I'd like to get this issue out of the way before working on TIKA-1508.

          Show
          tallison@mitre.org Tim Allison added a comment - - edited I looked at this a bit today, I'm now backing off to putting this only in tika-app with the "-c" option printing to STDOUT. In order to maintain round-trip-ability (xml -> TikaConfig -> xml), we'll need to store a few more things, which makes things a bit ugly...we may need to store the original "include" mime-types/parsers as well as the "exclude" mime-types/parsers...I think: getMimeRegistryResource() in TikaConfig (String, trivial) getServiceLoadingIsDynamic() in TikaConfig (boolean, trivial, just plumbing for pass through)...Does this only apply at the root level, er, child of <properties>? getExcludedTypes() in ParserDecorator (fairly trivial) getOriginalIncludedTypes() in ParserDecorator (trivial, but ugly) getExcludedParsers() in CompositeParser (fairly trivial) getOriginalIncludedParsers() in CompositeParser (trivial, but ugly) Does this look ok? Any other recommendations? Is there a more elegant way to represent a ParserDecorator in xml? Plan B: store only the excluded and assume that they were included in the "included"... There may be more items that arise as I progress on this, of course. I'd like to get this issue out of the way before working on TIKA-1508 .
          Hide
          tallison@mitre.org Tim Allison added a comment -

          Plan C: abandon the notion of full round-trip-ability and serialize only the "effective" TikaConfig...only serialize those parsers/supported mimes that are included/active.

          This will get rid of the need to store both included and excluded mimes and parsers. We'd still need 1. and 2. from above, but we could get rid of the 3-6.

          Show
          tallison@mitre.org Tim Allison added a comment - Plan C: abandon the notion of full round-trip-ability and serialize only the "effective" TikaConfig...only serialize those parsers/supported mimes that are included/active. This will get rid of the need to store both included and excluded mimes and parsers. We'd still need 1. and 2. from above, but we could get rid of the 3-6.
          Hide
          tallison@mitre.org Tim Allison added a comment - - edited

          Current version of tika config serialization for "effective config" run against TIKA-1558-blacklist.xml.

          <properties>
            <parsers>
              <parser class="org.apache.tika.parser.DefaultParser">
                <mime-exclude>image/jpeg</mime-exclude>
                <mime-exclude>application/pdf</mime-exclude>
                <parser-exclude class="org.apache.tika.parser.executable.ExecutableParser"/>
              </parser>
              <parser class="org.apache.tika.parser.EmptyParser">
                <mime>application/pdf</mime>
              </parser>
            </parsers>
          </properties>
          

          I couldn't easily get back to our old flat list of parsers. This is what I'm thinking for where we might be heading in 2.0. What do you think?
          If this looks good, I'll add a deserializer...we can use the legacy Tika loading mechanisms for any config files that don't have a version 2.0.

          Nick Burch, if you have a chance, please take a look. I know that you've added quite a bit of capability in this area, and I don't want to ruin it.

          The biggest changes:

          1. Hierarchical parsers are represented hierarchically (Composite,Decorator)...
          2. I've added a params section (TIKA-1508) for: str, int, long, float, double, boolean...see PDFParser and RTFParser
          3. There's room to grow for the potentially new type of CompositeParsers (fallback, etc) in the "type" attribute"
          Show
          tallison@mitre.org Tim Allison added a comment - - edited Current version of tika config serialization for "effective config" run against TIKA-1558 -blacklist.xml. <properties> <parsers> <parser class="org.apache.tika.parser.DefaultParser"> <mime-exclude>image/jpeg</mime-exclude> <mime-exclude>application/pdf</mime-exclude> <parser-exclude class="org.apache.tika.parser.executable.ExecutableParser"/> </parser> <parser class="org.apache.tika.parser.EmptyParser"> <mime>application/pdf</mime> </parser> </parsers> </properties> I couldn't easily get back to our old flat list of parsers. This is what I'm thinking for where we might be heading in 2.0. What do you think? If this looks good, I'll add a deserializer...we can use the legacy Tika loading mechanisms for any config files that don't have a version 2.0. Nick Burch , if you have a chance, please take a look. I know that you've added quite a bit of capability in this area, and I don't want to ruin it. The biggest changes: Hierarchical parsers are represented hierarchically (Composite,Decorator)... I've added a params section ( TIKA-1508 ) for: str, int, long, float, double, boolean...see PDFParser and RTFParser There's room to grow for the potentially new type of CompositeParsers (fallback, etc) in the "type" attribute"
          Hide
          gagravarr Nick Burch added a comment -

          I don't think we want a full flat list of parsers, unless the user originally gave us one. If the user specified the use of DefaultParser, then I'd say that's what we ought to give them back!

          (I could possibly see people wanting a --make-static-config option which replaces the DefaultParser with a composite parser holding all the found child parsers, but I wouldn't expect that to be the default)

          Does the code so far handle the other things you can put into a config file, eg detectors, translators, service loaders?

          Show
          gagravarr Nick Burch added a comment - I don't think we want a full flat list of parsers, unless the user originally gave us one. If the user specified the use of DefaultParser, then I'd say that's what we ought to give them back! (I could possibly see people wanting a --make-static-config option which replaces the DefaultParser with a composite parser holding all the found child parsers, but I wouldn't expect that to be the default) Does the code so far handle the other things you can put into a config file, eg detectors, translators, service loaders?
          Hide
          tallison@mitre.org Tim Allison added a comment - - edited

          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?

          --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.

          detectors, translators, optional mimeRegistry resource

          Y, take a look at the attachment from 20 min ago for the current output.

          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?

          Show
          tallison@mitre.org Tim Allison added a comment - - edited 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? --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. detectors, translators, optional mimeRegistry resource Y, take a look at the attachment from 20 min ago for the current output. 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?
          Hide
          gagravarr Nick Burch added a comment -

          Maybe we should make the options be something like -dump-active-config and -dump-static-config ?

          The former would give you back a config file of what Tika is currently using, excluding any bits it didn't understand, handy for people testing it out and/or starting from a default config. The later would remove the dynamic-ness, for people who have a working dynamic config that they want to make static + start removing things from.

          For service loading, we want both the dynamic flag, and the ignore/warn/throw setting

          Show
          gagravarr Nick Burch added a comment - Maybe we should make the options be something like - dump-active-config and -dump-static-config ? The former would give you back a config file of what Tika is currently using, excluding any bits it didn't understand, handy for people testing it out and/or starting from a default config. The later would remove the dynamic-ness, for people who have a working dynamic config that they want to make static + start removing things from. For service loading, we want both the dynamic flag, and the ignore/warn/throw setting
          Hide
          tallison@mitre.org Tim Allison added a comment - - edited

          Hmmm...not sure I see the difference.

          I do see a difference between:

          1. TIKA-1558-blacklist.xml (where you're saying: do the dynamic loading, but make some crucial tweaks)
          2. a dump of the full "effective" config. (I think this is your second option?)

          For service loading, we want both the dynamic flag, and the ignore/warn/throw setting

          Y, sorry, have them both.

          Show
          tallison@mitre.org Tim Allison added a comment - - edited Hmmm...not sure I see the difference. I do see a difference between: TIKA-1558 -blacklist.xml (where you're saying: do the dynamic loading, but make some crucial tweaks) a dump of the full "effective" config. (I think this is your second option?) For service loading, we want both the dynamic flag, and the ignore/warn/throw setting Y, sorry, have them both.
          Hide
          gagravarr Nick Burch added a comment - - edited

          Let's consider this config file:

          <properties>
            <parsers>
              <parser class="org.apache.tika.parser.DefaultParser">
                <mime-exclude>image/jpeg</mime-exclude>
                <mime-exclude>application/pdf</mime-exclude>
                <parser-exclude class="org.apache.tika.parser.executable.ExecutableParser"/>
                <parser-exclu class="org.apache.tika.parser.executable.ExecutableParser2"/>
              </parser>
              <parser class="org.apache.tika.parser.EmptyParser">
                <mime>application/pdf</mime>
                <no-mime>hello/world</no-mime>
              </parser>
            </parsers>
          </properties>
          

          With --dump-active-config you'd get what Tika was using of that, allowing you to spot what was and wasn't used, eg

          <properties>
            <parsers>
              <parser class="org.apache.tika.parser.DefaultParser">
                <mime-exclude>image/jpeg</mime-exclude>
                <mime-exclude>application/pdf</mime-exclude>
                <parser-exclude class="org.apache.tika.parser.executable.ExecutableParser"/>
              </parser>
              <parser class="org.apache.tika.parser.EmptyParser">
                <mime>application/pdf</mime>
              </parser>
            </parsers>
          </properties>
          

          Or, with --dump-static-config you'd get something like:

          <properties>
            <service-loader dynamic="false" />
            <translators/>
            <detectors>
             <detector class="org.apache.tika.parser.microsoft.POIFSContainerDetector"/>
             <detector class="org.apache.tika.parser.pkg.ZipContainerDetector"/>
             <detector class="org.gagravarr.tika.OggDetector"/>
             <detector class="org.apache.tika.mime.MimeTypes"/>
            </detectors>
            <parsers>
              <parser class="org.apache.tika.parser.CompositeParser">
                <mime-exclude>image/jpeg</mime-exclude>
                <mime-exclude>application/pdf</mime-exclude>
                <parser class="org.apache.tika.parser.asm.ClassParser"/>
                <parser class="org.apache.tika.parser.audio.AudioParser"/>
                <parser class="org.apache.tika.parser.audio.MidiParser"/>
                <parser class="org.apache.tika.parser.chm.ChmParser"/>
                <parser class="org.apache.tika.parser.code.SourceCodeParser"/>
                ... everything except executable ...
              </parser>
              <parser class="org.apache.tika.parser.EmptyParser">
                <mime>application/pdf</mime>
              </parser>
            </parsers>
          </properties>
          
          Show
          gagravarr Nick Burch added a comment - - edited Let's consider this config file: <properties> <parsers> <parser class= "org.apache.tika.parser.DefaultParser" > <mime-exclude>image/jpeg</mime-exclude> <mime-exclude>application/pdf</mime-exclude> <parser-exclude class= "org.apache.tika.parser.executable.ExecutableParser" /> <parser-exclu class= "org.apache.tika.parser.executable.ExecutableParser2" /> </parser> <parser class= "org.apache.tika.parser.EmptyParser" > <mime>application/pdf</mime> <no-mime>hello/world</no-mime> </parser> </parsers> </properties> With --dump-active-config you'd get what Tika was using of that, allowing you to spot what was and wasn't used, eg <properties> <parsers> <parser class= "org.apache.tika.parser.DefaultParser" > <mime-exclude>image/jpeg</mime-exclude> <mime-exclude>application/pdf</mime-exclude> <parser-exclude class= "org.apache.tika.parser.executable.ExecutableParser" /> </parser> <parser class= "org.apache.tika.parser.EmptyParser" > <mime>application/pdf</mime> </parser> </parsers> </properties> Or, with --dump-static-config you'd get something like: <properties> <service-loader dynamic= " false " /> <translators/> <detectors> <detector class= "org.apache.tika.parser.microsoft.POIFSContainerDetector" /> <detector class= "org.apache.tika.parser.pkg.ZipContainerDetector" /> <detector class= "org.gagravarr.tika.OggDetector" /> <detector class= "org.apache.tika.mime.MimeTypes" /> </detectors> <parsers> <parser class= "org.apache.tika.parser.CompositeParser" > <mime-exclude>image/jpeg</mime-exclude> <mime-exclude>application/pdf</mime-exclude> <parser class= "org.apache.tika.parser.asm.ClassParser" /> <parser class= "org.apache.tika.parser.audio.AudioParser" /> <parser class= "org.apache.tika.parser.audio.MidiParser" /> <parser class= "org.apache.tika.parser.chm.ChmParser" /> <parser class= "org.apache.tika.parser.code.SourceCodeParser" /> ... everything except executable ... </parser> <parser class= "org.apache.tika.parser.EmptyParser" > <mime>application/pdf</mime> </parser> </parsers> </properties>
          Hide
          tallison@mitre.org Tim Allison added a comment -

          Ah, ok, got it. Thank you. Y, current plan was just the latter. This only requires generating the xml based on the objects as they exist in the TikaConfig (with a few added items, mimeRepository path, etc).

          To get the first, we'd have to cache the xml nodes that the deserializer processed? Is the benefit worth the extra code?

          The user can see, with some effort admittedly, the same thing in the latter, no?

          Perhaps, start with the latter and add the former if needed?

          What's your take of the hierarchical handling in the attached?

          Show
          tallison@mitre.org Tim Allison added a comment - Ah, ok, got it. Thank you. Y, current plan was just the latter. This only requires generating the xml based on the objects as they exist in the TikaConfig (with a few added items, mimeRepository path, etc). To get the first, we'd have to cache the xml nodes that the deserializer processed? Is the benefit worth the extra code? The user can see, with some effort admittedly, the same thing in the latter, no? Perhaps, start with the latter and add the former if needed? What's your take of the hierarchical handling in the attached?
          Hide
          tallison@mitre.org Tim Allison added a comment -

          First very rough draft of code...

          Will need more input on whether the hierarchical approach makes sense for composite, decorator, delegating (not yet handled!) parsers.

          Show
          tallison@mitre.org Tim Allison added a comment - First very rough draft of code... Will need more input on whether the hierarchical approach makes sense for composite, decorator, delegating (not yet handled!) parsers.
          Hide
          hudson Hudson added a comment -

          UNSTABLE: Integrated in tika-trunk-jdk1.7 #853 (See https://builds.apache.org/job/tika-trunk-jdk1.7/853/)
          TIKA-1657 Update the example of dumping a Tika Config to support different output modes, for Translators and Detectors (nick: http://svn.apache.org/viewvc/tika/trunk/?view=rev&rev=1704934)

          • /tika/trunk/tika-core/src/main/java/org/apache/tika/language/translate/DefaultTranslator.java
          • /tika/trunk/tika-example/src/main/java/org/apache/tika/example/DumpTikaConfigExample.java
          • /tika/trunk/tika-example/src/test/java/org/apache/tika/example/DumpTikaConfigExampleTest.java
          Show
          hudson Hudson added a comment - UNSTABLE: Integrated in tika-trunk-jdk1.7 #853 (See https://builds.apache.org/job/tika-trunk-jdk1.7/853/ ) TIKA-1657 Update the example of dumping a Tika Config to support different output modes, for Translators and Detectors (nick: http://svn.apache.org/viewvc/tika/trunk/?view=rev&rev=1704934 ) /tika/trunk/tika-core/src/main/java/org/apache/tika/language/translate/DefaultTranslator.java /tika/trunk/tika-example/src/main/java/org/apache/tika/example/DumpTikaConfigExample.java /tika/trunk/tika-example/src/test/java/org/apache/tika/example/DumpTikaConfigExampleTest.java
          Hide
          gagravarr Nick Burch added a comment -

          A couple of things to say up front:

          • I agree with Tim's patch that most of the logic for this should really be in core, in the config package
          • I agree with Tim that the Tika App would be a better place to expose this

          That said... As of r1705191, DumpTikaConfigExample should now support 3 modes for most kinds of things. It has Minimal, which is anything that isn't a default. It has Current, which shows what the defaults are. It has Static, which turns Defaults into full lists. It handles some (but not all) kinds of decorations. It needs more unit tests... It includes some bits of Tim's patch

          One thing it doesn't have is the parameter parsing / writing out, as current Tika config core lacks that too. Once we work out how to add general parameters to the Tika Config without re-inventing Spring baldy (see another jira for that effort!), we'll need to include that part of Tim's patch too.

          Assuming everyone likes + understands + agrees with the approach I've taken in the expanded example, I'd suggest we look at pulling most of that logic out (as Tim did in his patch), push it to core, add it to the app, and replace the example with a thin shim. Then add more tests, then look at the other decorations etc needed

          Show
          gagravarr Nick Burch added a comment - A couple of things to say up front: I agree with Tim's patch that most of the logic for this should really be in core, in the config package I agree with Tim that the Tika App would be a better place to expose this That said... As of r1705191, DumpTikaConfigExample should now support 3 modes for most kinds of things. It has Minimal, which is anything that isn't a default. It has Current, which shows what the defaults are. It has Static, which turns Defaults into full lists. It handles some (but not all) kinds of decorations. It needs more unit tests... It includes some bits of Tim's patch One thing it doesn't have is the parameter parsing / writing out, as current Tika config core lacks that too. Once we work out how to add general parameters to the Tika Config without re-inventing Spring baldy (see another jira for that effort!), we'll need to include that part of Tim's patch too. Assuming everyone likes + understands + agrees with the approach I've taken in the expanded example, I'd suggest we look at pulling most of that logic out (as Tim did in his patch), push it to core, add it to the app, and replace the example with a thin shim. Then add more tests, then look at the other decorations etc needed
          Hide
          tallison@mitre.org Tim Allison added a comment -

          Thank you, Nick Burch, for moving this forward...and for code that is far more elegant than mine, as usual.

          I should have time by mid next week to get back to this. But please move forward if you have time+interest.

          This is not a blocker on 1.11 imho.

          Onward!

          Show
          tallison@mitre.org Tim Allison added a comment - Thank you, Nick Burch , for moving this forward...and for code that is far more elegant than mine, as usual. I should have time by mid next week to get back to this. But please move forward if you have time+interest. This is not a blocker on 1.11 imho. Onward!
          Hide
          hudson Hudson added a comment -

          UNSTABLE: Integrated in tika-trunk-jdk1.7 #918 (See https://builds.apache.org/job/tika-trunk-jdk1.7/918/)
          TIKA-1657 move xmlification of TikaConfig to tika-core. Thank you, (tallison: rev 3aa1dca4eef13de99b83989010fe02bfd391b378)

          • tika-example/src/main/java/org/apache/tika/example/DumpTikaConfigExample.java
          • tika-app/src/test/resources/test-data/tika-config2.xml
          • tika-app/src/main/java/org/apache/tika/cli/TikaCLI.java
          • tika-example/src/test/java/org/apache/tika/example/DumpTikaConfigExampleTest.java
          • tika-core/src/main/java/org/apache/tika/config/TikaConfigSerializer.java
          • tika-app/src/test/java/org/apache/tika/cli/TikaCLITest.java
          • tika-core/src/test/java/org/apache/tika/config/TikaConfigSerializerTest.java
            TIKA-1657 move xmlification of TikaConfig to tika-core. Thank you, (tallison: rev 5a341071532ac950efeaad222afe3e4a33bb9bee)
          • CHANGES.txt
          Show
          hudson Hudson added a comment - UNSTABLE: Integrated in tika-trunk-jdk1.7 #918 (See https://builds.apache.org/job/tika-trunk-jdk1.7/918/ ) TIKA-1657 move xmlification of TikaConfig to tika-core. Thank you, (tallison: rev 3aa1dca4eef13de99b83989010fe02bfd391b378) tika-example/src/main/java/org/apache/tika/example/DumpTikaConfigExample.java tika-app/src/test/resources/test-data/tika-config2.xml tika-app/src/main/java/org/apache/tika/cli/TikaCLI.java tika-example/src/test/java/org/apache/tika/example/DumpTikaConfigExampleTest.java tika-core/src/main/java/org/apache/tika/config/TikaConfigSerializer.java tika-app/src/test/java/org/apache/tika/cli/TikaCLITest.java tika-core/src/test/java/org/apache/tika/config/TikaConfigSerializerTest.java TIKA-1657 move xmlification of TikaConfig to tika-core. Thank you, (tallison: rev 5a341071532ac950efeaad222afe3e4a33bb9bee) CHANGES.txt
          Hide
          tallison@mitre.org Tim Allison added a comment -

          I moved Nick's code from tika-example to tika-core, and I made it available via tika-app.

          I added a handful of tests, but we'll need more...new tickets as needed.

          Also, we'll need to figure out how to store the parameters for the ExecutorService so that we can dump that information...new ticket.

          Show
          tallison@mitre.org Tim Allison added a comment - I moved Nick's code from tika-example to tika-core, and I made it available via tika-app. I added a handful of tests, but we'll need more...new tickets as needed. Also, we'll need to figure out how to store the parameters for the ExecutorService so that we can dump that information...new ticket.
          Hide
          hudson Hudson added a comment -

          FAILURE: Integrated in tika-2.x #43 (See https://builds.apache.org/job/tika-2.x/43/)
          TIKA-1657: move serialization of TikaConfig to tika-core and enable (tallison: rev 1d53ff4cf1619bad1ee00ecae7c59f0be921e5b7)

          • tika-core/src/test/java/org/apache/tika/config/TikaConfigSerializerTest.java
          • tika-app/src/test/resources/test-data/tika-config2.xml
          • CHANGES.txt
          • tika-core/src/main/java/org/apache/tika/config/TikaConfigSerializer.java
          • tika-app/src/main/java/org/apache/tika/cli/TikaCLI.java
          • tika-example/src/test/java/org/apache/tika/example/DumpTikaConfigExampleTest.java
          • tika-app/src/test/java/org/apache/tika/cli/TikaCLITest.java
          • tika-example/src/main/java/org/apache/tika/example/DumpTikaConfigExample.java
          Show
          hudson Hudson added a comment - FAILURE: Integrated in tika-2.x #43 (See https://builds.apache.org/job/tika-2.x/43/ ) TIKA-1657 : move serialization of TikaConfig to tika-core and enable (tallison: rev 1d53ff4cf1619bad1ee00ecae7c59f0be921e5b7) tika-core/src/test/java/org/apache/tika/config/TikaConfigSerializerTest.java tika-app/src/test/resources/test-data/tika-config2.xml CHANGES.txt tika-core/src/main/java/org/apache/tika/config/TikaConfigSerializer.java tika-app/src/main/java/org/apache/tika/cli/TikaCLI.java tika-example/src/test/java/org/apache/tika/example/DumpTikaConfigExampleTest.java tika-app/src/test/java/org/apache/tika/cli/TikaCLITest.java tika-example/src/main/java/org/apache/tika/example/DumpTikaConfigExample.java
          Hide
          thammegowda Thamme Gowda added a comment -

          Tim AllisonNick BurchChris A. Mattmann
          I am wondering if you have considered the option of creating model classes for all the configuration elements, and then using JAXB to easily convert to-and-from XML for (De)Serialization.?

          Show
          thammegowda Thamme Gowda added a comment - Tim Allison Nick Burch Chris A. Mattmann I am wondering if you have considered the option of creating model classes for all the configuration elements, and then using JAXB to easily convert to-and-from XML for (De)Serialization.?

            People

            • Assignee:
              Unassigned
              Reporter:
              tallison@mitre.org Tim Allison
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development