You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jspwiki.apache.org by "Glen Mazza (JIRA)" <ji...@apache.org> on 2013/07/28 18:17:48 UTC
[jira] [Created] (JSPWIKI-795) Update logging subsystem in JSPWiki
Glen Mazza created JSPWIKI-795:
----------------------------------
Summary: Update logging subsystem in JSPWiki
Key: JSPWIKI-795
URL: https://issues.apache.org/jira/browse/JSPWIKI-795
Project: JSPWiki
Issue Type: Improvement
Reporter: Glen Mazza
Juan Pablo recommended a switch to SLF4J + [Logback | Log4j2].
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Created] (JSPWIKI-795) Update logging subsystem in JSPWiki
Posted by Harry Metske <ha...@gmail.com>.
This discussion (logging for JSPWiki) has been done before 5 years ago, see
JSPWIKI-376 [#1].
It also has already been implemented in JSPWIKI 3.0, but got regressed when
we decided to drop JCR and Stripes and going with 2.9.
I have read both the pro's and con's and in the end I don't mind that much,
at the moment I would opt for doing nothing and spend time on the other
issues.
BTW: [#1] also notes that you cannot use MBeans if you want the slf4j
facade.
So a +0 from me here.
regards,
Harry
[#1] - https://issues.apache.org/jira/browse/JSPWIKI-376
On 30 July 2013 02:36, Ichiro Furusato <ic...@gmail.com> wrote:
> Hi Juan Pablo,
>
> I don't have a vote here, nor am I advocating for one really. I'm just
> noting
> that in three relatively large enterprise environments that I know of
> recently
> they are all using Log4j, having discussed (similar to the discussion here)
> alternatives such as SLF4j. I certainly understand the rationale for SLF4j,
> especially in a world where there is a requirement for mixed libraries, so
> I
> suppose I don't have an alternative in that regard.
>
> A recent large-scale project involved a bespoke approach that sounds
> similar to your LoggerManager idea, and while that worked find (and
> fulfilled a requirement of logging messages to different logs depending
> on context) it did mean that of the thousands of files in the project they
> all used this bespoke logger rather than a "standard" like Log4j. I found
> this a rather ugly solution in that the project was locked into this
> solution
> and any deficiencies (such as scaleability or bug fixes by an external
> team focused on logging) weren't really met.
>
> In any case, just throwing in my 2c on finding little value in the SLF4j
> approach, but certainly YMMV. Logging in Java has always been an
> issue -- too bad log4j hadn't been adopted into the JDK instead of it
> into Apache, then we'd not really have any need for the facades... too
> late for that sadly.
>
> Ichiro
>
>
> On Tue, Jul 30, 2013 at 10:17 AM, Juan Pablo Santos Rodríguez <
> juanpablo.santos@gmail.com> wrote:
>
> > Hi Ichiro,
> >
> > we're relying on several 3rd party libraries, each of them relying on
> > several logging frameworks. SLF4J would allow us to consolidate all
> > application-related logging to the same place. It also supports
> > parameterized log messages, which is a nice to have. As the underlying
> > logging framework, Logback is seen as the evolution of log4j (done by the
> > same author + [#1]). On the other hand, log4j 2 looks pretty nice too,
> > seems it's faster and has more features, however it's still in beta, so
> API
> > may be broken towards 1.0.0.
> >
> > Regardless we stick to Log4J, switch to SLF4J+Logback, use Log4j2 or
> > whatever, what I was having in mind was:
> >
> > - having a custom facade: o.a.w.log.WLogger (or WikiLogger, name doesn't
> > matter right now). It should have the logging methods we're all used to
> > (debug, info, etc) and would hide the log implementation used throughout
> > the application. I think this should be a must, reasons below.
> > - means to change the log level of a given package at runtime, with no
> > restarts required. Most probably through an JMX MBean (btw logback
> provides
> > means to do this up to method level)
> > - a LoggerManager to be init'ed from WikiEngine/EntityManager, performing
> > start-up and shutdown tasks related to logging (read jspwiki.property as
> > config file, init'ing and destroying the MBean and maybe some more
> things)
> >
> > If we isolate the logging framework and later on we decide that the
> changes
> > weren't good enough, we can revert to log4j again as the underlying
> logging
> > implementation, without touching mostly every single file from src.
> > Switching to SLF4J + Logback or Log4j2 as the logging framework is
> > something to be done as soon as we have isolated the logging framework.
> > They require more or less the same amount of configuration as Log4J and
> > they provide additional benefits enough to make me think it's worth the
> > effort.
> >
> > Finally, as switching the underlying logging library is a big change, I
> > think we should run a vote here at dev to decide which library to use
> >
> >
> > br,
> > juan pablo
> >
> >
> > [#1]: logback.qos.ch/reasonsToSwitch.html IMO, esp. interesting
> automatic
> > compression for FileAppender and graceful recovery from I/O errors
> >
> > On Mon, Jul 29, 2013 at 11:48 PM, Glen Mazza <gl...@gmail.com>
> wrote:
> >
> > > I put that item in because JP had requested it. JP +1'ed Style C/Sun
> > > indentation, which makes you and me happy, so I'll happily give him his
> > > logging preference of choice, as long as it's a competent solution, and
> > it
> > > is, so that's good enough for me. On a team, you have to give and take
> > to
> > > make everyone happy.
> > >
> > > Glen
> > >
> > >
> > > On 07/29/2013 05:08 PM, Ichiro Furusato wrote:
> > >
> > >> I've followed this debate for years now and it's hard to really
> justify
> > >> (to
> > >> my mind at least)
> > >> not simply going with Log4j. It's all but a standard. I've used the
> > JDK's
> > >> logging facility
> > >> and SLF4J and there simply is no added benefit to a facade API. The
> only
> > >> real justification
> > >> would be a project where one didn't want to use *any* additional
> > >> libraries.
> > >> As JSPWiki
> > >> is hardly in that category I'd recommend simply including the
> log4j.jar
> > >> file and being done
> > >> with it. Log4j works fine and pretty much the entire Java community
> > knows
> > >> and uses it.
> > >> Having a facade over it doesn't really provide any benefits and makes
> > log
> > >> configuration
> > >> just a bit more complicated, especially when JSPWiki is being used in
> a
> > >> mixed logging
> > >> environment.
> > >>
> > >> So I'd be interested in hearing the arguments in favour of SLF4j,
> i.e.,
> > >> what actual gains
> > >> are expected.
> > >>
> > >> Ichiro
> > >>
> > >>
> > >>
> > >> On Mon, Jul 29, 2013 at 4:17 AM, Glen Mazza (JIRA) <ji...@apache.org>
> > >> wrote:
> > >>
> > >> Glen Mazza created JSPWIKI-795:
> > >>> ------------------------------**----
> > >>>
> > >>> Summary: Update logging subsystem in JSPWiki
> > >>> Key: JSPWIKI-795
> > >>> URL: https://issues.apache.org/**
> > >>> jira/browse/JSPWIKI-795<
> > https://issues.apache.org/jira/browse/JSPWIKI-795>
> > >>> Project: JSPWiki
> > >>> Issue Type: Improvement
> > >>> Reporter: Glen Mazza
> > >>>
> > >>>
> > >>> Juan Pablo recommended a switch to SLF4J + [Logback | Log4j2].
> > >>>
> > >>> --
> > >>> This message is automatically generated by JIRA.
> > >>> If you think it was sent incorrectly, please contact your JIRA
> > >>> administrators
> > >>> For more information on JIRA, see: http://www.atlassian.com/**
> > >>> software/jira <http://www.atlassian.com/software/jira>
> > >>>
> > >>>
> > >
> >
>
Re: [jira] [Created] (JSPWIKI-795) Update logging subsystem in JSPWiki
Posted by Ichiro Furusato <ic...@gmail.com>.
Hi Juan Pablo,
I don't have a vote here, nor am I advocating for one really. I'm just
noting
that in three relatively large enterprise environments that I know of
recently
they are all using Log4j, having discussed (similar to the discussion here)
alternatives such as SLF4j. I certainly understand the rationale for SLF4j,
especially in a world where there is a requirement for mixed libraries, so I
suppose I don't have an alternative in that regard.
A recent large-scale project involved a bespoke approach that sounds
similar to your LoggerManager idea, and while that worked find (and
fulfilled a requirement of logging messages to different logs depending
on context) it did mean that of the thousands of files in the project they
all used this bespoke logger rather than a "standard" like Log4j. I found
this a rather ugly solution in that the project was locked into this
solution
and any deficiencies (such as scaleability or bug fixes by an external
team focused on logging) weren't really met.
In any case, just throwing in my 2c on finding little value in the SLF4j
approach, but certainly YMMV. Logging in Java has always been an
issue -- too bad log4j hadn't been adopted into the JDK instead of it
into Apache, then we'd not really have any need for the facades... too
late for that sadly.
Ichiro
On Tue, Jul 30, 2013 at 10:17 AM, Juan Pablo Santos Rodríguez <
juanpablo.santos@gmail.com> wrote:
> Hi Ichiro,
>
> we're relying on several 3rd party libraries, each of them relying on
> several logging frameworks. SLF4J would allow us to consolidate all
> application-related logging to the same place. It also supports
> parameterized log messages, which is a nice to have. As the underlying
> logging framework, Logback is seen as the evolution of log4j (done by the
> same author + [#1]). On the other hand, log4j 2 looks pretty nice too,
> seems it's faster and has more features, however it's still in beta, so API
> may be broken towards 1.0.0.
>
> Regardless we stick to Log4J, switch to SLF4J+Logback, use Log4j2 or
> whatever, what I was having in mind was:
>
> - having a custom facade: o.a.w.log.WLogger (or WikiLogger, name doesn't
> matter right now). It should have the logging methods we're all used to
> (debug, info, etc) and would hide the log implementation used throughout
> the application. I think this should be a must, reasons below.
> - means to change the log level of a given package at runtime, with no
> restarts required. Most probably through an JMX MBean (btw logback provides
> means to do this up to method level)
> - a LoggerManager to be init'ed from WikiEngine/EntityManager, performing
> start-up and shutdown tasks related to logging (read jspwiki.property as
> config file, init'ing and destroying the MBean and maybe some more things)
>
> If we isolate the logging framework and later on we decide that the changes
> weren't good enough, we can revert to log4j again as the underlying logging
> implementation, without touching mostly every single file from src.
> Switching to SLF4J + Logback or Log4j2 as the logging framework is
> something to be done as soon as we have isolated the logging framework.
> They require more or less the same amount of configuration as Log4J and
> they provide additional benefits enough to make me think it's worth the
> effort.
>
> Finally, as switching the underlying logging library is a big change, I
> think we should run a vote here at dev to decide which library to use
>
>
> br,
> juan pablo
>
>
> [#1]: logback.qos.ch/reasonsToSwitch.html IMO, esp. interesting automatic
> compression for FileAppender and graceful recovery from I/O errors
>
> On Mon, Jul 29, 2013 at 11:48 PM, Glen Mazza <gl...@gmail.com> wrote:
>
> > I put that item in because JP had requested it. JP +1'ed Style C/Sun
> > indentation, which makes you and me happy, so I'll happily give him his
> > logging preference of choice, as long as it's a competent solution, and
> it
> > is, so that's good enough for me. On a team, you have to give and take
> to
> > make everyone happy.
> >
> > Glen
> >
> >
> > On 07/29/2013 05:08 PM, Ichiro Furusato wrote:
> >
> >> I've followed this debate for years now and it's hard to really justify
> >> (to
> >> my mind at least)
> >> not simply going with Log4j. It's all but a standard. I've used the
> JDK's
> >> logging facility
> >> and SLF4J and there simply is no added benefit to a facade API. The only
> >> real justification
> >> would be a project where one didn't want to use *any* additional
> >> libraries.
> >> As JSPWiki
> >> is hardly in that category I'd recommend simply including the log4j.jar
> >> file and being done
> >> with it. Log4j works fine and pretty much the entire Java community
> knows
> >> and uses it.
> >> Having a facade over it doesn't really provide any benefits and makes
> log
> >> configuration
> >> just a bit more complicated, especially when JSPWiki is being used in a
> >> mixed logging
> >> environment.
> >>
> >> So I'd be interested in hearing the arguments in favour of SLF4j, i.e.,
> >> what actual gains
> >> are expected.
> >>
> >> Ichiro
> >>
> >>
> >>
> >> On Mon, Jul 29, 2013 at 4:17 AM, Glen Mazza (JIRA) <ji...@apache.org>
> >> wrote:
> >>
> >> Glen Mazza created JSPWIKI-795:
> >>> ------------------------------**----
> >>>
> >>> Summary: Update logging subsystem in JSPWiki
> >>> Key: JSPWIKI-795
> >>> URL: https://issues.apache.org/**
> >>> jira/browse/JSPWIKI-795<
> https://issues.apache.org/jira/browse/JSPWIKI-795>
> >>> Project: JSPWiki
> >>> Issue Type: Improvement
> >>> Reporter: Glen Mazza
> >>>
> >>>
> >>> Juan Pablo recommended a switch to SLF4J + [Logback | Log4j2].
> >>>
> >>> --
> >>> This message is automatically generated by JIRA.
> >>> If you think it was sent incorrectly, please contact your JIRA
> >>> administrators
> >>> For more information on JIRA, see: http://www.atlassian.com/**
> >>> software/jira <http://www.atlassian.com/software/jira>
> >>>
> >>>
> >
>
Re: [jira] [Created] (JSPWIKI-795) Update logging subsystem in JSPWiki
Posted by Juan Pablo Santos Rodríguez <ju...@gmail.com>.
Hi Ichiro,
we're relying on several 3rd party libraries, each of them relying on
several logging frameworks. SLF4J would allow us to consolidate all
application-related logging to the same place. It also supports
parameterized log messages, which is a nice to have. As the underlying
logging framework, Logback is seen as the evolution of log4j (done by the
same author + [#1]). On the other hand, log4j 2 looks pretty nice too,
seems it's faster and has more features, however it's still in beta, so API
may be broken towards 1.0.0.
Regardless we stick to Log4J, switch to SLF4J+Logback, use Log4j2 or
whatever, what I was having in mind was:
- having a custom facade: o.a.w.log.WLogger (or WikiLogger, name doesn't
matter right now). It should have the logging methods we're all used to
(debug, info, etc) and would hide the log implementation used throughout
the application. I think this should be a must, reasons below.
- means to change the log level of a given package at runtime, with no
restarts required. Most probably through an JMX MBean (btw logback provides
means to do this up to method level)
- a LoggerManager to be init'ed from WikiEngine/EntityManager, performing
start-up and shutdown tasks related to logging (read jspwiki.property as
config file, init'ing and destroying the MBean and maybe some more things)
If we isolate the logging framework and later on we decide that the changes
weren't good enough, we can revert to log4j again as the underlying logging
implementation, without touching mostly every single file from src.
Switching to SLF4J + Logback or Log4j2 as the logging framework is
something to be done as soon as we have isolated the logging framework.
They require more or less the same amount of configuration as Log4J and
they provide additional benefits enough to make me think it's worth the
effort.
Finally, as switching the underlying logging library is a big change, I
think we should run a vote here at dev to decide which library to use
br,
juan pablo
[#1]: logback.qos.ch/reasonsToSwitch.html IMO, esp. interesting automatic
compression for FileAppender and graceful recovery from I/O errors
On Mon, Jul 29, 2013 at 11:48 PM, Glen Mazza <gl...@gmail.com> wrote:
> I put that item in because JP had requested it. JP +1'ed Style C/Sun
> indentation, which makes you and me happy, so I'll happily give him his
> logging preference of choice, as long as it's a competent solution, and it
> is, so that's good enough for me. On a team, you have to give and take to
> make everyone happy.
>
> Glen
>
>
> On 07/29/2013 05:08 PM, Ichiro Furusato wrote:
>
>> I've followed this debate for years now and it's hard to really justify
>> (to
>> my mind at least)
>> not simply going with Log4j. It's all but a standard. I've used the JDK's
>> logging facility
>> and SLF4J and there simply is no added benefit to a facade API. The only
>> real justification
>> would be a project where one didn't want to use *any* additional
>> libraries.
>> As JSPWiki
>> is hardly in that category I'd recommend simply including the log4j.jar
>> file and being done
>> with it. Log4j works fine and pretty much the entire Java community knows
>> and uses it.
>> Having a facade over it doesn't really provide any benefits and makes log
>> configuration
>> just a bit more complicated, especially when JSPWiki is being used in a
>> mixed logging
>> environment.
>>
>> So I'd be interested in hearing the arguments in favour of SLF4j, i.e.,
>> what actual gains
>> are expected.
>>
>> Ichiro
>>
>>
>>
>> On Mon, Jul 29, 2013 at 4:17 AM, Glen Mazza (JIRA) <ji...@apache.org>
>> wrote:
>>
>> Glen Mazza created JSPWIKI-795:
>>> ------------------------------**----
>>>
>>> Summary: Update logging subsystem in JSPWiki
>>> Key: JSPWIKI-795
>>> URL: https://issues.apache.org/**
>>> jira/browse/JSPWIKI-795<https://issues.apache.org/jira/browse/JSPWIKI-795>
>>> Project: JSPWiki
>>> Issue Type: Improvement
>>> Reporter: Glen Mazza
>>>
>>>
>>> Juan Pablo recommended a switch to SLF4J + [Logback | Log4j2].
>>>
>>> --
>>> This message is automatically generated by JIRA.
>>> If you think it was sent incorrectly, please contact your JIRA
>>> administrators
>>> For more information on JIRA, see: http://www.atlassian.com/**
>>> software/jira <http://www.atlassian.com/software/jira>
>>>
>>>
>
Re: [jira] [Created] (JSPWIKI-795) Update logging subsystem in JSPWiki
Posted by Glen Mazza <gl...@gmail.com>.
I put that item in because JP had requested it. JP +1'ed Style C/Sun
indentation, which makes you and me happy, so I'll happily give him his
logging preference of choice, as long as it's a competent solution, and
it is, so that's good enough for me. On a team, you have to give and
take to make everyone happy.
Glen
On 07/29/2013 05:08 PM, Ichiro Furusato wrote:
> I've followed this debate for years now and it's hard to really justify (to
> my mind at least)
> not simply going with Log4j. It's all but a standard. I've used the JDK's
> logging facility
> and SLF4J and there simply is no added benefit to a facade API. The only
> real justification
> would be a project where one didn't want to use *any* additional libraries.
> As JSPWiki
> is hardly in that category I'd recommend simply including the log4j.jar
> file and being done
> with it. Log4j works fine and pretty much the entire Java community knows
> and uses it.
> Having a facade over it doesn't really provide any benefits and makes log
> configuration
> just a bit more complicated, especially when JSPWiki is being used in a
> mixed logging
> environment.
>
> So I'd be interested in hearing the arguments in favour of SLF4j, i.e.,
> what actual gains
> are expected.
>
> Ichiro
>
>
>
> On Mon, Jul 29, 2013 at 4:17 AM, Glen Mazza (JIRA) <ji...@apache.org> wrote:
>
>> Glen Mazza created JSPWIKI-795:
>> ----------------------------------
>>
>> Summary: Update logging subsystem in JSPWiki
>> Key: JSPWIKI-795
>> URL: https://issues.apache.org/jira/browse/JSPWIKI-795
>> Project: JSPWiki
>> Issue Type: Improvement
>> Reporter: Glen Mazza
>>
>>
>> Juan Pablo recommended a switch to SLF4J + [Logback | Log4j2].
>>
>> --
>> This message is automatically generated by JIRA.
>> If you think it was sent incorrectly, please contact your JIRA
>> administrators
>> For more information on JIRA, see: http://www.atlassian.com/software/jira
>>
Re: [jira] [Created] (JSPWIKI-795) Update logging subsystem in JSPWiki
Posted by Ichiro Furusato <ic...@gmail.com>.
I've followed this debate for years now and it's hard to really justify (to
my mind at least)
not simply going with Log4j. It's all but a standard. I've used the JDK's
logging facility
and SLF4J and there simply is no added benefit to a facade API. The only
real justification
would be a project where one didn't want to use *any* additional libraries.
As JSPWiki
is hardly in that category I'd recommend simply including the log4j.jar
file and being done
with it. Log4j works fine and pretty much the entire Java community knows
and uses it.
Having a facade over it doesn't really provide any benefits and makes log
configuration
just a bit more complicated, especially when JSPWiki is being used in a
mixed logging
environment.
So I'd be interested in hearing the arguments in favour of SLF4j, i.e.,
what actual gains
are expected.
Ichiro
On Mon, Jul 29, 2013 at 4:17 AM, Glen Mazza (JIRA) <ji...@apache.org> wrote:
> Glen Mazza created JSPWIKI-795:
> ----------------------------------
>
> Summary: Update logging subsystem in JSPWiki
> Key: JSPWIKI-795
> URL: https://issues.apache.org/jira/browse/JSPWIKI-795
> Project: JSPWiki
> Issue Type: Improvement
> Reporter: Glen Mazza
>
>
> Juan Pablo recommended a switch to SLF4J + [Logback | Log4j2].
>
> --
> This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA
> administrators
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>