[
https://issues.apache.org/jira/browse/LOG4J2-2977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17256085#comment-17256085
]
Matt Sicker edited comment on LOG4J2-2977 at 12/29/20, 5:50 PM:
----------------------------------------------------------------
Few things:
* The set/with naming convention is an inconsistency by accident; in master,
they were all standardized to setFoo.
* Builder classes are mostly hand-written or generated and subsequently
modified. No magic code generation here.
* The way plugin builders currently work is generally via the builder class's
fields more so than the methods (more specifically, it works via whatever
program element is annotated with the plugin annotation; you can follow that
annotation to a meta-annotation describing the implementation binding strategy
for converting a configuration node into the injected element); the methods are
provided for allowing fluent builders (mostly in unit tests, but I'd imagine
that users use them for something else as well). Default values for builder
classes are whatever the field value is upon construction (when using parameter
injection from factory methods, default values have to be specified in the
annotation instead). If you use the parameter injection annotations in a
builder class, you can probably specific a default value via the annotation,
but I haven't tested that.
* Documentation: in my ideal world, we'd be able to document plugin options
and examples directly in the javadoc for the plugin classes and test classes.
However, we generally document these options in the manual as well as adding
javadoc for the factory method or builder methods.
Let me know if you'd like more info about anything here as it's not as simple
as I intend it to be eventually (the dependency injection API overhaul).
was (Author: jvz):
Few things:
* The set/with naming convention is an inconsistency by accident; in master,
they were all standardized to setFoo.
* Builder classes are mostly hand-written or generated and subsequently
modified. No magic code generation here.
* The way plugin builders currently work is generally via the builder class's
fields more so than the methods (more specifically, it works via whatever
program element is annotated with the plugin annotation; you can follow that
annotation to a meta-annotation describing the implementation binding strategy
for converting a configuration node into the injected element); the methods are
provided for allowing fluent builders (mostly in unit tests, but I'd imagine
that users use them for something else as well). Default values for builder
classes are whatever the field value is when build() is called (when using
parameter injection from factory methods, default values have to be specified
in the annotation instead). If you use the parameter injection annotations in a
builder class, you can probably specific a default value via the annotation,
but I haven't tested that.
* Documentation: in my ideal world, we'd be able to document plugin options
and examples directly in the javadoc for the plugin classes and test classes.
However, we generally document these options in the manual as well as adding
javadoc for the factory method or builder methods.
> Documentation for code to create a FileAppender is out of date
> --------------------------------------------------------------
>
> Key: LOG4J2-2977
> URL: https://issues.apache.org/jira/browse/LOG4J2-2977
> Project: Log4j 2
> Issue Type: Improvement
> Components: Configuration
> Affects Versions: 2.13.3
> Environment: Please update the documentation with code that
> successfully can create a FileAppender
> Reporter: Bryan Pauquette
> Assignee: Ron Grabowski
> Priority: Minor
> Attachments: image-2020-12-14-09-23-04-411.png
>
>
> [http://logging.apache.org/log4j/2.x/manual/customconfig.html#AddingToCurrent]
>
> Appears to be out of date because the createLayout method is no longer
> available.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
