[ 
https://issues.apache.org/jira/browse/TIKA-1573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14356856#comment-14356856
 ] 

Nick Burch commented on TIKA-1573:
----------------------------------

If you only want a handful of types, why not just replace the mimetypes xml 
file with a small one containing just your chosen few types and none others?

> Not possible to restrict default mime types
> -------------------------------------------
>
>                 Key: TIKA-1573
>                 URL: https://issues.apache.org/jira/browse/TIKA-1573
>             Project: Tika
>          Issue Type: Improvement
>            Reporter: Pavel Micka
>            Priority: Minor
>              Labels: performance
>
> I am facing the following problem. I am using MagicNumber detector, but the 
> detection is slow for my purposes, so I have decided to limit the number of 
> detected types. However this is not easily possible as: 
>  * Mimetypes does not have any remove method.
>  * getDefaultMimeTypes method by default load the full set
>  * MimeTypes constructor does not accept parameters (mimes with magics)
>  * method add is package friendly (so one must construct the wrapper in the 
> same package, which is awkward)
>  * MimeTypes class is final, so it does not allow to subclass it a improve 
> the implementation in object oriented way
> My workaround was to force the expected implementation (public add) with 
> reflection:
>                     Method addMethod = 
> decrMimeTypes.getClass().getDeclaredMethod("add", MimeType.class);
>                     addMethod.setAccessible(true);
>                     addMethod.invoke(myMimeTypes, 
> defaultMimeTypes.getRegisteredMimeType(m.toString()));
> I can imagine that the current implementation is done this way to be 
> immutable, but this can also achieved with parametrized constructor (point 3) 
> with no effect on immutability of the class. Or with explicit flag (set by 
> method call) that would disallow any further object modifications.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to