headers
ceki | 3 Jan 2003 10:10
Picon
Favicon

cvs commit: jakarta-log4j/docs manual.html

ceki        2003/01/03 01:10:36

  Modified:    docs     manual.html
  Log:
  Minor corrections signalled by Bernhard Wagner

  Revision  Changes    Path
  1.37      +4 -4      jakarta-log4j/docs/manual.html

  Index: manual.html
  ===================================================================
  RCS file: /home/cvs/jakarta-log4j/docs/manual.html,v
  retrieving revision 1.36
  retrieving revision 1.37
  diff -u -r1.36 -r1.37
  --- manual.html	3 Dec 2002 17:37:02 -0000	1.36
  +++ manual.html	3 Jan 2003 09:10:36 -0000	1.37
   <at>  <at>  -55,8 +55,8  <at>  <at> 
   latest log4j version, including full-source code, class files and
   documentation can be found at <a
   href="http://jakarta.apache.org/log4j/"><b>http://jakarta.apache.org/log4j/</b></a>.
  -By the way, log4j has been ported to the C, C++, C#, Python, Ruby, and
  -Eiffel languages.
  +By the way, log4j has been ported to the C, C++, C#, Perl, Python,
  +Ruby, and Eiffel languages.

   <p>Inserting log statements into code is a low-tech method for
   debugging it. It may also be the only way because debuggers are not
   <at>  <at>  -72,7 +72,7  <at>  <at> 
   development cycle, a sufficiently rich logging package can also be
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Womack | 3 Jan 2003 19:44

log4j sandbox?

Some of our discussions prior to the holiday break got me thinking,
specifically the discussion about adding new, experimental code to log4j and
the desire to allow users to contribute code to a more permanent place.

There are at least two jakarta projects that support a "sandbox" area where
newer, more experimental code can be created and submitted.  I am not
familiar with the specifics, but I wonder if something like that might
benefit this project as well.

Pros:

- newer, experimental code could go in the log4j-sandbox, and after some
time of usage and "shake down", it could be moved to the main log4j project,
based on a vote by committers.
- new code that seemed like a good idea at the time, but on second thought
should not have been released, will be kept in the sandbox area.  This
includes the new stuff we have added recently like selectors and servlets.
- code that doesn't make sense to include in the main log4j project, due to
obscurity, etc could live in the sandbox.
- the sandbox code could be released as part of the official release, in a
different jar, but with the caveats that it is sandbox level support.
- maybe we could be a bit looser with committer access to the sandbox,
allowing more users to have commit access.  Allowing patches to be applied,
etc.  I don't know if anyone has watched the commons httpclient project, but
they do almost everything through patches.  Kind of neat.

Cons:

- another cvs to maintain
- there might be more build breakages with the "looser" sandbox standards.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jacob Kjome | 3 Jan 2003 21:41
Favicon

Re: log4j sandbox?


Sounds like a good idea to me.

Jake

At 10:44 AM 1/3/2003 -0800, you wrote:
>Some of our discussions prior to the holiday break got me thinking,
>specifically the discussion about adding new, experimental code to log4j and
>the desire to allow users to contribute code to a more permanent place.
>
>There are at least two jakarta projects that support a "sandbox" area where
>newer, more experimental code can be created and submitted.  I am not
>familiar with the specifics, but I wonder if something like that might
>benefit this project as well.
>
>Pros:
>
>- newer, experimental code could go in the log4j-sandbox, and after some
>time of usage and "shake down", it could be moved to the main log4j project,
>based on a vote by committers.
>- new code that seemed like a good idea at the time, but on second thought
>should not have been released, will be kept in the sandbox area.  This
>includes the new stuff we have added recently like selectors and servlets.
>- code that doesn't make sense to include in the main log4j project, due to
>obscurity, etc could live in the sandbox.
>- the sandbox code could be released as part of the official release, in a
>different jar, but with the caveats that it is sandbox level support.
>- maybe we could be a bit looser with committer access to the sandbox,
>allowing more users to have commit access.  Allowing patches to be applied,
>etc.  I don't know if anyone has watched the commons httpclient project, but
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla | 3 Jan 2003 22:24
Picon
Favicon

DO NOT REPLY [Bug 15599] - SocketAppender ignores ReconnectionDelay of 0 (with fix)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15599>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15599

SocketAppender ignores ReconnectionDelay of 0 (with fix)

mwomack <at> apache.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
Permalink | Reply | 0 comments |
headers
bugzilla | 3 Jan 2003 22:34
Picon
Favicon

DO NOT REPLY [Bug 15599] - SocketAppender ignores ReconnectionDelay of 0 (with fix)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15599>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15599

SocketAppender ignores ReconnectionDelay of 0 (with fix)

mwomack <at> apache.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|log4j-dev <at> jakarta.apache.org|mwomack <at> apache.org
             Status|ASSIGNED                    |NEW

------- Additional Comments From mwomack <at> apache.org  2003-01-03 21:34 -------
I'll take a look at applying this change.
Permalink | Reply | 0 comments |
headers
Ceki Gülcü | 4 Jan 2003 00:08
Picon
Gravatar

Re: log4j sandbox?


Sounds good. We could be quite lax with commit access, for instance any 
existing jakarta committer should have access to the log4j-sandbox upon 
demand with no questions asked.

Ask on general <at> jakarta

I'd also ask on community <at> apache.org for input on how other projects deal 
with contributions.

At 10:44 03.01.2003 -0800, you wrote:
>Some of our discussions prior to the holiday break got me thinking,
>specifically the discussion about adding new, experimental code to log4j and
>the desire to allow users to contribute code to a more permanent place.
>
>There are at least two jakarta projects that support a "sandbox" area where
>newer, more experimental code can be created and submitted.  I am not
>familiar with the specifics, but I wonder if something like that might
>benefit this project as well.
>
>Pros:
>
>- newer, experimental code could go in the log4j-sandbox, and after some
>time of usage and "shake down", it could be moved to the main log4j project,
>based on a vote by committers.
>- new code that seemed like a good idea at the time, but on second thought
>should not have been released, will be kept in the sandbox area.  This
>includes the new stuff we have added recently like selectors and servlets.
>- code that doesn't make sense to include in the main log4j project, due to
>obscurity, etc could live in the sandbox.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ceki Gülcü | 4 Jan 2003 00:11
Picon
Gravatar

Re: log4j sandbox?


(My previous message was sent prematurely.)

Sounds good. We could be quite lax with commit access, for instance
any existing jakarta committer chould have access to the log4j-sandbox
upon demand with no questions asked.

Ask on general <at> jakarta for someone to create log4j-sandbox.

I'd also ask on community <at> apache.org for input on how other projects
deal with contributions.

At 10:44 03.01.2003 -0800, you wrote:
>Some of our discussions prior to the holiday break got me thinking,
>specifically the discussion about adding new, experimental code to log4j and
>the desire to allow users to contribute code to a more permanent place.
>
>There are at least two jakarta projects that support a "sandbox" area where
>newer, more experimental code can be created and submitted.  I am not
>familiar with the specifics, but I wonder if something like that might
>benefit this project as well.
>
>Pros:
>
>- newer, experimental code could go in the log4j-sandbox, and after some
>time of usage and "shake down", it could be moved to the main log4j project,
>based on a vote by committers.
>- new code that seemed like a good idea at the time, but on second thought
>should not have been released, will be kept in the sandbox area.  This
>includes the new stuff we have added recently like selectors and servlets.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jonathan Cowherd | 4 Jan 2003 00:47
Favicon

log4j socket patch

I found a "bug" in the org.apache.log4j.net.SocketServer class.

If a machine only has an IP and no host name, the InetAddres.toString() call
only return "/D1.D2.D3.D4" which yields an empty string for String key =
s.substring(0,i) //where I is the index of the '/' in the returned string.
This patch will return the IP address to the 'key' variable so that you can
use IP addresses for conf files like 192.168.1.30.lcf .  :)

It's been suggested that InetAddress has more functions that there could be
a better way of getting the host name.  I'll investigate this weekend (from
first glance, InetAddress wasn't pretty to look at).

Jonathan Paul Cowherd
Linux and Java Administrator
Genscape, Inc.
Email:  jonathan.cowherd <at> genscape.com
Office: (502) 583-3730
Mobile: (502) 314-0444

-----Original Message-----
From: Jonathan Cowherd [mailto:jcowherd <at> thor.int.genscape.com] 
Sent: Friday, January 03, 2003 7:43 PM
To: jonathan.cowherd <at> genscape.com
Subject: log4j socket patch

--- SocketServerorig.java	Fri Jan  3 19:42:08 2003
+++ SocketServer.java	Fri Jan  3 19:42:08 2003
 <at>  <at>  -70,7 +70,7  <at>  <at> 

   <at> since 1.0 */
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mark Womack | 4 Jan 2003 02:34

RE: log4j sandbox?

> Sounds good. We could be quite lax with commit access, for instance
> any existing jakarta committer chould have access to the log4j-sandbox
> upon demand with no questions asked.

This is the policy for commons-sandbox, according to the info I read on the
web.

> Ask on general <at> jakarta for someone to create log4j-sandbox.
> 
> I'd also ask on community <at> apache.org for input on how other projects
> deal with contributions.

I'm going to get more input on this before creating the cvs.

-Mark
Permalink | Reply | 0 comments |
headers
Richard Bair | 4 Jan 2003 02:52

new configure method for DOMConfigurator

Ceki/Mark,

I added a really simple config method to DOMConfigurator.  It made my
life easier since I could now use an in memory string representation of
an xml file to initialize the log4j system (via a StringReader and the
InputSource).  I don't know how to go about contributing, or anything,
but here it is.

  /**
     A static version of { <at> link #doConfigure(InputSource,    
     LoggerRepository)}.
  */
  static
  public
  void configure(InputSource xmlData) throws FactoryConfigurationError {
    new DOMConfigurator().doConfigure(xmlData,
LogManager.getLoggerRepository());
  }

Feel free.  BTW, let me know if this will be added.  If not, then I'll
add it to my proprietary code.

Thanks,
Richard
Permalink | Reply | 0 comments |

Gmane