[
https://issues.apache.org/jira/browse/LOG4J2-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125154#comment-14125154
]
Scott Harrington commented on LOG4J2-745:
-----------------------------------------
I've compiled the git branch called 'LOG4J2-745' and confirmed I get the
expected collision-detection warnings.
However upon further reflection, the "Sorry, Dave, I can't let you do that"
warning does not seem appropriate. It would have been appropriate if we
actually implemented a way for log4j-core plugins to always have special status
ahead of user-defined plugins, however my actual solution here was to honor
plugins strictly in the order they are encountered in the CLASSPATH. Indeed I'm
placing my JAR at the front to deliberately override the built-in %d converter
(for a FastDateFormat implementation, which as it turns out I've noticed other
folks have suggested recently on the ML as an obvious improvement over
SimpleDateFormat).
> Plugins can cause ConverterKeys collisions with unpredictable results
> ---------------------------------------------------------------------
>
> Key: LOG4J2-745
> URL: https://issues.apache.org/jira/browse/LOG4J2-745
> Project: Log4j 2
> Issue Type: Improvement
> Components: Plugins
> Affects Versions: 2.0.2
> Reporter: Scott Harrington
> Assignee: Matt Sicker
> Priority: Blocker
> Attachments: LOG4J2-745-patch-r1617171.txt, Safer_PluginManager.patch
>
>
> If I create a Converter plugin with ConverterKeys of "d" or "m" then there
> will be a collision with the built-in DatePatternConverter or
> MessagePatternConverter.
> It is unpredictable which plugin gets used.
> I see two resolutions:
> (1) detect collisions in PatternParser and emit a warning so we know which
> implementation will be used
> (2) use whichever Log4j2Plugins.dat appeared first in the CLASSPATH
> Predictable iteration order is usually accomplished by replacing HashMaps
> with LinkedHashMaps. Could easily do this for thie PluginManager.plugins
> field. But PluginRegistry uses a ConcurrentHashMap.
> Is there a good reason to use ConcurrentHashMaps in PluginRegistry? It
> doesn't really give you any concurrency -- a caller to
> PluginManager.getPlugins could see a partially-loaded map if collectPlugins
> was still running. Why not synchronize collectPlugins and/or loadPlugins, and
> force any concurrent caller to getPlugins to wait until the loading was
> complete.
> I would give it a stab but I see other more important changes are probably
> underway for LOG4J2-741 and LOG4J2-673 and this can probably wait.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
