[
https://issues.apache.org/jira/browse/LOG4J2-1531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15429453#comment-15429453
]
Ralph Goers edited comment on LOG4J2-1531 at 8/20/16 5:35 PM:
--------------------------------------------------------------
I like what this patch is trying to do, however, I have some concerns.
1. When would it ever be desirable that the value of a Node is not a String?
From a programmatic perspective I am not sure why you would want anything else.
2. Do we really need to support anything other than a Function? Although it
would be nice to be able to use Java 8's Function interface I would imagine we
could just use our own, more or less as you have done.
3.PluginAttributes are Strings and really should stay that way. When a Plugin
has a parameter that is a complex object it is represented by a PluginElement,
which is a complex object represented by its own Node. So a PluginAttribute (or
PluginFunction?) really should be a PluginElement where the PluginType has the
Object already populated. With that I believe most of these changes are
unnecessary.
If you could try something along those lines that would be great. Otherwise I
can do it but I have been swamped at my $day job and am not sure how long it
will be before I have time.
was (Author: ralph.go...@dslextreme.com):
I like what this patch is trying to do, however, I have some concerns.
1. When would it ever be desirable that the value of a Node is not a String?
From a programmatic perspective I am not sure why you would want anything else.
2. Do we really need to support anything other than a Function? Although it
would be nice to be able to use Java 8's Function interface I would imagine we
could just use our own, more or less as you have done.
3.PluginAttributes are Strings and really should stay that way. When a Plugin
has a parameter that is a complex object it is represented by a PluginElement,
which is a complex object represented by its own Node. So a PluginAttribute (or
PluginFunction?) really should be a PluginElement where the PluginType has the
Object already populated. With that I believe most of these changes are
unnecessary.
> Change attribute and component values from String to Object
> -----------------------------------------------------------
>
> Key: LOG4J2-1531
> URL: https://issues.apache.org/jira/browse/LOG4J2-1531
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.6.2
> Reporter: Roger Kapsi
> Attachments: log4j2-1531-1.0.patch
>
>
> I was looking into creating a ConfigurationFactory/Builder that is backed by
> a Clojure DSL. It works rather beautifully until I tried to create a filter
> that is backed by a Clojure function. There is literally no way to pass
> arbitrary objects into a PluginFactory. All component values and attributes
> are assumed to be Strings.
> {code:java}
> (configuration
> (appender "stdout" "CONSOLE"
> (layout "PatternLayout"
> (attribute "pattern" "%d [%t] %-5level: %msg%n"))
> (filter "ClojureFilter"
> ;; This LoC doesn't work: addAttribute(key, value)
> ;; will store the toString() of the value. Bummer.
> ;; I'd the so easy and beautiful if it didn't.
> (attribute "fn" (fn [logger & more] (println logger)))))
>
> (logger "TestLogger" Level/INFO
> (appender-ref "rolling")
> (attribute "additivity" false))
> (root-logger Level/DEBUG
> (appender-ref "rolling")))
> {code}
> {code:java}
> @Plugin(name = "ClojureFilter", category = Node.CATEGORY, elementType =
> Filter.ELEMENT_TYPE, printObject = true)
> class ClojureFilter extends AbstractFilter {
> @PluginFactory
> public static ClojureFilter createFilter(
> @PluginAttribute("fn") IFn fn, ...) {
> return new ClojureFilter(fn, ...);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
