[
https://issues.apache.org/jira/browse/TIKA-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris A. Mattmann updated TIKA-490:
-----------------------------------
Comment: was deleted
(was: Comment from Jan on the ML:
{quote}
My rationale for the override part is as follows:
The default properties file will be embedded within tika-xx.jar
I assume most people are not keen to unpack and repack JARs to make a config
change.
We COULD put a similar named properties file at another location, but then the
user
needs to make sure that location is EARLIER in classpath than the JAR file.
In the case of e.g. Solr (Tomcat, Jetty..) it is not obvious how to ensure this,
and to avoid any confusion about class-loader peculiarities, it's more
straight-forward
to look for an override file.
Take the Solr example. The user would then put the properties file along with
his new language profiles in a folder $SOLR_HOME/lib/org/apache/tika/language/
{quote})
> Support for adding language profiles dynamically
> ------------------------------------------------
>
> Key: TIKA-490
> URL: https://issues.apache.org/jira/browse/TIKA-490
> Project: Tika
> Issue Type: Improvement
> Components: languageidentifier
> Affects Versions: 0.7
> Reporter: Jan Høydahl
> Assignee: Chris A. Mattmann
> Fix For: 0.8
>
> Attachments: TIKA-490.patch, TIKA-490.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Currently the Tika LanguageIdentifier loads language profiles thorugh a
> hardcoded static block in the java code.
> It would be better to make this configurable, so you could add your own
> languages without recompiling.
> Suggested approach:
> Remove the static code block loading all languages. Instead look for a
> tika.languageidentification.properties file on classpath.
> Now the user can simply make his/her own (additional) language profile files,
> put them on the classpath together with a properties file and off you go!
> Also, once you make it configurable, there might be an issue of having the
> profiles as static members, as you will force the same behaviour for the
> whole VM. A static Map of Maps could solve this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
