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

Pavel Micka commented on TIKA-1573:
-----------------------------------

Hi, because my restriction is all "binary mimetypes" (remove all text/*). This 
would make maintanance of my program harder, as I would need to check the 
definitions the list each time I increase the tika version. Also the file is 
embedded in tika.jar and the filename is hardcoded to MimeTypes.java...

> 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