logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Severtson <ssevert...@digitalmeasures.com>
Subject Re: SMTPAppender work in progress, questions
Date Fri, 21 Dec 2012 01:02:19 GMT

Thanks. I knew it was something dumb, I just needed another set of eyes.

As for the manager - it looks like AbstractManager.getManager uses a 
"name" as a key, and returns shared instances if the same key is 
provided. Correct?

I'm thinking for SMTPAppender, this may be a good place to hold 
identically configured javax.mail.Session instances. Are there any 
existing appenders which rely on a composite "name" key, composed of 
several plugin configuration settings? Just curious where I could look 
for examples, as I'll need a unique instance per 
protocol/host/port/username/password/debug settings. Otherwise, I'll 
just concatenate settings with separators of some kind.

Finally, Dumbster is APL 2.0, so it shouldn't be a concern. I'll build 
some basic tests using it.

I'll see what I can wrap up in the short term, for possible inclusion in 
beta 4.

--Scott Severtson

On 12/20/2012 07:45 PM, Ralph Goers wrote:
> Also, I am planning on spending some time over the next week to address the outstanding
open Jira issues and then create a new release. If you can make something available by then
I'd love to include it.
> Ralph
> On Dec 20, 2012, at 4:43 PM, Ralph Goers wrote:
>> The name in the annotation is what should appear as the XML element name. So instead
of <SMTPAppender name="smtp" you should have <SMTP name="smtp".
>> Please remember to keep in mind if it makes sense you should try to use a Manager
as most of the other Appenders do so that 1) applications across multiple ClassLoaders will
share the Manager even if they have their own configuration and 2) applications won't have
problems when a reconfiguration occurs.
>> Generally there are no concerns about adding test dependencies. If the license is
not compatible with the Apache license we might want to discuss that but generally that is
flexible for test dependencies.
>> Ralph
>> On Dec 20, 2012, at 12:49 PM, Scott Severtson wrote:
>>> Hi,
>>> We've decided that we really need SMTPAppender to be implemented soon, and have
nearly finished a port/cleanup from the old Log4J 1.x implementation. The code is basically
complete, and we've got unit tests around a good percentage of the code.
>>> When fully tested and complete, we'd like to contribute the code back to the
project. As such, we're developing the code within a checked-out copy of Log4J2 trunk.
>>> We have two questions, though:
>>> 1. Even though the plugin class and factory method are annotated, XMLConfiguration
seems to be unable to find our plugin. Here's the relevant annotations:
>>> ---
>>> package org.apache.logging.log4j.core.appender;
>>> // ...
>>> @Plugin(name = "SMTP", type = "Core", elementType = "appender", printObject =
>>> public class SMTPAppender extends AbstractAppender {
>>> // ...
>>>     @PluginFactory
>>>     public static SMTPAppender createAppender(@PluginAttr("name") final String
>>> @PluginAttr("to") final String to,
>>> // ...
>>> ---
>>> Here's our stupid-simple log4j2.xml file:
>>> ---
>>> <configuration status="DEBUG">
>>>     <appenders>
>>>         <SMTPAppender
>>>                 name="smtp"
>>>                 to="me@example"
>>>                 subject="Test error" />
>>>     </appenders>
>>>     <loggers>
>>>         <root level="debug">
>>>             <appender-ref ref="smtp"/>
>>>         </root>
>>>     </loggers>
>>> </configuration>
>>> ---
>>> And, the startup debug output from Log4J2 itself:
>>> ---
>>> 2012-12-20 15:39:28,035 DEBUG Generated plugins in 0.048658829 seconds
>>> 2012-12-20 15:39:28,039 ERROR appenders contains an invalid element or attribute
>>> 2012-12-20 15:39:28,041 DEBUG Calling createAppenders on class org.apache.logging.log4j.core.config.plugins.AppendersPlugin
for element appenders with params(appenders={})
>>> 2012-12-20 15:39:28,085 DEBUG Generated plugins in 0.043871845 seconds
>>> 2012-12-20 15:39:28,087 DEBUG Calling createAppenderRef on class org.apache.logging.log4j.core.config.AppenderRef
for element appender-ref with params(ref="smtp", level="null", null)
>>> 2012-12-20 15:39:28,089 DEBUG Calling createLogger on class org.apache.logging.log4j.core.config.LoggerConfig$RootLogger
for element root with params(additivity="null", level="debug", appender-ref={org.apache.logging.log4j.core.config.AppenderRef@21aed5f9},
properties={}, Configuration(/home/ssevertson/workspace/log4j/core/test.xml), null)
>>> 2012-12-20 15:39:28,090 DEBUG Calling createLoggers on class org.apache.logging.log4j.core.config.plugins.LoggersPlugin
for element loggers with params(loggers={root})
>>> 2012-12-20 15:39:28,090 ERROR Unable to locate appender smtp for logger
>>> 2012-12-20 15:39:28,090 DEBUG Shutting down OutputStreamManager SYSTEM_OUT
>>> 2012-12-20 15:39:28,090 DEBUG Reconfiguration completed
>>> ---
>>> So, what are we missing? What else needs to happen to allow the plugin to be
recognized? FYI, we've also tried the "strict" syntax, both specifying the class name, and
the fully qualified package/class name as the "type" parameter.
>>> One final wrinkle - under a debugger, it appears that PluginManager is indeed
finding our class, although I'm not entirely sure I follow the plugin loading code.
>>> 2. We'd like to have more complete unit test coverage, including verifying that
messages are generated and sent correctly. As such, we'd need to introduce an additional test-time
dependency on a mock SMTP server, such as Dumbster. Any concerns with adding yet another test-time
>>> Thanks,
>>> --Scott Severtson
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message