Looks good - A few things:
1. helpers/Constants.java is in both extras & component. I looked in helpers
for other dups, but didn't see any - not sure if we have other dups..
2. When I try to use UDPReceiver (with XMLDecoder), it looks like it's trying
to go out to the internet to retrieve the DTD. Here's the exception:
log4j:ERROR Could not find [log4j.dtd]. Used [EMAIL PROTECTED]
2e78c] class loader in the search.
java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
at java.net.Socket.connect(Socket.java:519)
at java.net.Socket.connect(Socket.java:469)
at sun.net.NetworkClient.doConnect(NetworkClient.java:157)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:382)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:509)
at sun.net.www.http.HttpClient.<init>(HttpClient.java:231)
at sun.net.www.http.HttpClient.New(HttpClient.java:304)
at sun.net.www.http.HttpClient.New(HttpClient.java:316)
at
sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnecti
on.java:817)
at
sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.j
ava:769)
at
sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:6
94)
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection
.java:938)
at
com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(
XMLEntityManager.java:973)
at
com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startEntity(XMLEnti
tyManager.java:905)
at
com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startDTDEntity(XMLE
ntityManager.java:872)
at
com.sun.org.apache.xerces.internal.impl.XMLDTDScannerImpl.setInputSource(XML
DTDScannerImpl.java:282)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDispatcher
.dispatch(XMLDocumentScannerImpl.java:1021)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanD
ocument(XMLDocumentFragmentScannerImpl.java:368)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Con
figuration.java:834)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Con
figuration.java:764)
at
com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:14
8)
at
com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:25
0)
at
com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBu
ilderImpl.java:292)
at org.apache.log4j.xml.XMLDecoder.parse(XMLDecoder.java:167)
at org.apache.log4j.xml.XMLDecoder.decodeEvents(XMLDecoder.java:257)
at
org.apache.log4j.net.UDPReceiver$UDPHandlerThread.run(UDPReceiver.java:196)
To prevent this, I had to add log4j's src/main/resources path to my classpath..
Of course, I'm testing from inside eclipse, so this may not be an issue once I
try out the final jars. Just curious if we should change how the entity
resolver works (as you mentioned in a previous email).
I ended up calling MDC.put on the main Chainsaw thread to get the chainsaw-log
application & hostname mdc entries to appear, and I remove them in the
workerthread in ChainsawAppenderHandler, so I think we're ok with properties in
Chainsaw for now.
I think we're ready for a 1.2.15 rc..
By the way, I'm not sure where we left event properties - not important now,
just curious.
-----Original Message-----
From: Curt Arnold [mailto:[EMAIL PROTECTED]
Sent: Wed 8/22/2007 8:48 PM
To: Log4J Developers List
Subject: Bug list survey
I don't know what possessed me, but I think I've reviewed all the
open log4j bugs today and fixed several of them. I didn't see any of
the other ones that seemed ready for log4j 1.2.15. The big clusters
of bugs seemed to be:
1) Tomcat shutdown/restart breaking what were intended to be
invariants within a class. Unfortunately a lot of these "invariants"
weren't made private (many have package visibility) and could
potentially be modified (like
o.a.l.helpers.PatternConverter.SPACES). I considered rewriting
PatternConverter.spacePad, but didn't want to touch it due to its
potential to impact performance and that EnhancedPatternLayout has a
totally different implementation that may or may not be affected with
the Tomcat blues.
2) Users running multiple the same RFA configuration in multiple VMs.
3) Chainsaw related
Unless someone wants to lobby for a particular bug, I think I'm going
to let Gump do a nightly build and cut another release candidate
tomorrow and call a vote.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<<winmail.dat>>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
