[
https://issues.apache.org/jira/browse/LOG4J2-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14718118#comment-14718118
]
Ralph Goers commented on LOG4J2-952:
------------------------------------
Wow your update is long!
1. I have shown two ways to use the assembler. I implemented the
PropertiesConfiguration with it just as an example of how it could be used. The
CustomConfiguration is a way to do it purely programmatically. There is no
reason Configurator couldn't have an initialize method as you have shown.
However, you will get the error that says no configuration was provided since
the initial configuration is created when you call getContext(). To avoid that
you MUST use a ConfigurationFactory.
2. I wanted to expose an API that we could guarantee and hide the
implementation. I did not want users to use DefaultConfigurationAssembler
directly. The most logical way to do that seemed to me to put the methods in
the ConfigurationFactory class.
3. As I said previously, I didn't use "Builder" because I thought it gave the
wrong impression. I would expect the build() method of a Builder to return the
actual object. The assembler returns Components, not Appenders, Loggers, etc. I
also expect that when Matt returns he may want to continue his work on creating
"real" builders for everything. I did not want to raise the potential for a
conflict with that. "Assembler" seemed like it conveyed a similar enough
meaning to Builder and frankly, it was the only other word I could think of.
4. I agree with everything else down to "This comment applies to other APIs". I
will try making those changes and see how it works out.
5. The only argument against using the concrete types is probably weak. They
all have to be converted back to Strings as that is all Nodes can accept during
the first pass of construction. AbstractConfiguration creates the actual
objects based on the Plugin factory/builder. Obviously, the ComponentAssembler
can only accept Strings.
6. Generics gave me tons of headaches trying to eliminate all the warning
messages. In the end it was impossible and I just had to suppress them. So I
have no idea at this point if changing <T> to <> is going to cause one to pop
back up. FWIW, I noticed a change you made yesterday to the Configuration class
caused warnings to pop up all over the place. I had to modify
AbstractConfiguration to suppress the warning there to make them all go away.
7. I think there is an error in your statement above. Yes, the intention is to
make the API public and give it the same guarantee that we have to log4j-api.
The only impl class users should use is to extend AssembledConfiguration as
PropertiesConfiguration does.
> FAQ: How do I configure log4j2 programmatically in code without a
> configuration file?
> -------------------------------------------------------------------------------------
>
> Key: LOG4J2-952
> URL: https://issues.apache.org/jira/browse/LOG4J2-952
> Project: Log4j 2
> Issue Type: Bug
> Components: API, Configurators, Documentation
> Affects Versions: 2.1
> Reporter: Joe Merten
> Attachments: LOG4J2-952-2.patch, LOG4J2-952-3.patch,
> LOG4J2-952-4.patch, LOG4J2-952.patch
>
>
> I found [this
> link|http://logging.apache.org/log4j/2.x/faq.html#config_from_code] which
> said:
> {quote}
> You could use the static method #initialize(String contextName, ClassLoader
> loader, String configLocation) in
> org.apache.logging.log4j.core.config.Configurator. (You can pass null for the
> class loader.) Be aware that this class is not part of the public API so your
> code may break with any minor release.
> {quote}
> This documentation is unclear because it points to a member function which
> needs a filename {{configLocation}} where as the topic is »without a
> configuration file«.
> It shoud rather point to the member function
> {{org.apache.logging.log4j.core.config.Configurator.initialize(ClassLoader
> loader, ConfigurationSource source)}}.
> Example:
> {code:java}
> import org.apache.logging.log4j.core.config.ConfigurationSource;
> import org.apache.logging.log4j.core.config.Configurator;
> final String hardCodedXmlConfig =
> "<?xml version='1.0' encoding='UTF-8'?>\n" +
> "<Configuration status='INFO'>\n" +
> " <Appenders>\n" +
> " <Console name='Console' target='SYSTEM_OUT'>\n" +
> " <PatternLayout pattern='%d{HH:mm:ss.SSS} [%t] %-5level
> %logger{36} - %msg%n'/>\n" +
> " </Console>\n" +
> " </Appenders>\n" +
> " <Loggers>\n" +
> " <Root level='debug'>\n" +
> " <AppenderRef ref='Console'/>\n" +
> " </Root>\n" +
> " </Loggers>\n" +
> "</Configuration>\n";
> try {
> Configurator.initialize(null, new ConfigurationSource(new
> ByteArrayInputStream(hardCodedXmlConfig.getBytes())));
> } catch (IOException e) {
> e.printStackTrace();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]