AsyncAppender is just a wrapper around any other Appender. So I don't see why it couldn't be used here.
On 26 September 2016 at 04:50, Mikael Ståldal <mikael.stal...@magine.com> wrote: > Could AsyncAppender be adapted for this use case? > > On Mon, Sep 26, 2016 at 12:44 AM, Remko Popma <remko.po...@gmail.com> > wrote: > >> That sounds like quite a unique use case! >> >> Would it make sense to go through a few iterations at your company until >> you have something that you're really happy with (to use and to support) >> before publishing it in Log4j? >> >> Remko >> >> Sent from my iPhone >> >> On 2016/09/25, at 7:13, Gary Gregory <garydgreg...@gmail.com> wrote: >> >> Hi All, >> >> I can't believe it, but through a convoluted use-case, I actually need an >> in-memory list appender, very much like our test-only ListAppender. >> >> The requirement is as follows. >> >> We have a JDBC driver and matching proprietary database that specializes >> in data virtualization of mainframe resources like DB2, VSAM, IMS, and all >> sorts of non-SQL data sources (http://www.rocketsoftware.com >> /products/rocket-data/rocket-data-virtualization) >> >> The high level requirement is to merge the driver log into the server's >> log for full-end to end tractability and debugging. >> >> When the driver is running on the z/OS mainframe, it can be configured >> with a z/OS specific Appender that can talk to the server log module >> directly. >> >> When the driver is running elsewhere, it can talk to the database via a >> Syslog socket Appender. This requires more set up on the server side and >> for the server to do special magic to know how the incoming log events >> match up with server operations. Tricky. >> >> The customer should also be able to configure the driver such that >> anytime the driver communicates to the database, it sends along whatever >> log events have accumulated since the last client-server roundtrip. This >> allows the server to match exactly the connection and operations the client >> performed with the server's own logging. >> >> In order to do that I need to buffer all log events in an Appender and >> when it's time, I need to get the list of events and reset the appender to >> a new empty list so events can keep accumulating. >> >> My proposal is to either turn our ListAppender into such an appender. For >> sanity, the appender could be configured with various sizing policies: >> >> - open: the list grows unbounded >> - closed: the list grows to a given size and _new_ events are dropped on >> the floor beyond that >> - latest: the list grows to a given size and _old_ events are dropped on >> the floor beyond that >> >> Thoughts? >> >> Gary >> >> -- >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >> Java Persistence with Hibernate, Second Edition >> <http://www.manning.com/bauer3/> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >> Spring Batch in Action <http://www.manning.com/templier/> >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory >> >> > > > -- > [image: MagineTV] > > *Mikael Ståldal* > Senior software developer > > *Magine TV* > mikael.stal...@magine.com > Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com > > Privileged and/or Confidential Information may be contained in this > message. If you are not the addressee indicated in this message > (or responsible for delivery of the message to such a person), you may not > copy or deliver this message to anyone. In such case, > you should destroy this message and kindly notify the sender by reply > email. > -- Matt Sicker <boa...@gmail.com>
