headers
Mark Womack | 1 Feb 2006 17:59
Picon
Favicon

[VOTE] Release log4j-1.3a8 official

The log4j project has voted to release log4j 1.3alpha8.  Just need PMC
approval for official release.

http://cvs.apache.org/builds/logging/log4j/log4j-1.3a8

I am +1.

(Maybe we should look into defining the meaning of "Product Release"
in the LS bylaws so that we don't require the PMC to vote for every
subproject alpha and beta release?  Unless we want that level of
oversight.)

-Mark
Permalink | Reply | 0 comments |
headers
Scott Deboy | 1 Feb 2006 20:24

RE: [VOTE] Release log4j-1.3a8 official

A nit, but:

I'd like to see logging-test not fail prior to letting a build out the door.

I know we could remove the test, but could this be a regression that would necessitate changes in the build?

Reserving my vote for the moment.

Scott Deboy
COMOTIV SYSTEMS
111 SW Columbia Street Ste. 950
Portland, OR  97201

Telephone:      503.224.7496
Cell:           503.997.1367
Fax:            503.222.0185

sdeboy <at> comotivsystems.com

www.comotivsystems.com

-----Original Message-----
From: mwomack <at> google.com on behalf of Mark Womack
Sent: Wed 2/1/2006 8:59 AM
To: Logging General
Subject: [VOTE] Release log4j-1.3a8 official

The log4j project has voted to release log4j 1.3alpha8.  Just need PMC
approval for official release.
(Continue reading)

Permalink | Reply | 503 comments |
headers
Mark Womack | 1 Feb 2006 20:44
Picon
Favicon

Re: [VOTE] Release log4j-1.3a8 official

Well, it is a good nit.  This particular test doesn't always fail
though.  Locally on my machine it failed once, and after looking at
the code, I ran it again and it worked.  My guess is that it has
something to do with the copying of the config file not changing the
date so that the watchdog triggers or conceiveably a bug in the
FileWatchdog code someplace.

There is something similar that I have mentioned related to the
TimeBasedRolling scheme as well, though it does not seem to show up in
the Gump radar.  I get it fairly often locally.

-Mark

On 2/1/06, Scott Deboy <sdeboy <at> comotivsystems.com> wrote:
> A nit, but:
>
> I'd like to see logging-test not fail prior to letting a build out the door.
>
> I know we could remove the test, but could this be a regression that would necessitate changes in the build?
>
> Reserving my vote for the moment.
>
>
> Scott Deboy
> COMOTIV SYSTEMS
> 111 SW Columbia Street Ste. 950
> Portland, OR  97201
>
> Telephone:      503.224.7496
> Cell:           503.997.1367
(Continue reading)

Permalink | Reply | 502 comments |
headers
Curt Arnold | 1 Feb 2006 22:16
Picon
Favicon

Re: [VOTE] Release log4j-1.3a8 official


On Feb 1, 2006, at 1:44 PM, Mark Womack wrote:

> Well, it is a good nit.  This particular test doesn't always fail
> though.  Locally on my machine it failed once, and after looking at
> the code, I ran it again and it worked.  My guess is that it has
> something to do with the copying of the config file not changing the
> date so that the watchdog triggers or conceiveably a bug in the
> FileWatchdog code someplace.
>
> There is something similar that I have mentioned related to the
> TimeBasedRolling scheme as well, though it does not seem to show up in
> the Gump radar.  I get it fairly often locally.
>
> -Mark

Gump is not consistently failing, but it isn't a desirable practice  
to be issuing releases while Gump is failing or immediately after  
Gump starts passing.  The test was recently added at which time they  
would pass on Windows but fail on most Unix platforms.  I modified  
them to get them to pass consistently on my boxes and apparently pass  
inconsistently on Gump.   I do not think it reflects a regression in  
the code base, but either the fragility of the test or a bug that has  
been latent in the code for some time.

Omitting the test would not change the distribution since the unit  
tests are not included.  It would only silence Gump from reminding us  
that we have either a fragile test or a latent bug.  I think  
releasing an alpha under these conditions, while undesirable, is  
acceptable.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Mark Womack | 1 Feb 2006 22:41
Picon
Favicon

Re: [VOTE] Release log4j-1.3a8 official

So, you are +1 then?  :-)

On 2/1/06, Curt Arnold <carnold <at> apache.org> wrote:
>
> On Feb 1, 2006, at 1:44 PM, Mark Womack wrote:
>
> > Well, it is a good nit.  This particular test doesn't always fail
> > though.  Locally on my machine it failed once, and after looking at
> > the code, I ran it again and it worked.  My guess is that it has
> > something to do with the copying of the config file not changing the
> > date so that the watchdog triggers or conceiveably a bug in the
> > FileWatchdog code someplace.
> >
> > There is something similar that I have mentioned related to the
> > TimeBasedRolling scheme as well, though it does not seem to show up in
> > the Gump radar.  I get it fairly often locally.
> >
> > -Mark
>
> Gump is not consistently failing, but it isn't a desirable practice
> to be issuing releases while Gump is failing or immediately after
> Gump starts passing.  The test was recently added at which time they
> would pass on Windows but fail on most Unix platforms.  I modified
> them to get them to pass consistently on my boxes and apparently pass
> inconsistently on Gump.   I do not think it reflects a regression in
> the code base, but either the fragility of the test or a bug that has
> been latent in the code for some time.
>
> Omitting the test would not change the distribution since the unit
> tests are not included.  It would only silence Gump from reminding us
(Continue reading)

Permalink | Reply | 1 comment |
headers
Curt Arnold | 1 Feb 2006 22:58
Picon
Favicon

Re: [VOTE] Release log4j-1.3a8 official


On Feb 1, 2006, at 3:41 PM, Mark Womack wrote:

> So, you are +1 then?  :-)

+1
Permalink | Reply | 0 comments |
headers
Mark Ferguson | 6 Feb 2006 16:41
Picon

log4j.configuration: relative path

Hello, I would like to link to my log4j configuration file as a
relative path. My current VM parameter is this :

-Dlog4j.configuration=../../conf/log4j.properties

When I run log4j with debugging I receive the following message:

log4j: Trying to find [../../conf/log4j.properties] using context
classloader sun.misc.Launcher$AppClassLoader <at> 133056f.
log4j: Trying to find [../../conf/log4j.properties] using
sun.misc.Launcher$AppClassLoader <at> 133056f class loader.
log4j: Trying to find [../../conf/log4j.properties] using
ClassLoader.getSystemResource().
log4j: Could not find resource: [../../conf/log4j.properties].

By poking around the source code it looks like the VM argument is
parsed as a URL and this is causing me problems, as it throws a
MalformedURLException. Is there any way to provide a relative path and
have it parsed correctly?

Thanks,

Mark
Permalink | Reply | 0 comments |
headers
Mark Womack | 6 Feb 2006 17:59
Picon
Favicon

Re: [VOTE] Release log4j-1.3a8 official

On Saturday, I instrumented the TimedLocationWatchdog code to see if I
could get a snapshot of what was going wrong, but of course after
doing that, the test never failed, after repeated tries.  It occured
to me last night that it could be related to a difference in JDK 1.3
vs JDK 1.4 (I was doing everything in 1.3).  So, I will be at it again
this evening.

However, I don't think we should stop the alpha8 release for this.  I
will create a bug to track the issue (if there isn't already an
apporpriate one).  But previously the test was just left out of the
main test suite.  At least now there is a test that can fail
(intermittently).  It is a new feature, not on a critical path for
most users, and all the other parts of the alpha8 release need to get
into the user community in general for review.  If this was beta or
rc, I'd have a much different opinion.

-Mark

On 2/1/06, Curt Arnold <carnold <at> apache.org> wrote:
>
> On Feb 1, 2006, at 1:44 PM, Mark Womack wrote:
>
> > Well, it is a good nit.  This particular test doesn't always fail
> > though.  Locally on my machine it failed once, and after looking at
> > the code, I ran it again and it worked.  My guess is that it has
> > something to do with the copying of the config file not changing the
> > date so that the watchdog triggers or conceiveably a bug in the
> > FileWatchdog code someplace.
> >
> > There is something similar that I have mentioned related to the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Womack | 7 Feb 2006 20:33
Picon
Favicon

[RESULT] Release log4j-1.3a8 official

+1 Mark
+1 Curt
+0 Scott

There are not enough votes to allow the official release of log4j 1.3
alpha 8 at this time.

I am still looking into the file watchdog, but was still unable to
reproduce yesterday, using the JDK 1.4.  FYI, Gump has not reported
any test failures in any recent runs.

-Mark
Permalink | Reply | 0 comments |
headers
Scott Deboy | 7 Feb 2006 21:11

RE: [RESULT] Release log4j-1.3a8 official

I appreciate your efforts, Mark, and I realize this is an alpha release so the expectation of a quality
release is lower.  I don't want to get in the way of getting feedback.

My view is that releases (including alpha releases) shouldn't come to the PMC for a vote until tests pass.  

Let's have a discussion about releases - do we as a PMC want to have a 'policy statement' about tests and how
they relate to releases?  If we don't want to define a set policy, that's ok, it's just that -1s can have a
negative impact (no pun intended) on the community, and obviously if we can avoid it we'll be better off.

+1 on the release, but I'd like us to come to agreement on what our role is w/r/t releases and tests/alpha and
non-alpha releases.

Scott Deboy
COMOTIV SYSTEMS
111 SW Columbia Street Ste. 950
Portland, OR  97201

Telephone:      503.224.7496
Cell:           503.997.1367
Fax:            503.222.0185

sdeboy <at> comotivsystems.com

www.comotivsystems.com

-----Original Message-----
From: mwomack <at> google.com on behalf of Mark Womack
Sent: Tue 2/7/2006 11:33 AM
To: Logging General
Subject: [RESULT] Release log4j-1.3a8 official
(Continue reading)

Permalink | Reply | 501 comments |

Gmane