[
https://issues.apache.org/jira/browse/BATIK-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16579812#comment-16579812
]
Erich Schubert commented on BATIK-1203:
---------------------------------------
[~ssteiner1]: Here is a unit test in that horrible legacy test framework that
Junit uses:
{{ @Override}}
{{ public boolean runImplBasic() throws Exception {}}
{{ ImageTagRegistry ir = new ImageTagRegistry();}}
{{ // Add a new registry entry with a HIGHER priority first}}
{{ ir.register(new AbstractRegistryEntry("Unit test", 100, "working",
"application/working") {});}}
{{ // Ensure the first one is present:}}
{{
assertTrue(ir.getRegisteredMimeTypes().contains("application/working"));}}
{{ // Ensure the second is NOT YET present:}}
{{ assertTrue(false ==
ir.getRegisteredMimeTypes().contains("application/missing"));}}
{{ // Add a new registry entry with a LOW priority later}}
{{ ir.register(new AbstractRegistryEntry("Unit test", 1, "missing",
"application/missing") {});}}
{{ // This one still works - this is expected:}}
{{
assertTrue(ir.getRegisteredMimeTypes().contains("application/working"));}}
{{ // The second was not added because of BATIK-1203.}}
{{
assertTrue(ir.getRegisteredMimeTypes().contains("application/missing"));}}
{{ return true;}}
{{ }}}
The full patch is at https://github.com/apache/batik/pull/15
As you can see, adding registry entries of _lower_ priority after populating
the cache with getRegisteredMimeTypes does not work.
The trivial bug fix is still here. Maybe it now no longer is ignored, as there
is a test case now: https://github.com/apache/batik/pull/4
> ImageTagRegistry forgets to reinitialize cache
> ----------------------------------------------
>
> Key: BATIK-1203
> URL: https://issues.apache.org/jira/browse/BATIK-1203
> Project: Batik
> Issue Type: Bug
> Reporter: Erich Schubert
> Priority: Major
>
> Pull request is here:
> https://github.com/apache/batik/pull/4
> ImageTagRegistry fails to clear the cache via:
> extensions = null;
> mimeTypes = null;
> whenever entries are NOT inserted in descending priority. Only if the "if"
> condition never triggers the cache is correctly reset.
> The reason why this went largely unnoticed is that when the entries are
> loaded initially, the cache is still null. So it usually gets initialized
> only once. But because of this bug, you cannot later register a
> higher-priority handler yourself.
> To test, make sure the cache is populated before calling "register". Then
> register a low priority entry.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
