It seems odd to have one new feature as the only thing planned as the only
thing that will ever exist in a 1.x release - where the next release is 1.x+1.
As I said, I'm -0 on the 1.3 portion, only because TRACE is the only feature
described in this proposal for inclusion in 1.3 and I think the TRACE issue
could use more discussion before we make this decision.
So here goes:
What would happen if we stepped back and examined what folks are really asking
for when they say they want TRACE? We also know they aren't willing to wait
for/interested in 'domains' or event attributes.
I think folks want an easy way to add new severity levels without having to
write their own log4j-related classes. Let's give THAT to them. TRACE is a
band aid that only addresses the problem for folks who want ONE new level - a
new level that's less severe than DEBUG.
What about folks who want a level between INFO & WARN or between ERROR and
FATAL, or TWO levels below DEBUG (TRACE and ULTRATRACE)? Adding support for a
'TRACE' Level and related helpers in Logger doesn't address this problem and I
think we can find a solution that supports all of these cases in common way.
If a level is just a mapping between an int severity and a name, why not
support the registration of user-defined levels along side the built-in levels.
New levels could be registered with the Level class - a 'registerCustomLevel'
method on Level that would allow you to map your own severity to a name.
If I wanted to define a TRACE level and an ULTRA_TRACE level, I register these
as custom levels (no need to write our own level class). I then access these
levels using logger's already-provided log methods like this:
logger.log(Level.getCustomLevel("ULTRA_TRACE"), msg)
The only thing they lose is the logger.TRACE helper (which is only slightly
more compact than the logger.log method) - which I think is reasonable
considering the flexibility it provides. They also need to understand the int
values of the built-in levels (two inconveniences but folks who want their own
levels could reasonably be expected to understand how they work with built-in
levels).
There are probably many implementation options - this is just my thoughts on
how we could support TRACE in a more flexible way.
Thoughts?
Scott
-----Original Message-----
From: Mark Womack [mailto:[EMAIL PROTECTED]
Sent: Wed 5/25/2005 9:32 AM
To: 'Log4J Developers List'
Cc:
Subject: RE: [VOTE] Modified Release Proposal
But how long do you estimate the next 'major' release is going to be? You
don't think we should have an 'interim' release with trace and deprecation
in the mean time?
-Mark
> -----Original Message-----
> From: Scott Deboy [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 24, 2005 2:29 PM
> To: Log4J Developers List [EMAIL PROTECTED]
> Subject: RE: [VOTE] Modified Release Proposal
>
> +1 on 1 and 2
>
> -0 on 3 and 4: I would prefer to see 3 and 4 combined into the next
> 'major' release (which I feel should just be 1.3).
>
>
> -----Original Message-----
> From: Mark Womack [mailto:[EMAIL PROTECTED]
> Sent: Tue 5/24/2005 10:49 AM
> To: 'Log4J Developers List'
> Cc:
> Subject: [VOTE] Modified Release Proposal
> It sounds like there is interest in modifying the release schedule to move
> the trace changes into its own release number to protect the 1.2 users
> from
> the change.
>
> I want to finalize this so that we communicate it as part of the 1.2.11
> release later this week. I want to get the release schedule onto the
> website and into the 1.2.11 documentation.
>
> 1) Release 1.2.11 with JMS build fix.
> Timeframe: This is in progress now.
>
> 2) Release a 1.2.12 version with major bug fixes.
> Timeframe: Within 2 weeks of the 1.2.11 release.
> TBD: final set of bug fixes to include (Owners: Mark, Curt, Paul, ??). We
> should not take more than a week to hash this out, and we have started.
>
> 3) Release a 1.3 version that is the base 1.2.12 release + the TRACE
> changes. We can also consider adding more deprecation to prep the user
> base
> for changes coming in the next major release. What is currently released
> as
> the 1.3 alpha will be changed to version 1.4 (below). Moving trace to
> this
> release number protects the 1.2 users from this unexpected api change.
> Timeframe: Within 2 weeks of the 1.2.12 release.
>
> 4) Release 1.4. The next major release from the main cvs head, what we
> have
> been calling "1.3" to date. We will release a 1.4 alpha around the same
> time as the 1.3 release for the bleeding edge of our community.
> Timeframe: 10/2005 final release, sooner if we think possible.
> TBD: Finalize task list for release. (Owner: Mark)
>
> As usual, I am +1 for the above.
>
> -Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
