You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Mark Womack <mw...@apache.org> on 2006/01/27 06:37:45 UTC
log4j 1.3alpha8 build
http://cvs.apache.org/builds/logging/log4j/log4j-1.3a8/
Take a look at it.
I plan to generate the compatibility report and post it someplace. I still
need to figure out the problem with my building the dll.
-Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j 1.3alpha8 build
Posted by Yoav Shapira <yo...@apache.org>.
Hola,
> I think I'm -0 on releasing Mark's last build. There are a couple
> things in the build process that bother me and I think it would be
> better to take another day and fix them. Also, I think that it would
> be best not to announce release candidates to the log4j-user list, at
> least not until the developer community sanity checks the build. I
> am able to reproduce Mark's build (with the expected exception of
> timestamps in the generated Javadoc files).
This is mostly a philosophical difference between us. I'm generally
+1 on releasing anything and everything for public consumption as long
as it's properly labelled (which these alpha builds are). When you
start doing too much internal QA and reduce the number of eyeballs
looking at stuff, you lose several key benefits of the open-source
development process IMHO.
I'm not pushing hard for the release, especially since I haven't been
heavily involved with the compatibility stuff. My original message
was intended to be in the "by the way, here's something to think
about..." tone.
--
Yoav Shapira
System Design and Management Fellow
MIT Sloan School of Management
Cambridge, MA, USA
yoavs@computer.org / www.yoavshapira.com
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j 1.3alpha8 build
Posted by Jacob Kjome <ho...@visi.com>.
Sounds good. If the docs are all proper and work without -breakiterator, then
that's even better. I guess we'll have to be diligent that we don't add any
new docs that run into problems. But since they all work now, that effort
should be minor.
Jake
Quoting Curt Arnold <ca...@apache.org>:
>
> On Jan 30, 2006, at 11:34 PM, Jacob Kjome wrote:
> > Have either of you looked at the Ant docs for the Javadoc task
> > since Ant-1.6 came out (a long, long, time ago, I might add)? It
> > includes a "breakiterator" attribute which, as I understand it,
> > takes effect under JDK1.4+. I could be wrong, since I've never
> > actually tested it under JDK1.3.1, but it seems to me that the
> > smart way to implement the feature would be to ignore
> > breakiterator="true" in cases where the JDK is less than 1.4. That
> > way, the build is not tied to a particular JDK as additionalparam="-
> > breakiterator" would do. Please let me know if I'm wrong. But if
> > I'm not, it would make sense to use breakiterator="true"
>
>
> Using the breakiterator attribute on the javadoc task would have
> fixed the problem without requiring changes to the documentation
> comments. It hadn't crossed my mind that additionalparam="-
> breakiterator" could have been a legacy from Ant 1.5.
>
> However, the changes made to the doc comments were desirable since
> the places where the original sentence analyzer and the breakiterator
> differed in their analysis were places where there should have been a
> sentence and wasn't. The only marginal case was:
>
>
> - Return <code>true</code> if the buffer is full, i.e. of the
> + Return <code>true</code> if the buffer is full, that is the
> number of elements in the buffer equals the buffer size. */
>
> Where the period after the "i" in "i.e." was considered the end of
> the first sentence by the original sentence scanner and breakiterator
> would have ended after "size". I replaced "i.e." with its English
> equivalent which eliminated the discrepancy. I had a vague
> recollection that Strunk and White's "The Elements of Style" had an
> explicit prohibition on "i.e." and "e.g.". I couldn't find it, but
> you could infer it from "19. Do not take shortcuts at the cost of
> clarity" and "20. Avoid foreign languages".
>
> Since using the BreakIterator as the default analyzer in Javadoc has
> been abandoned, I do not think it is desirable to add it back into
> the build since the switch will likely eventually disappear in a
> decade or two. At the moment, it would make no difference since the
> cases where it did make a difference has been eliminated.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j 1.3alpha8 build
Posted by Curt Arnold <ca...@apache.org>.
On Jan 30, 2006, at 11:34 PM, Jacob Kjome wrote:
> Have either of you looked at the Ant docs for the Javadoc task
> since Ant-1.6 came out (a long, long, time ago, I might add)? It
> includes a "breakiterator" attribute which, as I understand it,
> takes effect under JDK1.4+. I could be wrong, since I've never
> actually tested it under JDK1.3.1, but it seems to me that the
> smart way to implement the feature would be to ignore
> breakiterator="true" in cases where the JDK is less than 1.4. That
> way, the build is not tied to a particular JDK as additionalparam="-
> breakiterator" would do. Please let me know if I'm wrong. But if
> I'm not, it would make sense to use breakiterator="true"
Using the breakiterator attribute on the javadoc task would have
fixed the problem without requiring changes to the documentation
comments. It hadn't crossed my mind that additionalparam="-
breakiterator" could have been a legacy from Ant 1.5.
However, the changes made to the doc comments were desirable since
the places where the original sentence analyzer and the breakiterator
differed in their analysis were places where there should have been a
sentence and wasn't. The only marginal case was:
- Return <code>true</code> if the buffer is full, i.e. of the
+ Return <code>true</code> if the buffer is full, that is the
number of elements in the buffer equals the buffer size. */
Where the period after the "i" in "i.e." was considered the end of
the first sentence by the original sentence scanner and breakiterator
would have ended after "size". I replaced "i.e." with its English
equivalent which eliminated the discrepancy. I had a vague
recollection that Strunk and White's "The Elements of Style" had an
explicit prohibition on "i.e." and "e.g.". I couldn't find it, but
you could infer it from "19. Do not take shortcuts at the cost of
clarity" and "20. Avoid foreign languages".
Since using the BreakIterator as the default analyzer in Javadoc has
been abandoned, I do not think it is desirable to add it back into
the build since the switch will likely eventually disappear in a
decade or two. At the moment, it would make no difference since the
cases where it did make a difference has been eliminated.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j 1.3alpha8 build
Posted by Jacob Kjome <ho...@visi.com>.
At 06:29 PM 1/30/2006 -0600, you wrote:
>
>On Jan 30, 2006, at 2:02 PM, Mark Womack wrote:
>
>> Of the 4 items mentioned, the jdk 1.3/1.4 issue is the biggest. But
>> it looks like the 1.4 dependencies have been resolved? If so, then I
>> can rebuild using 1.3, remove the breakiterator, and upgrade to Ant
>> 1.6.5. None of those will be hard to setup.
>>
<snip>
>
>The -breakiterator flag has been removed and the handful of places
>where breakiterator made a difference resolved in trunk as of rev
>373024.
Why?
Have either of you looked at the Ant docs for the Javadoc task since
Ant-1.6 came out (a long, long, time ago, I might add)? It includes a
"breakiterator" attribute which, as I understand it, takes effect under
JDK1.4+. I could be wrong, since I've never actually tested it under
JDK1.3.1, but it seems to me that the smart way to implement the feature
would be to ignore breakiterator="true" in cases where the JDK is less than
1.4. That way, the build is not tied to a particular JDK as
additionalparam="-breakiterator" would do. Please let me know if I'm
wrong. But if I'm not, it would make sense to use breakiterator="true"
Jake
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j 1.3alpha8 build
Posted by Mark Womack <mw...@google.com>.
i definitely had the wrong binary for mingw.
i'll post status later this evening.
-Mark
On 1/30/06, Curt Arnold <ca...@apache.org> wrote:
>
> On Jan 30, 2006, at 2:02 PM, Mark Womack wrote:
>
> > Of the 4 items mentioned, the jdk 1.3/1.4 issue is the biggest. But
> > it looks like the 1.4 dependencies have been resolved? If so, then I
> > can rebuild using 1.3, remove the breakiterator, and upgrade to Ant
> > 1.6.5. None of those will be hard to setup.
> >
> > I need to look at the .dll build issue. I suspect that I am just
> > using the wrong download from the mingw stuff. Nothing I set up in
> > the path ever responds to the gcc command. I'll follow up with Curt
> > (and we need to document it in the build.properties.sample), but
> > again, I don't think it should slow down this alpha release.
> >
> > Unless I hear otherwise, I will get everything going tonight and
> > generate a new alpha8 build. Or alpha9 if that is easier to tag/etc.
> >
> > -Mark
> >
>
> The -breakiterator flag has been removed and the handful of places
> where breakiterator made a difference resolved in trunk as of rev
> 373024.
>
> Download "MinGW-3.1.0-1.exe" from http://mingw.sourceforge.net/
> download.shtml and run. Should install MinGW to \mingw and you
> should place \mingw\bin on the path.
>
> alpha8 was never signed, requested for a vote or signed, etc, so I
> would not have a problem keeping the name, but abandoning the binary
> in the cvs.apache.org/builds area. I would update the web site
> source in SVN for alpha8, copy the current trunk over to tags/alpha8,
> rebuild, place the image in cvs.apache.org/builds and then request a
> vote to move alpha8 to the distribution servers.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j 1.3alpha8 build
Posted by Curt Arnold <ca...@apache.org>.
On Jan 30, 2006, at 2:02 PM, Mark Womack wrote:
> Of the 4 items mentioned, the jdk 1.3/1.4 issue is the biggest. But
> it looks like the 1.4 dependencies have been resolved? If so, then I
> can rebuild using 1.3, remove the breakiterator, and upgrade to Ant
> 1.6.5. None of those will be hard to setup.
>
> I need to look at the .dll build issue. I suspect that I am just
> using the wrong download from the mingw stuff. Nothing I set up in
> the path ever responds to the gcc command. I'll follow up with Curt
> (and we need to document it in the build.properties.sample), but
> again, I don't think it should slow down this alpha release.
>
> Unless I hear otherwise, I will get everything going tonight and
> generate a new alpha8 build. Or alpha9 if that is easier to tag/etc.
>
> -Mark
>
The -breakiterator flag has been removed and the handful of places
where breakiterator made a difference resolved in trunk as of rev
373024.
Download "MinGW-3.1.0-1.exe" from http://mingw.sourceforge.net/
download.shtml and run. Should install MinGW to \mingw and you
should place \mingw\bin on the path.
alpha8 was never signed, requested for a vote or signed, etc, so I
would not have a problem keeping the name, but abandoning the binary
in the cvs.apache.org/builds area. I would update the web site
source in SVN for alpha8, copy the current trunk over to tags/alpha8,
rebuild, place the image in cvs.apache.org/builds and then request a
vote to move alpha8 to the distribution servers.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j 1.3alpha8 build
Posted by Mark Womack <mw...@apache.org>.
Of the 4 items mentioned, the jdk 1.3/1.4 issue is the biggest. But
it looks like the 1.4 dependencies have been resolved? If so, then I
can rebuild using 1.3, remove the breakiterator, and upgrade to Ant
1.6.5. None of those will be hard to setup.
I need to look at the .dll build issue. I suspect that I am just
using the wrong download from the mingw stuff. Nothing I set up in
the path ever responds to the gcc command. I'll follow up with Curt
(and we need to document it in the build.properties.sample), but
again, I don't think it should slow down this alpha release.
Unless I hear otherwise, I will get everything going tonight and
generate a new alpha8 build. Or alpha9 if that is easier to tag/etc.
-Mark
On 1/27/06, Curt Arnold <ca...@apache.org> wrote:
>
> On Jan 27, 2006, at 7:02 AM, Yoav Shapira wrote:
>
> > Howdy,
> > +1 to cross-posting alpha build announcements to
> > log4j-user@logging.a.o... It'd be nice to get wider feedback at this
> > point.
> >
> > Yoav
>
>
> I think I'm -0 on releasing Mark's last build. There are a couple
> things in the build process that bother me and I think it would be
> better to take another day and fix them. Also, I think that it would
> be best not to announce release candidates to the log4j-user list, at
> least not until the developer community sanity checks the build. I
> am able to reproduce Mark's build (with the expected exception of
> timestamps in the generated Javadoc files).
>
> My problem with the current build:
>
> 1. Failure when running on JDK 1.3
>
> The compilations were done on a JDK 1.4.2 unlike the recent log4j
> 1.2.x builds which are done on a JDK 1.3.1. Running the distributed
> jar files on a JDK 1.3 will throw NoSuchMethodException when doing
> date formatting. When compiled using JDK 1.3, calls that append
> StringBuilders will be compiled to use StringBuilder.append(Object),
> but when compiled using JDK 1.4, they will use a new
> StringBuilder.append(StringBuilder) method and which will result in a
> NoSuchMethodException when run on a JDK 1.3.
>
> 2. Missing NTEventLogAppender.dll
>
> Mark didn't go into the details on his problems. I'm guessing that
> it might have been related to the hassle of installing the Microsoft
> Platform SDK to get access to the Microsoft Message Compiler. The
> Message Compiler is used to compile src/java/org/apache/log4j/nt/
> EventLogCategories.mc into a small resource file and binary file.
> The output of the message compiler is tiny (less than 200 bytes) and
> slow changing and downloading the Platform SDK is huge, so it would
> probably be worthwhile just to cache the output of the Message
> Compiler into the SVN so that only MinGW is needed to build the DLL.
>
> 3. -breakiterator switch on Javadoc
>
> The -breakiterator switch (introduced in JDK 1.4) is used in
> build.xml. I'm not sure how it improves first sentence detection,
> but probably best to remove it and address javadoc formatting issues
> another way.
>
> 4. Use of Ant 1.6.4
>
> The candidate build was built using Ant 1.6.4 which was the
> recommended release for only two weeks (19-May-2005 to 2-June-2005).
> Ant 1.6.5 has been the recommended release since June 2005. Don't
> suspect that we are subject to any of the bugs reported in Ant 1.6.4,
> but it would be better to use a much more widely used version of Ant.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j 1.3alpha8 build
Posted by Curt Arnold <ca...@apache.org>.
On Jan 27, 2006, at 7:02 AM, Yoav Shapira wrote:
> Howdy,
> +1 to cross-posting alpha build announcements to
> log4j-user@logging.a.o... It'd be nice to get wider feedback at this
> point.
>
> Yoav
I think I'm -0 on releasing Mark's last build. There are a couple
things in the build process that bother me and I think it would be
better to take another day and fix them. Also, I think that it would
be best not to announce release candidates to the log4j-user list, at
least not until the developer community sanity checks the build. I
am able to reproduce Mark's build (with the expected exception of
timestamps in the generated Javadoc files).
My problem with the current build:
1. Failure when running on JDK 1.3
The compilations were done on a JDK 1.4.2 unlike the recent log4j
1.2.x builds which are done on a JDK 1.3.1. Running the distributed
jar files on a JDK 1.3 will throw NoSuchMethodException when doing
date formatting. When compiled using JDK 1.3, calls that append
StringBuilders will be compiled to use StringBuilder.append(Object),
but when compiled using JDK 1.4, they will use a new
StringBuilder.append(StringBuilder) method and which will result in a
NoSuchMethodException when run on a JDK 1.3.
2. Missing NTEventLogAppender.dll
Mark didn't go into the details on his problems. I'm guessing that
it might have been related to the hassle of installing the Microsoft
Platform SDK to get access to the Microsoft Message Compiler. The
Message Compiler is used to compile src/java/org/apache/log4j/nt/
EventLogCategories.mc into a small resource file and binary file.
The output of the message compiler is tiny (less than 200 bytes) and
slow changing and downloading the Platform SDK is huge, so it would
probably be worthwhile just to cache the output of the Message
Compiler into the SVN so that only MinGW is needed to build the DLL.
3. -breakiterator switch on Javadoc
The -breakiterator switch (introduced in JDK 1.4) is used in
build.xml. I'm not sure how it improves first sentence detection,
but probably best to remove it and address javadoc formatting issues
another way.
4. Use of Ant 1.6.4
The candidate build was built using Ant 1.6.4 which was the
recommended release for only two weeks (19-May-2005 to 2-June-2005).
Ant 1.6.5 has been the recommended release since June 2005. Don't
suspect that we are subject to any of the bugs reported in Ant 1.6.4,
but it would be better to use a much more widely used version of Ant.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j 1.3alpha8 build
Posted by Yoav Shapira <yo...@apache.org>.
Howdy,
+1 to cross-posting alpha build announcements to
log4j-user@logging.a.o... It'd be nice to get wider feedback at this
point.
Yoav
On 1/27/06, Mark Womack <mw...@apache.org> wrote:
> http://cvs.apache.org/builds/logging/log4j/log4j-1.3a8/
>
> Take a look at it.
>
> I plan to generate the compatibility report and post it someplace. I still
> need to figure out the problem with my building the dll.
>
> -Mark
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
--
Yoav Shapira
System Design and Management Fellow
MIT Sloan School of Management
Cambridge, MA, USA
yoavs@computer.org / www.yoavshapira.com
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: questions regarding log4j console prints and rolling file
appender
Posted by Sumit Kumar <su...@novell.com>.
To Add with that, I am using xml configuration file to configure log4j.
Sumit
>>> On Fri, Jan 27, 2006 at 1:33 pm, in message
<43...@novell.com>,
sumitk@novell.com wrote:
> Hi Devs,
>
> I am using log4j alpha6 for logging. Quite good, but still facing
few
> problems and need you help ..
>
> 1. While configure, there were many messages printed on the console.
I
> set LogLog.setQuiteMode(true) and many of the messages gone away.
But
> still there are few messages printed on the console.
> As I am developing a CLI, I can not afford any such messages on the
> console.
> Here are the messages printed:
>
> *** configurationOptionStr=log4j.properties
> ** End of LogManager static initializer
> (there are direct SOPs .. can we comment them out .. or use logger
to
> do so)
>
> 0 [main] WARN org.apache.log4j.config.PropertySetter - No such
property
> [storeLocation] in org.apache.log4j.Hierarchy.
> 1 [main] WARN org.apache.log4j.config.PropertySetter - No such
property
> [logStyle] in org.apache.log4j.Hierarchy.
> (Here xyz is the variable I am using for configuring some property
of
> my own and not related to log4j .However I feel there must be some
way
> to stop printing such messages on the console.)
>
> 2. I am extending RollingFileAppender to customize it for my
purpose.
> However this class is final in alpha- 7 and 8 builds.
> Can we make it extensible ??
>
> Any suggestion/help is welcomed ...
> Sumit
>
>
---------------------------------------------------------------------
> To unsubscribe, e- mail: log4j- dev- unsubscribe@logging.apache.org
> For additional commands, e- mail: log4j- dev-
help@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: questions regarding log4j console prints and rolling file appender
Posted by Curt Arnold <ca...@apache.org>.
On Jan 28, 2006, at 2:56 AM, Sumit Kumar wrote:
> Thanks for solving out first Issue for me.
> However the thing which stopped me to move for alpha7 or greater is
> org.apache.log4j.rolling.RollingFileAppender is a final class in them
> and hence is not extensible.
> Its good enough for me if some one can make it extensible in alpha -8,
> gives me all reasons to move for alpha 8 !!
The behavior of o.a.l.rolling.RollingFileAppender is customizable by
replacing the triggering policy and rolling policy objects. Those
are the anticipated extension points. Please explain what type of
behavior change you are trying to achieve. If they can't be
accomplished through the either the triggering policy or rolling
policy, then we can consider modifying TriggeringPolicy or
RollingPolicy, provide yet another extension point or (unlikely)
removing the final keyword.
For background on why final is our friend, see items 14 and 15 in
"Effective Java".
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: questions regarding log4j console prints and rolling file
appender
Posted by Sumit Kumar <su...@novell.com>.
Thanks for solving out first Issue for me.
However the thing which stopped me to move for alpha7 or greater is
org.apache.log4j.rolling.RollingFileAppender is a final class in them
and hence is not extensible.
Its good enough for me if some one can make it extensible in alpha -8,
gives me all reasons to move for alpha 8 !!
Regards
Sumit
>>> On Fri, Jan 27, 2006 at 10:40 pm, in message
<11...@my.visi.com>, hoju@visi.com wrote:
> Quoting Sumit Kumar <su...@novell.com>:
>
>> Hi Devs,
>>
>> I am using log4j alpha6 for logging. Quite good, but still facing
few
>> problems and need you help ..
>>
>> 1. While configure, there were many messages printed on the console.
I
>> set LogLog.setQuiteMode(true) and many of the messages gone away.
But
>> still there are few messages printed on the console.
>> As I am developing a CLI, I can not afford any such messages on the
>> console.
>> Here are the messages printed:
>>
>> *** configurationOptionStr=log4j.properties
>> ** End of LogManager static initializer
>> (there are direct SOPs .. can we comment them out .. or use logger
to
>> do so)
>>
>> 0 [main] WARN org.apache.log4j.config.PropertySetter - No such
property
>> [storeLocation] in org.apache.log4j.Hierarchy.
>> 1 [main] WARN org.apache.log4j.config.PropertySetter - No such
property
>> [logStyle] in org.apache.log4j.Hierarchy.
>> (Here xyz is the variable I am using for configuring some property
of
>> my own and not related to log4j .However I feel there must be some
way
>> to stop printing such messages on the console.)
>>
>
> This is the case for Log4j- 1.3 alphas less than 7. You need to
upgrade. The
> forced logging was there for debugging purposes in the development
of
> Log4j- 1.3. They are removed in alpha7. Alpha 8 is now out. You
should move
> to that.
>
> http://cvs.apache.org/builds/logging/log4j/log4j- 1.3a8/
>
>> 2. I am extending RollingFileAppender to customize it for my
purpose.
>> However this class is final in alpha- 7 and 8 builds.
>> Can we make it extensible ??
>>
>
> I'm not sure where this landed or if a final decision has been made.
Lots
> of
> work is going into making Logj4- 1.3 binary compatible with 1.2. But
I'm not
> sure if some of the wrapper classes are going to be removed. I
suggest
> looking
> in at the classes in the "rolling" package and extending one of
those.
>
> Jake
>
>> Any suggestion/help is welcomed ...
>> Sumit
>>
>>
---------------------------------------------------------------------
>> To unsubscribe, e- mail: log4j- dev- unsubscribe@logging.apache.org
>> For additional commands, e- mail: log4j- dev-
help@logging.apache.org
>>
>
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e- mail: log4j- dev- unsubscribe@logging.apache.org
> For additional commands, e- mail: log4j- dev-
help@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: questions regarding log4j console prints and rolling file appender
Posted by Jacob Kjome <ho...@visi.com>.
Quoting Sumit Kumar <su...@novell.com>:
> Hi Devs,
>
> I am using log4j alpha6 for logging. Quite good, but still facing few
> problems and need you help ..
>
> 1. While configure, there were many messages printed on the console. I
> set LogLog.setQuiteMode(true) and many of the messages gone away. But
> still there are few messages printed on the console.
> As I am developing a CLI, I can not afford any such messages on the
> console.
> Here are the messages printed:
>
> *** configurationOptionStr=log4j.properties
> ** End of LogManager static initializer
> (there are direct SOPs .. can we comment them out .. or use logger to
> do so)
>
> 0 [main] WARN org.apache.log4j.config.PropertySetter - No such property
> [storeLocation] in org.apache.log4j.Hierarchy.
> 1 [main] WARN org.apache.log4j.config.PropertySetter - No such property
> [logStyle] in org.apache.log4j.Hierarchy.
> (Here xyz is the variable I am using for configuring some property of
> my own and not related to log4j .However I feel there must be some way
> to stop printing such messages on the console.)
>
This is the case for Log4j-1.3 alphas less than 7. You need to upgrade. The
forced logging was there for debugging purposes in the development of
Log4j-1.3. They are removed in alpha7. Alpha 8 is now out. You should move
to that.
http://cvs.apache.org/builds/logging/log4j/log4j-1.3a8/
> 2. I am extending RollingFileAppender to customize it for my purpose.
> However this class is final in alpha-7 and 8 builds.
> Can we make it extensible ??
>
I'm not sure where this landed or if a final decision has been made. Lots of
work is going into making Logj4-1.3 binary compatible with 1.2. But I'm not
sure if some of the wrapper classes are going to be removed. I suggest looking
in at the classes in the "rolling" package and extending one of those.
Jake
> Any suggestion/help is welcomed ...
> Sumit
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
questions regarding log4j console prints and rolling file
appender
Posted by Sumit Kumar <su...@novell.com>.
Hi Devs,
I am using log4j alpha6 for logging. Quite good, but still facing few
problems and need you help ..
1. While configure, there were many messages printed on the console. I
set LogLog.setQuiteMode(true) and many of the messages gone away. But
still there are few messages printed on the console.
As I am developing a CLI, I can not afford any such messages on the
console.
Here are the messages printed:
*** configurationOptionStr=log4j.properties
** End of LogManager static initializer
(there are direct SOPs .. can we comment them out .. or use logger to
do so)
0 [main] WARN org.apache.log4j.config.PropertySetter - No such property
[storeLocation] in org.apache.log4j.Hierarchy.
1 [main] WARN org.apache.log4j.config.PropertySetter - No such property
[logStyle] in org.apache.log4j.Hierarchy.
(Here xyz is the variable I am using for configuring some property of
my own and not related to log4j .However I feel there must be some way
to stop printing such messages on the console.)
2. I am extending RollingFileAppender to customize it for my purpose.
However this class is final in alpha-7 and 8 builds.
Can we make it extensible ??
Any suggestion/help is welcomed ...
Sumit
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org