Hi All:
Our server uses v1's org.apache.log4j.net.XMLSocketReceiver.
I do not see a v2 equivalent.
Thoughts?
Gary
--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Editionhttp://www.manning.com/bauer3/
JUnit in Action, Second Edition
We need to add receivers to log4j2 :)
Dcott
On Mar 25, 2014 5:19 AM, Gary Gregory garydgreg...@gmail.com wrote:
Hi All:
Our server uses v1's org.apache.log4j.net.XMLSocketReceiver.
I do not see a v2 equivalent.
Thoughts?
Gary
--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
We have JMS receivers and a SocketServer. I would expect that the
XMLSocketReceiver is expecting log events in XML format? If so, it would seem
that extending SocketServer to do that wouldn’t be very hard.
Ralph
On Mar 25, 2014, at 6:51 AM, Scott Deboy scott.de...@gmail.com wrote:
We need
I've been reading up on Camel lately. Maybe we could adopt some conventions
from there?
On 25 March 2014 10:29, Ralph Goers ralph.go...@dslextreme.com wrote:
We have JMS receivers and a SocketServer. I would expect that the
XMLSocketReceiver is expecting log events in XML format? If so, it
On Tue, Mar 25, 2014 at 9:38 PM, Matt Sicker boa...@gmail.com wrote:
I've been reading up on Camel lately. Maybe we could adopt some
conventions from there?
Please explain.
Gary
On 25 March 2014 10:29, Ralph Goers ralph.go...@dslextreme.com wrote:
We have JMS receivers and a
OK, I think Camel is higher level than our low-level net bits.
Gary
On Tue, Mar 25, 2014 at 10:20 PM, Matt Sicker boa...@gmail.com wrote:
Using routes, consumers, producers, processors, endpoints, etc. All
enterprise integration pattern sort of things. Somewhat similar to how
Flume works,
I don't mean using it. I mean borrowing the patterns it uses
architecturally. Though I might be thinking a bit too high level here to be
really useful.
So basically, we've got Appenders, Filters, Layouts (and patterns),
StrLookups, and ContextSelectors. Using Camel/EIP vocab, that gives us
