[PATCH] - LOG4J2-256 - SyslogWraplayout

[Tomek Kaczynski]

Hi,


   my first OSS patch ever ;-)


Tomek


SyslogWrapLayout.java.patch
Description: Binary data

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

Appender extension based on UDP socket Appender error

[Tomek Kaczynski]

Hi, All

   Because of a bug already reported by me
(LOG4J2-246https://issues.apache.org/jira/browse/LOG4J2-246),
I had to write an Appender containing a fix/workaround.

 Obvious approach for me would be inherittance from
AbstractOutputStreamAppender and overriding method append. However I
couldn't do that because:

manager.write(bytes); and
manager.flush(); are package visible only + few other visibility issues.

So I would suggest to use more protected visibility than package as well as
'template method' pattern, especially in classes like
AbstractOutputStreamAppender.


In order to finalize my story I have to say that the final solution was to
put
a copied AbstractOutputStreamAppender and new Appender in namespace
org.apache. which is definitely not nice.



So, can you please consider making changes that would make lives of
extensions writers a little bit easier ?


Regards,
Tomek

-
@Override
public void append(final LogEvent event) {

final byte[] bytes = getLayout().toByteArray(event);
boolean failedOnSize = false;

readLock.lock();
try {

if (bytes.length  0) {
if (bytes.length = udpSizeLimit) {
manager.write(bytes);
if (this.immediateFlush || event.isEndOfBatch()) {
manager.flush();
}
} else {
failedOnSize = true;
}
}
} catch (final AppenderRuntimeException ex) {
error(Unable to write to stream  + manager.getName() +  for
appender  + getName());
throw ex;
} finally {
readLock.unlock();
}

if (failedOnSize) {
handleFailedSize(event, bytes);
}
}--

Socket Appender error

[Tomek Kaczynski]

Hi All,


   I'm using log4j2 since beta4, now beta5. In general it's a cute library,
but there's some bug that I've found out recently :


   When a client code genreates a huge message ( 64k ), the underlying
DatagramOutputStream fails ( UDP socket throws exception).

  After that all following flushes fail because data buffer is not cleared
upon exception.

 So in lines

DatagramOutputStream:91
--
public synchronized void flush() throws IOException {
if (this.data != null  this.ds != null  this.address != null) {
final DatagramPacket packet = new DatagramPacket(data,
data.length, address, port);
ds.send(packet);
}
data = null;
}

--

data = null should be put in finally block or some simillar solution could
be applied.


What do you think ?


Regards,
Tomek


Moreover DatagramOutputStream should check if message size is less then 64k
.