Re: log4j2 site design

2012-09-22 Thread Ivan Habunek
On 21 September 2012 21:21, Christian Grobmeier wrote: > I see, it is always good to have a web dev in team. > Personally I like this very much. I'm not a web dev. Please. I'm just marginally more perceptive than the average developer when it comes to web design. :) > PS: as you may have noticed

Re: log4j2 site design

2012-09-22 Thread Ivan Habunek
Raplh, do you have a "master" of the log4j logo? The one in images is a jpeg (and a bit blurry one at that), and I'd like to have a transparent png or gif to try to incorporate it into the header. Regards, Ivan On 21 September 2012 21:50, Ralph Goers wrote: > Yeah - I agree on both counts. You

Re: log4j2 site design

2012-09-22 Thread Ivan Habunek
On 21 September 2012 21:50, Ralph Goers wrote: > The only thing I would suggest is, like is done with the API, add the > "chapter" to the beginning of each section, although I'm not really sure why > I like that since it is obvious what chapter you are in from the sidebar. What do you think abo

Re: log4j2 site design

2012-09-22 Thread Tushar Kapila
I like the new site design. the logo missing is not such a bad idea. maybe on the first page it can be full size in the header and on the about/ press pack page / and on subsequent pages a smaller version in the header - more real estate for the sub pages is easier on the eyes http://bezdomni.n

Re: log4j2 site design

2012-09-22 Thread Ralph Goers
No. I have no idea who created it. I edited the jpeg in Photoshop Elements yesterday to add the TM to it. Ralph On Sep 22, 2012, at 2:05 AM, Ivan Habunek wrote: > Raplh, do you have a "master" of the log4j logo? The one in images is > a jpeg (and a bit blurry one at that), and I'd like to ha

Re: log4j2 site design

2012-09-22 Thread Ralph Goers
Reload the pages in your browser. They should all say meta1 now. They do for me. Ralph On Sep 22, 2012, at 4:11 AM, Tushar Kapila wrote: > I like the new site design. the logo missing is not such a bad idea. maybe on > the first page it can be full size in the header and on the about/ press pa

performance comparison

2012-09-22 Thread ceki
Hello, Looking at the log4j/log42/logback comparison [1], I have noticed a number of inaccuracies. item 2) The performance of deciding whether to log or not to log when logging is turned on. Logback does not walk the hierarchy. No, really. It doesn't. item 2) Actually outputting log messages

Re: performance comparison

2012-09-22 Thread Ralph Goers
Thank, Ceki. I obviously take your concerns very seriously and will look into these asap. Ralph On Sep 22, 2012, at 6:21 AM, ceki wrote: > Hello, > > Looking at the log4j/log42/logback comparison [1], I have noticed a > number of inaccuracies. > > item 2) The performance of deciding whether

Re: performance comparison

2012-09-22 Thread Christian Grobmeier
On Sat, Sep 22, 2012 at 3:46 PM, Ralph Goers wrote: > Thank, Ceki. I obviously take your concerns very seriously and will look > into these asap. Maybe we can push the used configuration/code for the perfomance test to github? That way it is more easy to follow which version has been used and w

Re: performance comparison

2012-09-22 Thread ceki
On 22.09.2012 15:48, Christian Grobmeier wrote: On Sat, Sep 22, 2012 at 3:46 PM, Ralph Goers wrote: Thank, Ceki. I obviously take your concerns very seriously and will look into these asap. Maybe we can push the used configuration/code for the perfomance test to github? That way it is more

Re: performance comparison

2012-09-22 Thread Ralph Goers
Well, Ceiki's statement about Logback not walking a hierarchy is partially correct and partially incorrect. In Logback each Logger has an "effectiveLevel" that is either set or inherited from its parent so the logger hierarchy isn't "walked" for level filtering. However, if a Logger has not b

Re: performance comparison

2012-09-22 Thread ceki
On 22.09.2012 17:29, Ralph Goers wrote: > Well, Ceiki's statement about Logback not walking a hierarchy is > partially correct and partially incorrect. In Logback each Logger has > an "effectiveLevel" that is either set or inherited from its parent so > the logger hierarchy isn't "walked" for le