Re: [1/2] logging-log4j2 git commit: LOG4J2-1442 Generic HTTP appender

Done. On Thu, May 4, 2017 at 5:16 PM, Matt Sicker wrote: > As long as the plugin configuration that's exposed doesn't leak any > internal details specific to HttpURLConnection, I think we'll be fine as > you say. I haven't looked closely at the code yet, though (working hours > for me right now)

Re: [1/2] logging-log4j2 git commit: LOG4J2-1442 Generic HTTP appender

As long as the plugin configuration that's exposed doesn't leak any internal details specific to HttpURLConnection, I think we'll be fine as you say. I haven't looked closely at the code yet, though (working hours for me right now), so I don't have specific suggestions yet. On 4 May 2017 at 10:15,

Re: [1/2] logging-log4j2 git commit: LOG4J2-1442 Generic HTTP appender

I would say that the HttpManager would be that facade. If you want another implementation you write another HttpManager and add support for selecting between different managers in HttpAppender. I don't think that much code in HttpManager can be shared between different implementations. Maybe we sh

Re: [1/2] logging-log4j2 git commit: LOG4J2-1442 Generic HTTP appender

Depends on the use case. Using HttpURLConnection covers a lot of them, but users may need more customization to handle their requests. I'm not so sure how necessary it is to support in an initial version, but abstracting the use of HttpURLConnection behind a facade would be handy for future extensi

Re: [1/2] logging-log4j2 git commit: LOG4J2-1442 Generic HTTP appender

Yes, but what benefits would the more advanced client bring us? On Thu, May 4, 2017 at 4:59 PM, Matt Sicker wrote: > The main thing I wanted regarding plugability of clients was to allow for > both java.net usage along with a more advanced client. It could be > simplified down to only allowing o

Re: [1/2] logging-log4j2 git commit: LOG4J2-1442 Generic HTTP appender

The main thing I wanted regarding plugability of clients was to allow for both java.net usage along with a more advanced client. It could be simplified down to only allowing one non-java.net client library. I don't want to have two HTTP plugins with different configurations and other confusion jus

Re: [1/2] logging-log4j2 git commit: LOG4J2-1442 Generic HTTP appender

I can see advantages in using Netty-http or similar to use async NIO, though those advantages will be a bit limited as long as we don't have a proper interface for async appenders (LOG4J2-1797 ). But are there any significant advantages in using a

Re: [1/2] logging-log4j2 git commit: LOG4J2-1442 Generic HTTP appender

Thanks for starting this! My idea in mind when I wrote the ticket was to make the actual client pluggable so that users could use HttpURLConnection (no dependencies), Apache HttpClient, Netty-HTTP, etc. On 4 May 2017 at 07:49, wrote: > Repository: logging-log4j2 > Updated Branches: > refs/head