[
https://issues.apache.org/jira/browse/LOG4J2-997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14521175#comment-14521175
]
Gary Gregory commented on LOG4J2-997:
-------------------------------------
At this, point I would love to RERO and get 2.3 out the door, so we can ponder
this some more. If someone wants to fiddle with fixing this now for 2.3 and
commit within the current API, I certainly will not complain! :-)
We can always revisit after 2.3. The instance checks for CompositeFilter that
are scattered throughout is not a good code smell.
Even if there are tons of custom filters, only callers of {{getFilter()}}
_might_ be affected. We could leave {{getFilter()}} in place and _add_
{{getFilters()}}.
How would fixing the API by adding {{getFilters()}} break custom filters?
It's very late in the PST, I might not be thinking straight...
> removeFilter() in AbstractFilterable does not remove filter
> -----------------------------------------------------------
>
> Key: LOG4J2-997
> URL: https://issues.apache.org/jira/browse/LOG4J2-997
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.2
> Reporter: Maytee Chinavanichkit
>
> Add two filters to a class that implements AbstractFilterable. Try to remove
> one of the two filters; nothing is removed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
