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 Ivan Habunek <iv...@gmail.com> on 2012/09/20 23:25:55 UTC
log4j2 site design
Hi Ralph & co,
Since you mentioned you had site design issues, I tried applying the
log4php template I created to log4j2 site. Seems to work pretty well.
Check out this quick demo, especially the cool vertically fixed sidebar :D
http://bezdomni.net/log4j2/
If you're interested, I could adapt the template and change the source
files to use bootstrap features. It would require some work but is
doable.
One potential problem I see is that this design does not have a logo
on the top of the page. Don't know how attached you are to having the
logo there.
Regards,
Ivan
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j2 site design
Posted by Ivan Habunek <iv...@gmail.com>.
On 21 September 2012 21:50, Ralph Goers <ra...@dslextreme.com> 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 about using breadcrumbs instead? Something like this:
http://bezdomni.net/log4j2/manual/configuration/configuration-syntax.html
I have also split appender page into one page per appender, with breadcrumbs:
http://bezdomni.net/log4j2/manual/appenders/flume.html
Still working on ideas for the header...
Ivan
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j2 site design
Posted by Ralph Goers <rg...@apache.org>.
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 <iv...@gmail.com> 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 have a
> transparent png or gif to try to incorporate it into the header.
>
> Regards,
> Ivan
>
> On 21 September 2012 21:50, Ralph Goers <ra...@dslextreme.com> wrote:
>> Yeah - I agree on both counts. You will notice I did the same thing with the API. 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.
>>
>> Ralph
>>
>> On Sep 21, 2012, at 12:21 PM, Christian Grobmeier wrote:
>>
>>> On Fri, Sep 21, 2012 at 9:16 PM, Ivan Habunek <iv...@gmail.com> wrote:
>>>> Ralph,
>>>>
>>>> How would you feel about breaking up the really long pages, e.g.
>>>> configuration, into smaller ones?
>>>
>>> I see, it is always good to have a web dev in team.
>>> Personally I like this very much.
>>>
>>> Cheers
>>>
>>> PS: as you may have noticed, I am not Ralph :-)
>>>
>>>
>>>> I've done a quick demo of how that would look (note that I've only
>>>> done configuration, not others).
>>>> http://bezdomni.net/log4j2/manual/configuration/index.html
>>>>
>>>> It may require a little bit of re-arranging things so not to have too
>>>> small pages, but generally, I think it's better this way.
>>>>
>>>> Regards,
>>>> Ivan
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>
>>>
>>>
>>>
>>> --
>>> http://www.grobmeier.de
>>> https://www.timeandbill.de
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j2 site design
Posted by Ivan Habunek <iv...@gmail.com>.
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 <ra...@dslextreme.com> wrote:
> Yeah - I agree on both counts. You will notice I did the same thing with the API. 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.
>
> Ralph
>
> On Sep 21, 2012, at 12:21 PM, Christian Grobmeier wrote:
>
>> On Fri, Sep 21, 2012 at 9:16 PM, Ivan Habunek <iv...@gmail.com> wrote:
>>> Ralph,
>>>
>>> How would you feel about breaking up the really long pages, e.g.
>>> configuration, into smaller ones?
>>
>> I see, it is always good to have a web dev in team.
>> Personally I like this very much.
>>
>> Cheers
>>
>> PS: as you may have noticed, I am not Ralph :-)
>>
>>
>>> I've done a quick demo of how that would look (note that I've only
>>> done configuration, not others).
>>> http://bezdomni.net/log4j2/manual/configuration/index.html
>>>
>>> It may require a little bit of re-arranging things so not to have too
>>> small pages, but generally, I think it's better this way.
>>>
>>> Regards,
>>> Ivan
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>
>>
>>
>>
>> --
>> http://www.grobmeier.de
>> https://www.timeandbill.de
>>
>> ---------------------------------------------------------------------
>> 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: performance comparison
Posted by ceki <ce...@qos.ch>.
On 22.09.2012 15:48, Christian Grobmeier wrote:
> On Sat, Sep 22, 2012 at 3:46 PM, Ralph Goers <ra...@dslextreme.com> 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
> which settings.
>
The relevant files can be found under:
http://svn.apache.org/repos/asf/logging/log4j/log4j2/trunk/core/src/test/
The resources/logback-perf.xml file should be modified to read:
<configuration>
<appender name="TestLogfile" class="ch.qos.logback.core.FileAppender">
<file>target/testlogback.log</file>
<encoder>
<pattern>%d{ISO8601} %5p [%t] %c{0} %X{transactionId} - %m%n</pattern>
<!-- this quadruples logging throughput -->
<immediateFlush>false</immediateFlush>
</encoder>
</appender>
<root level="debug">
<appender-ref ref="TestLogfile" />
</root>
</configuration>
HTH,
--
Ceki
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: performance comparison
Posted by ceki <ce...@qos.ch>.
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 level filtering. However, if
> a Logger has not been configured it will have no appenders and will
> have its additivity will default to true. callAppenders will perform
> the for loop to call all the appenders (there won't be any) and then
> because addictive is true it will delegate to its parent's
> callAppenders method, which will do the same. Thus if you have a
> hierarchy of 5 or 6 levels with only a root logger configured you will
> "walk the hierarchy". However, since the hierarchy is mentioned in a
> section on "deciding" (i.e. - filtering) Ceki is absolutely correct
> that this should be changed. FWIW, Log4j 2 also has the equivalent of
> the effectiveLevel on each Logger.
Thank you for the quick and detailed response. Indeed, the append loop
goes through the list of attached appenders. However, as you point out
that happens after the decision to log has been taken. This decision
is made extremely quickly and involves no "hierarchy walk".
I understand that log4j2 configuration is atomic. this might indeed be
an improvement upon logback. However, the devil might be in the
details.
> The next issue is with regard to immediateFlush. Prior to Logback
> 1.0.3 the immediateFlush parameter was not available in Logback as an
> option on LayoutWrappingEncoder, which is long after I wrote the text
> on the performance of writing log events. However, since the option
> is now available I have changed the test and rerun it. Note that the
> point of that section is not to highlight the differences between the
> frameworks but to point out that actually doing logging is
> considerably more costly than calling the logging framework and having
> the events filtered.
Makes sense.
> The results from rerunning the test are (I have a much faster MacBook
> than when I first wrote the doc):
>
> Log4j: 1427
> Logback: 1401
> Log4j 2.0: 1963
>
> Interestingly, I made a mistake the first time I tried it and
> configured it as
>
> <encoder immediateFlush="false">
>
> and didn't get an error and still got the slower results.
Joran is very much element oriented. It will ignore XML attributes it
does not know about. It will complain about unknown elements though.
Again, thank you for the quick response.
--
Ceki
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: performance comparison
Posted by Ralph Goers <ra...@dslextreme.com>.
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 been configured it will have no appenders and will have its additivity will default to true. callAppenders will perform the for loop to call all the appenders (there won't be any) and then because addictive is true it will delegate to its parent's callAppenders method, which will do the same. Thus if you have a hierarchy of 5 or 6 levels with only a root logger configured you will "walk the hierarchy". However, since the hierarchy is mentioned in a section on "deciding" (i.e. - filtering) Ceki is absolutely correct that this should be changed. FWIW, Log4j 2 also has the equivalent of the effectiveLevel on each Logger.
The next issue is with regard to immediateFlush. Prior to Logback 1.0.3 the immediateFlush parameter was not available in Logback as an option on LayoutWrappingEncoder, which is long after I wrote the text on the performance of writing log events. However, since the option is now available I have changed the test and rerun it. Note that the point of that section is not to highlight the differences between the frameworks but to point out that actually doing logging is considerably more costly than calling the logging framework and having the events filtered.
The results from rerunning the test are (I have a much faster MacBook than when I first wrote the doc):
Log4j: 1427
Logback: 1401
Log4j 2.0: 1963
Interestingly, I made a mistake the first time I tried it and configured it as
<encoder immediateFlush="false">
and didn't get an error and still got the slower results.
Ralph
On Sep 22, 2012, at 6:48 AM, Christian Grobmeier wrote:
> On Sat, Sep 22, 2012 at 3:46 PM, Ralph Goers <ra...@dslextreme.com> 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
> which settings.
>
> Cheers
>
>> 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 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
>>>
>>> For the log4j2 figures your have the "immediateFlush" property set to
>>> false. For the logback figures you have "immediateFlush" property set
>>> to true.
>>>
>>> Quoting from [2] and [3]
>>>
>>> By default, the OutputStream is immediately flushed, unless the
>>> immediateFlush property is explicitly set to 'false'. Setting the
>>> immediateFlush property to false can significantly improve logging
>>> throughput.
>>>
>>> The default value for immediateFlush is 'true'. Immediate flushing of
>>> the output stream ensures that logging events are immediately written
>>> to disk and will not be lost in case your application exits without
>>> properly closing appenders. On the other hand, setting this property
>>> to 'false' is likely to quintuple (your mileage may vary) logging
>>> throughput. As mentioned previously, if immediateFlush is set to
>>> 'false' and if appenders are not closed properly when your application
>>> exits, then logging events not yet written to disk may be lost. ===
>>> ====
>>>
>>> For an honest comparison, both frameworks should use comparable
>>> settings. In this particular case, the setting is called
>>> "immediateFlush" and carries the same name in both frameworks.
>>>
>>>
>>> [1] http://logging.apache.org/log4j/2.x/performance.html
>>> [2] http://logback.qos.ch/manual/encoders.html#LayoutWrappingEncoder
>>> [3] http://logback.qos.ch/manual/encoders.html#immediateFlush
>>>
>>> --
>>> Ceki
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>
>
>
> --
> http://www.grobmeier.de
> https://www.timeandbill.de
>
> ---------------------------------------------------------------------
> 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: performance comparison
Posted by Christian Grobmeier <gr...@gmail.com>.
On Sat, Sep 22, 2012 at 3:46 PM, Ralph Goers <ra...@dslextreme.com> 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
which settings.
Cheers
> 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 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
>>
>> For the log4j2 figures your have the "immediateFlush" property set to
>> false. For the logback figures you have "immediateFlush" property set
>> to true.
>>
>> Quoting from [2] and [3]
>>
>> By default, the OutputStream is immediately flushed, unless the
>> immediateFlush property is explicitly set to 'false'. Setting the
>> immediateFlush property to false can significantly improve logging
>> throughput.
>>
>> The default value for immediateFlush is 'true'. Immediate flushing of
>> the output stream ensures that logging events are immediately written
>> to disk and will not be lost in case your application exits without
>> properly closing appenders. On the other hand, setting this property
>> to 'false' is likely to quintuple (your mileage may vary) logging
>> throughput. As mentioned previously, if immediateFlush is set to
>> 'false' and if appenders are not closed properly when your application
>> exits, then logging events not yet written to disk may be lost. ===
>> ====
>>
>> For an honest comparison, both frameworks should use comparable
>> settings. In this particular case, the setting is called
>> "immediateFlush" and carries the same name in both frameworks.
>>
>>
>> [1] http://logging.apache.org/log4j/2.x/performance.html
>> [2] http://logback.qos.ch/manual/encoders.html#LayoutWrappingEncoder
>> [3] http://logback.qos.ch/manual/encoders.html#immediateFlush
>>
>> --
>> Ceki
>>
>> ---------------------------------------------------------------------
>> 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
>
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: performance comparison
Posted by Ralph Goers <ra...@dslextreme.com>.
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 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
>
> For the log4j2 figures your have the "immediateFlush" property set to
> false. For the logback figures you have "immediateFlush" property set
> to true.
>
> Quoting from [2] and [3]
>
> By default, the OutputStream is immediately flushed, unless the
> immediateFlush property is explicitly set to 'false'. Setting the
> immediateFlush property to false can significantly improve logging
> throughput.
>
> The default value for immediateFlush is 'true'. Immediate flushing of
> the output stream ensures that logging events are immediately written
> to disk and will not be lost in case your application exits without
> properly closing appenders. On the other hand, setting this property
> to 'false' is likely to quintuple (your mileage may vary) logging
> throughput. As mentioned previously, if immediateFlush is set to
> 'false' and if appenders are not closed properly when your application
> exits, then logging events not yet written to disk may be lost. ===
> ====
>
> For an honest comparison, both frameworks should use comparable
> settings. In this particular case, the setting is called
> "immediateFlush" and carries the same name in both frameworks.
>
>
> [1] http://logging.apache.org/log4j/2.x/performance.html
> [2] http://logback.qos.ch/manual/encoders.html#LayoutWrappingEncoder
> [3] http://logback.qos.ch/manual/encoders.html#immediateFlush
>
> --
> Ceki
>
> ---------------------------------------------------------------------
> 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
performance comparison
Posted by ceki <ce...@qos.ch>.
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
For the log4j2 figures your have the "immediateFlush" property set to
false. For the logback figures you have "immediateFlush" property set
to true.
Quoting from [2] and [3]
By default, the OutputStream is immediately flushed, unless the
immediateFlush property is explicitly set to 'false'. Setting the
immediateFlush property to false can significantly improve logging
throughput.
The default value for immediateFlush is 'true'. Immediate flushing of
the output stream ensures that logging events are immediately written
to disk and will not be lost in case your application exits without
properly closing appenders. On the other hand, setting this property
to 'false' is likely to quintuple (your mileage may vary) logging
throughput. As mentioned previously, if immediateFlush is set to
'false' and if appenders are not closed properly when your application
exits, then logging events not yet written to disk may be lost. ===
====
For an honest comparison, both frameworks should use comparable
settings. In this particular case, the setting is called
"immediateFlush" and carries the same name in both frameworks.
[1] http://logging.apache.org/log4j/2.x/performance.html
[2] http://logback.qos.ch/manual/encoders.html#LayoutWrappingEncoder
[3] http://logback.qos.ch/manual/encoders.html#immediateFlush
--
Ceki
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j2 site design
Posted by Ralph Goers <rg...@apache.org>.
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 <tg...@gmail.com> 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 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.net/log4j2/manual/configuration/automatic-configuration.html making pages smaller is not that important especially if you can give us a zip to download or maybe we should try wget
>
> * Alpha says alpha on this page http://logging.apache.org/ and when I click http://logging.apache.org/log4j/2.x/ says alpha there too
> (Version: 2.0-alpha2)
>
> On 9/22/2012 1:20 AM, Ralph Goers wrote:
>> Yeah - I agree on both counts. You will notice I did the same thing with the API. 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.
>>
>> Ralph
>>
>> On Sep 21, 2012, at 12:21 PM, Christian Grobmeier wrote:
>>
>>> On Fri, Sep 21, 2012 at 9:16 PM, Ivan Habunek <iv...@gmail.com> wrote:
>>>> Ralph,
>>>>
>>>> How would you feel about breaking up the really long pages, e.g.
>>>> configuration, into smaller ones?
>>> I see, it is always good to have a web dev in team.
>>> Personally I like this very much.
>>>
>>> Cheers
>>>
>>> PS: as you may have noticed, I am not Ralph :-)
>>>
>>>
>>>
>
>
> ---------------------------------------------------------------------
> 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: log4j2 site design
Posted by Tushar Kapila <tg...@gmail.com>.
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.net/log4j2/manual/configuration/automatic-configuration.html
making pages smaller is not that important especially if you can give us
a zip to download or maybe we should try wget
* Alpha says alpha on this page http://logging.apache.org/ and when I
click http://logging.apache.org/log4j/2.x/ says alpha there too
(Version: 2.0-alpha2)
On 9/22/2012 1:20 AM, Ralph Goers wrote:
> Yeah - I agree on both counts. You will notice I did the same thing with the API. 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.
>
> Ralph
>
> On Sep 21, 2012, at 12:21 PM, Christian Grobmeier wrote:
>
>> On Fri, Sep 21, 2012 at 9:16 PM, Ivan Habunek <iv...@gmail.com> wrote:
>>> Ralph,
>>>
>>> How would you feel about breaking up the really long pages, e.g.
>>> configuration, into smaller ones?
>> I see, it is always good to have a web dev in team.
>> Personally I like this very much.
>>
>> Cheers
>>
>> PS: as you may have noticed, I am not Ralph :-)
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j2 site design
Posted by Ralph Goers <ra...@dslextreme.com>.
Yeah - I agree on both counts. You will notice I did the same thing with the API. 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.
Ralph
On Sep 21, 2012, at 12:21 PM, Christian Grobmeier wrote:
> On Fri, Sep 21, 2012 at 9:16 PM, Ivan Habunek <iv...@gmail.com> wrote:
>> Ralph,
>>
>> How would you feel about breaking up the really long pages, e.g.
>> configuration, into smaller ones?
>
> I see, it is always good to have a web dev in team.
> Personally I like this very much.
>
> Cheers
>
> PS: as you may have noticed, I am not Ralph :-)
>
>
>> I've done a quick demo of how that would look (note that I've only
>> done configuration, not others).
>> http://bezdomni.net/log4j2/manual/configuration/index.html
>>
>> It may require a little bit of re-arranging things so not to have too
>> small pages, but generally, I think it's better this way.
>>
>> Regards,
>> Ivan
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>
>
>
> --
> http://www.grobmeier.de
> https://www.timeandbill.de
>
> ---------------------------------------------------------------------
> 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: log4j2 site design
Posted by Ivan Habunek <iv...@gmail.com>.
On 21 September 2012 21:21, Christian Grobmeier <gr...@gmail.com> 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, I am not Ralph :-)
Yes, I might have. :)
Ivan
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j2 site design
Posted by Christian Grobmeier <gr...@gmail.com>.
On Fri, Sep 21, 2012 at 9:16 PM, Ivan Habunek <iv...@gmail.com> wrote:
> Ralph,
>
> How would you feel about breaking up the really long pages, e.g.
> configuration, into smaller ones?
I see, it is always good to have a web dev in team.
Personally I like this very much.
Cheers
PS: as you may have noticed, I am not Ralph :-)
> I've done a quick demo of how that would look (note that I've only
> done configuration, not others).
> http://bezdomni.net/log4j2/manual/configuration/index.html
>
> It may require a little bit of re-arranging things so not to have too
> small pages, but generally, I think it's better this way.
>
> Regards,
> Ivan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j2 site design
Posted by Ivan Habunek <iv...@gmail.com>.
Ralph,
How would you feel about breaking up the really long pages, e.g.
configuration, into smaller ones?
I've done a quick demo of how that would look (note that I've only
done configuration, not others).
http://bezdomni.net/log4j2/manual/configuration/index.html
It may require a little bit of re-arranging things so not to have too
small pages, but generally, I think it's better this way.
Regards,
Ivan
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j2 site design
Posted by Ivan Habunek <iv...@gmail.com>.
On 21 September 2012 21:00, Christian Grobmeier <gr...@gmail.com> wrote:
>> Maybe it's time to try git-svn.
>
> Its fine with git-svn... if you need a starter:
> http://wiki.apache.org/logging/UsingGitWithLogging
>
> Cheers!
Thanks, just what I needed. :)
Ivan
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j2 site design
Posted by Christian Grobmeier <gr...@gmail.com>.
On Fri, Sep 21, 2012 at 8:46 PM, Ivan Habunek <iv...@gmail.com> wrote:
> On 21 September 2012 00:37, Ralph Goers <ra...@dslextreme.com> wrote:
>> I do like that the text in the sidebar doesn't seem to wrap like it does with the fluido skin. I'm not sure if that is just because it is wider or if it is wider to accommodate the text.
>>
>> Can you modify it to incorporate the header?
>
> I'll give it a go.
>
> Darn, I just got used to working with git and now I have to work on
> svn. Not happy. Apache should move to github. :)
>
> Maybe it's time to try git-svn.
Its fine with git-svn... if you need a starter:
http://wiki.apache.org/logging/UsingGitWithLogging
Cheers!
>
> Regards,
> Ivan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j2 site design
Posted by Ivan Habunek <iv...@gmail.com>.
On 21 September 2012 00:37, Ralph Goers <ra...@dslextreme.com> wrote:
> I do like that the text in the sidebar doesn't seem to wrap like it does with the fluido skin. I'm not sure if that is just because it is wider or if it is wider to accommodate the text.
>
> Can you modify it to incorporate the header?
I'll give it a go.
Darn, I just got used to working with git and now I have to work on
svn. Not happy. Apache should move to github. :)
Maybe it's time to try git-svn.
Regards,
Ivan
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j2 site design
Posted by Ralph Goers <ra...@dslextreme.com>.
I do like that the text in the sidebar doesn't seem to wrap like it does with the fluido skin. I'm not sure if that is just because it is wider or if it is wider to accommodate the text.
Can you modify it to incorporate the header?
Ralph
On Sep 20, 2012, at 3:26 PM, Ralph Goers wrote:
> While the font and sidebar are a bit crisper and cleaner i do miss having the Log4j logo. Also, it doesn't resolve the area that I think is the toughest nut to crack - the fact that it is a multi-module site.
>
> As you pointed out, clicking on a component name causes the bottom portion of the sidebar to change to show all the project reports for that component. This isn't intuitively obvious. For example, I was asked off-list just yesterday where the API javadocs are. It isn't obvious that you need to click on "API" and then select project reports to get to the javadoc. However, I don't like the idea of aggregated javadocs either as then it isn't clear which are "core" and which are from optional components.
>
> Likewise, I was asked to package the manual as a zip. Normally "mvn site" has to be invoked separate from the release, which makes it hard to package the manual as part of the release. I'd also like the manual to be downloadable as a pdf or in some other easy-to-read-offline format.
>
> FWIW - I looked at the table you don't like in the Architecture section. To me it looks fine. But I'm colorblind and so I tend to pick bright colors.
>
> Ralph
>
>
> On Sep 20, 2012, at 2:25 PM, Ivan Habunek wrote:
>
>> Hi Ralph & co,
>>
>> Since you mentioned you had site design issues, I tried applying the
>> log4php template I created to log4j2 site. Seems to work pretty well.
>>
>> Check out this quick demo, especially the cool vertically fixed sidebar :D
>> http://bezdomni.net/log4j2/
>>
>> If you're interested, I could adapt the template and change the source
>> files to use bootstrap features. It would require some work but is
>> doable.
>>
>> One potential problem I see is that this design does not have a logo
>> on the top of the page. Don't know how attached you are to having the
>> logo there.
>>
>> Regards,
>> Ivan
>>
>> ---------------------------------------------------------------------
>> 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: log4j2 site design
Posted by Ralph Goers <ra...@dslextreme.com>.
While the font and sidebar are a bit crisper and cleaner i do miss having the Log4j logo. Also, it doesn't resolve the area that I think is the toughest nut to crack - the fact that it is a multi-module site.
As you pointed out, clicking on a component name causes the bottom portion of the sidebar to change to show all the project reports for that component. This isn't intuitively obvious. For example, I was asked off-list just yesterday where the API javadocs are. It isn't obvious that you need to click on "API" and then select project reports to get to the javadoc. However, I don't like the idea of aggregated javadocs either as then it isn't clear which are "core" and which are from optional components.
Likewise, I was asked to package the manual as a zip. Normally "mvn site" has to be invoked separate from the release, which makes it hard to package the manual as part of the release. I'd also like the manual to be downloadable as a pdf or in some other easy-to-read-offline format.
FWIW - I looked at the table you don't like in the Architecture section. To me it looks fine. But I'm colorblind and so I tend to pick bright colors.
Ralph
On Sep 20, 2012, at 2:25 PM, Ivan Habunek wrote:
> Hi Ralph & co,
>
> Since you mentioned you had site design issues, I tried applying the
> log4php template I created to log4j2 site. Seems to work pretty well.
>
> Check out this quick demo, especially the cool vertically fixed sidebar :D
> http://bezdomni.net/log4j2/
>
> If you're interested, I could adapt the template and change the source
> files to use bootstrap features. It would require some work but is
> doable.
>
> One potential problem I see is that this design does not have a logo
> on the top of the page. Don't know how attached you are to having the
> logo there.
>
> Regards,
> Ivan
>
> ---------------------------------------------------------------------
> 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