You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Jeff Turner <je...@socialchange.net.au> on 2002/01/13 09:09:45 UTC
[httpclient] Anakia outputting "[Element:"
Hi,
When I run 'ant xdoc' from a cleanly checked-out httpclient, the HTML output
contains:
<blockquote>
[Element: <p/>]
[Element: <p/>]
[Element: <p/>]
</blockquote>
Anyone know why this would be happening?
thanks,
--Jeff
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [logging] consensus about Log interface?
Posted by Paulo Gaspar <pa...@krankikom.de>.
LOL
Paulo
> -----Original Message-----
> From: Peter Donald [mailto:peter@apache.org]
> Sent: Monday, January 14, 2002 10:59 AM
> To: Jakarta Commons Developers List
> Subject: Re: [logging] consensus about Log interface?
>
>
> Wow - almost identical to the Avalon Logger interface.
>
> On Mon, 14 Jan 2002 10:09, robert burrell donkin wrote:
> > i think it's important to get a consensus since we might have to stick
> > with this interface for some time. this is an attempt to
> summarize what i
> > think came out of the various threads. it should make it easier
> for anyone
> > else who thinks otherwise to make that clear.
> >
> > 1. no one else (but me) has any great enthusiasm for making log levels
> > internal to commons-logging. so we'll lose that idea.
> >
> > 2. commons-logging should not perform any configuration of the
> underlying
> > logging system. therefore setLevel() should be removed.
> >
> > 3, getLevel cannot be used reliable for anything more than the basic
> > levels (ie. debug, info, warn, error, fatal). the behaviour of
> > commons-logging (from a component's point of view) should not depend on
> > any feature of the logging system which the user chooses. therefore
> > getLevel should be removed and isWarnEnabled, isErrorEnabled and
> > isFatalEnabled methods added instead. any implementation which cannot
> > reliable determine the log level should return true for each of these
> > methods.
> >
> > - robert
>
> --
> Cheers,
>
> Pete
>
> "You know what a dumbshit the 'average man' on the street is? Well, by
> definition, half of them are even dumber than that!"
> J.R. "Bob" Dobbs
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] consensus about Log interface?
Posted by Peter Donald <pe...@apache.org>.
Wow - almost identical to the Avalon Logger interface.
On Mon, 14 Jan 2002 10:09, robert burrell donkin wrote:
> i think it's important to get a consensus since we might have to stick
> with this interface for some time. this is an attempt to summarize what i
> think came out of the various threads. it should make it easier for anyone
> else who thinks otherwise to make that clear.
>
> 1. no one else (but me) has any great enthusiasm for making log levels
> internal to commons-logging. so we'll lose that idea.
>
> 2. commons-logging should not perform any configuration of the underlying
> logging system. therefore setLevel() should be removed.
>
> 3, getLevel cannot be used reliable for anything more than the basic
> levels (ie. debug, info, warn, error, fatal). the behaviour of
> commons-logging (from a component's point of view) should not depend on
> any feature of the logging system which the user chooses. therefore
> getLevel should be removed and isWarnEnabled, isErrorEnabled and
> isFatalEnabled methods added instead. any implementation which cannot
> reliable determine the log level should return true for each of these
> methods.
>
> - robert
--
Cheers,
Pete
"You know what a dumbshit the 'average man' on the street is? Well, by
definition, half of them are even dumber than that!"
J.R. "Bob" Dobbs
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] consensus about Log interface?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sun, 13 Jan 2002, robert burrell donkin wrote:
> Date: Sun, 13 Jan 2002 23:09:55 +0000
> From: robert burrell donkin <ro...@mac.com>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: [logging] consensus about Log interface?
>
> i think it's important to get a consensus since we might have to stick
> with this interface for some time. this is an attempt to summarize what i
> think came out of the various threads. it should make it easier for anyone
> else who thinks otherwise to make that clear.
>
> 1. no one else (but me) has any great enthusiasm for making log levels
> internal to commons-logging. so we'll lose that idea.
>
+1
> 2. commons-logging should not perform any configuration of the underlying
> logging system. therefore setLevel() should be removed.
>
+1
> 3, getLevel cannot be used reliable for anything more than the basic
> levels (ie. debug, info, warn, error, fatal). the behaviour of
> commons-logging (from a component's point of view) should not depend on
> any feature of the logging system which the user chooses. therefore
> getLevel should be removed and isWarnEnabled, isErrorEnabled and
> isFatalEnabled methods added instead. any implementation which cannot
> reliable determine the log level should return true for each of these
> methods.
>
It's clear that different logging systems have different notions about
what "levels" are available, so removing getLevel() makes sense to me as
well.
I don't personally plan to call is{Warn,Error,Fatal}Enabled in my code,
but I can see adding them for semantic completeness.
> - robert
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[logging] consensus about Log interface?
Posted by robert burrell donkin <ro...@mac.com>.
i think it's important to get a consensus since we might have to stick
with this interface for some time. this is an attempt to summarize what i
think came out of the various threads. it should make it easier for anyone
else who thinks otherwise to make that clear.
1. no one else (but me) has any great enthusiasm for making log levels
internal to commons-logging. so we'll lose that idea.
2. commons-logging should not perform any configuration of the underlying
logging system. therefore setLevel() should be removed.
3, getLevel cannot be used reliable for anything more than the basic
levels (ie. debug, info, warn, error, fatal). the behaviour of
commons-logging (from a component's point of view) should not depend on
any feature of the logging system which the user chooses. therefore
getLevel should be removed and isWarnEnabled, isErrorEnabled and
isFatalEnabled methods added instead. any implementation which cannot
reliable determine the log level should return true for each of these
methods.
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [httpclient] Anakia outputting "[Element:"
Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 1/13/02 12:09 AM, "Jeff Turner" <je...@socialchange.net.au> wrote:
> Hi,
>
> When I run 'ant xdoc' from a cleanly checked-out httpclient, the HTML output
> contains:
>
> <blockquote>
> [Element: <p/>]
> [Element: <p/>]
> [Element: <p/>]
> </blockquote>
>
>
> Anyone know why this would be happening?
>
> thanks,
>
> --Jeff
What does the source XML look like?
-jon
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>