DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=43867.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=43867.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
On 07/11/2007, at 7:15 PM, Curt Arnold wrote:
On Nov 7, 2007, at 1:55 AM, Curt Arnold wrote:
Okay, I'm about ready to fall over, but I looked at zeroconf and
see your motivation for moving the binding onto the main thread so
you continue the set up in
I've logged a bug report (43874) for the SocketHubAppender
enhancement and committed the createServerSocket() patch and updated
the changes.xml for 1.2.16. I'm not saying that has to be the final
approach, but I think there is general agreement that we can do
something minimal and safe in
Author: carnold
Date: Thu Nov 15 11:07:32 2007
New Revision: 595394
URL: http://svn.apache.org/viewvc?rev=595394view=rev
Log:
Bug 43874: SocketHubAppender should expose actual port in use to extending
classes
Modified:
logging/log4j/trunk/src/changes/changes.xml
On Nov 15, 2007, at 4:36 AM, Paul Smith wrote:
Ok, i'm a bit tired, so I ended up just going simple and pretty
much following Curt's idea, see below. Thoughts?
Index: src/main/java/org/apache/log4j/net/SocketHubAppender.java
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=43874.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=43874.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Can we get the maven dependencies corrected so we don't break maven and
others?
See
http://www.1060.org/blogxter/entry?publicid=9FDCA6751DE11295AD0049F5DB17
F461token=
Scott Deboy
Principal Engineer
COMOTIV SYSTEMS
111 SW Columbia Street Ste. 950
Portland, OR 97201
Office: 503.224.7496
Direct
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=43867.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
That chunk seems just like the IDE at work moving things around.
Honestly, is that really that much of a deal? I agree a total
reformat of the class is not a good idea, but I don't see the need to
get too anal about something like that..
But I didn't see much benefit from hiding
On Nov 15, 2007, at 2:02 PM, Scott Deboy wrote:
Can we get the maven dependencies corrected so we don't break maven
and
others?
See
http://www.1060.org/blogxter/entry?
publicid=9FDCA6751DE11295AD0049F5DB17
F461token=
Its fixed in the subversion repo. All that would be necessary is to
actually I've found a problem with the commit.
If ZeroconfSocketHubAppender class calls super.activateOptions() which
then creates the SocketServer, the actual creation of the ServerSocket
is done by another thread (see the SocketMonitor constructor), which
means the call back to the
On Nov 15, 2007, at 3:35 PM, Paul Smith wrote:
actually I've found a problem with the commit.
If ZeroconfSocketHubAppender class calls super.activateOptions()
which then creates the SocketServer, the actual creation of the
ServerSocket is done by another thread (see the SocketMonitor
14 matches
Mail list logo
