[
https://issues.apache.org/jira/browse/TIKA-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting updated TIKA-21:
------------------------------
Attachment: TIKA-21.patch
Attached a proposed patch to simplify the config classes and get rid of the
static variables.
The patch moves the parsing of the XML configuration file to the LiusConfig,
ParserConfig, and Content constructors and makes all these objects immutable
except for the value properties of Content instances.
> LiusConfig supports multiple config files, but parser config list is static.
> ----------------------------------------------------------------------------
>
> Key: TIKA-21
> URL: https://issues.apache.org/jira/browse/TIKA-21
> Project: Tika
> Issue Type: Bug
> Components: general
> Affects Versions: 0.1-incubator
> Reporter: Keith R. Bennett
> Fix For: 0.1-incubator
>
> Attachments: TIKA-21.patch
>
>
> The LiusConfig class keeps an internal map whose keys are configuration
> specifications (now filespec Strings, possibly URL's in the future) and whose
> values are LiusConfig objects. When an instance of a given key is requested,
> and that key has not yet been processed, it is parsed into an object that
> will be available from the map from then on. During that parse, the content
> of the static List<ParserConfig> parsersConfig is overwritten. Here is how:
> At the end of populateConfig(), a static method, there is a call:
> tc.setParsersConfigs(parsersConfigs)
> 'tc' seems to be an instance kept around solely to accomplish this call.
> setParsersConfig() is defined as:
> public void setParsersConfigs(List<ParserConfig> parsersConfigs) {
> this.parsersConfigs = parsersConfigs;
> }
> However, the list variable itself, parsersConfigs, is defined as static:
> private static List<ParserConfig> parsersConfigs;
> ... so the result is that it is overwritten at each parse.
> If I understand correcty the intent, parsersConfig should be nonstatic, since
> different configurations could specify different parsers. If this is the
> case, then it would probably make sense to make the populateConfig method
> nonstatic, and create a private constructor:
> private LiusConfig(Document document) {
> populateConfig(document);
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
