> On Feb 12, 2020, at 9:25 PM, Christopher <ctubb...@apache.org> wrote: > > On Wed, Feb 12, 2020 at 7:01 PM Ralph Goers <ralph.go...@dslextreme.com > <mailto:ralph.go...@dslextreme.com>> wrote: >> >> >> >>> On Feb 12, 2020, at 4:14 PM, Christopher <ctubb...@apache.org> wrote: >>> >>> Hi, >>> >>> I noticed that the log4j2 SocketServer and related utilities were >>> moved away from log4j-core and into log4j-tools awhile back. However, >>> there hasn't been a release of log4j-tools, as far as I can tell. Is >>> there any plan to do so? I'm having trouble migrating some custom >>> appender/receiver stuff from log4j1 without the classes, and I'd >>> prefer to use the newer log4j-core, rather than an out-of-date one >>> from before the move of these classes. >>> >>> (I just now subscribed to the list, and haven't had time to thoroughly >>> search the backlog for related discussions, so apologies if this has >>> already been covered recently.) >>> >>> Thanks, >>> >>> Christopher >>> >> >> >> You are correct. It hasn’t been released. There is some work that would be >> need to do the release although I don’t believe it is much. >> >> However, you should be warned that we don’t recommend sending Java >> serialized objects over the network as this has several problems, security >> being one of them. Instead, using something like JSON is a better choice. >> > > Thanks, I'm aware of that recommendation. It is the primary reason I > am motivated to investigate the alternatives in Log4j2. Unfortunately, > many of those alternatives appear to now exist only in the log4j-tools > repo. For example, my understanding is that the TcpSocketServer and > the SocketAppender can be configured to use the JSON layout, instead > of the Java Serialization layout, but I'm still in the early stages of > figuring out how to configure it all properly, and not having a > released jar in Maven Central has made it slightly difficult to > experiment with. > > I'm not 100% sure a release would even help me, as I may not even need > anything out of that repo. I was considering using the HttpAppender > instead, but there doesn't appear to be any server-side tooling at all > to help with that one. > > Ultimately, what I'm trying to do is have a custom appender forward to > a destination server whose location is subject to change over time. I > wanted this custom appender to be asynchronous, but did not want users > to have to configure the AsyncAppender wrapper themselves. I currently > have this for Log4j 1.2 > (https://github.com/apache/accumulo/blob/3fd5cad92f9b63ac19e4466f3f2d5237b905262c/server/monitor/src/main/java/org/apache/accumulo/monitor/util/AccumuloMonitorAppender.java > > <https://github.com/apache/accumulo/blob/3fd5cad92f9b63ac19e4466f3f2d5237b905262c/server/monitor/src/main/java/org/apache/accumulo/monitor/util/AccumuloMonitorAppender.java> > and > https://github.com/apache/accumulo/blob/3fd5cad92f9b63ac19e4466f3f2d5237b905262c/assemble/conf/log4j-service.properties#L35-L36 > > <https://github.com/apache/accumulo/blob/3fd5cad92f9b63ac19e4466f3f2d5237b905262c/assemble/conf/log4j-service.properties#L35-L36>), > but am having difficulty migrating to Log4j2.
Creating an AccumuloAppender for Log4j2 wouldn’t be terribly hard if that is really what you want to do. But I wouldn’t have it be an asynchronous appender. Instead, I would use asynchronous Loggers as they perform better. That said, I would have very little motivation to implement an AccumuloAppender myself. We use Logstash, Fluentd, and Flume for forwarding. I should point out that the SocketAppender, when configured for TCP allows for the location to change. Just configure it with a DNS name. It will perform a DNS lookup whenever it needs to reconnect. Ralph
