Yes that was the problem, I forgot to mark it as plugin. Now it works,
thank you
On Friday, August 29, 2014, Matt Sicker wrote:
> Is VanillaLogAppenderConfig also marked as a @Plugin and everything?
>
>
> On 28 August 2014 05:13, lb > wrote:
>
> > I'm writing a custom appender and I have a probl
Again, thanks for all the interest in my request.
I don't have the code in front of me, but I will try and give an
overview of what we did for log4j 1.x.
We want to send emails for errors happening in production. However for
example, we don't want to send thousands of emails if the network goes
d
This is a fair point. There are some things not in the API that we wouldn’t
change as they would also break compatibility, such as the Layout or Appender
interface, but we aren’t guaranteeing that specific Appender or Layout
instances won’t have a new parameter added to them or things like that
I would prefer to see changes that allows more flexible usage without
subclassing. If you subclass a core class, there is no guarantee that the
next release will be binary compatible. For the API, we do guarantee binary
compatibility within a major version.
Gary
On Fri, Aug 29, 2014 at 6:22 PM,
The dynamic way to go about doing that would be to update the configuration
and do a reconfigure. The basic way this is done is through polling the
config file, but the same concept can be extended in a more programmatic
fashion by taking a look at ConfigurationFactory customization:
http://loggin
I'm looking at integrating Log4j2 into a complex desktop application,
because of it's async logging implementation. The problem I'm running into
is that I'd like to dynamically register/unregister an appender on the root
logger (or any user specified logger). The problem though is that I can't
fi
I would not object to changing SmtpAppender to make it more extendible.
Can you tell me more about your use case? SmtpAppender is designed this way
because we had a specific usage in mind. By understanding your use case we
might be able to improve the design in a way that benefits not just you but
Thanks for your response Remko.
Looking into this further, I could duplicate the SmtpAppender code as it
really just seems to do plugin work. The bulk of the code is in the
SmtpManager class which is not marked final. The constructor is marked
protected, however it takes a private class (FactoryD
Looks like this class was made final in January 2013. The commit message
mentions checkstyle errors.
What change are you proposing? Would just removing the final keyword from
the class definition be enough to fulfill your needs?
It may be good to raise this as a feature request in Jira.
If you nee
It could be a problem with log4j2 not loading your custom plugin correctly.
It looks like you are building with maven.
Does the jar file generated by your build contain
a META-INF/org/apache/logging/log4j/core/config/plugins/Log4j2Plugins.dat
file?
If it doesn't you could try specifying the package
I'm upgrading an application to use Log4j2. With our existing
implementation we have created a new appender which extends the
SMTPAppender. I see the SMTPAppender is a final class now which prevents
me from extending it. I was wondering what the reason for this is? Do we
really need to re-imple
Is VanillaLogAppenderConfig also marked as a @Plugin and everything?
On 28 August 2014 05:13, lb wrote:
> I'm writing a custom appender and I have a problem setting up
> PluginElement:
>
> The xml definition is the following one:
>
>
>
>
> ${sys:java.io.tmpdir}/chronology-log4j2/conf-binary-v
12 matches
Mail list logo
