Hi,
> -----Original Message-----
> From: Scott Deboy [mailto:[EMAIL PROTECTED]
> Sent: 25 May 2005 18:45
> To: Log4J Developers List
> Subject: Remove TRACE? Was: [VOTE] Modified Release Proposal
>
> 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 would you be +0 or +1 if more functionality was added to the schedule :-)
>
> 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.
Oh no please, not again! Hasn't this been discussed to the death?
When this issue was last discussed a vote was taken and the outcome was to
add TRACE. It was added to the CVS HEAD for the 1.3 release but this is
taking longer than anticipated to get to a final release.
>
> 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.
Users should be discouraged from adding custom levels to log4j as it is
known that having too many levels causes confusion as to the correct usage,
so why make it easier to use more custom levels?
There already exists the capability to add custom levels to log4j for the
determined user and TRACE logging can already be achieved using a variety of
methods.
I thought that TRACE had been accepted as it has a reasonable use-case and a
good general understanding of its purpose. If someone would like log4j to
have native support for ULTRATRACE or IMPORTANTINFO levels then let them
justify it, as the usage of those levels would be domain specific.
>
> 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)
This is a significant deviation from the typical logger usage pattern which
I would not want to encourage. If I want a convenient method to use a
custom level I would implement it in a Logger wrapper providing the same
usage pattern.
>
> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
