You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Lukasz Lenart <lu...@apache.org> on 2015/05/29 07:55:53 UTC
Log42j
Hi,
Johannes started transforming Struts to use Log4j2 as a base logging
layer but I thought it'd just affect LoggingFactory in the way that
the Log4j2 would be the first option to consider when looking for
available logging layers on classpath.
With the current approach user can be surprised that they have to
reconfigure the whole logging layer because they are upgrading from
2.3 to 2.5 - it's too big change for minor update IMHO.
My assumption was that we do this in Struts 3 - drop other layers and
use Log4j2 as a main layer.
What do you think about that?
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Log42j
Posted by Lukasz Lenart <lu...@apache.org>.
2015-05-29 9:12 GMT+02:00 Christoph Nenning <Ch...@lex-com.net>:
> Log4j2 wants to provide the same benefits as slf4j does. AFAIK slf4j is a
> one man show while log4j2 has a bigger team and is backed by the ASF.
SLF4J and Log4j2 are comparable for me, but the other is from ASF
which is advantage over SLF4J :)
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Log42j
Posted by Joseph Walton <jw...@atlassian.com>.
> On 29 May 2015, at 5:12 pm, Christoph Nenning <Ch...@lex-com.net> wrote:
>
>>
>> Given that, perhaps direct use of SLF4J’s API would make it easier
>> to defer the choice of Log4j 2 or, for example, LogBack to runtime?
>> That way there would be no compile-time dependency on Log4j2-specific API.
>>
>
>
> From the log4j2 front page:
>
> http://logging.apache.org/log4j/2.x/ <http://logging.apache.org/log4j/2.x/>
Ah, great. I think http://logging.apache.org/log4j/2.x/log4j-api/apidocs/ <http://logging.apache.org/log4j/2.x/log4j-api/apidocs/> is what I was looking for, as documentation of the org.apache.logging.log4j:log4j-api artifact.
> Log4j2 wants to provide the same benefits as slf4j does. AFAIK slf4j is a
> one man show while log4j2 has a bigger team and is backed by the ASF.
It’s a shame to end up with two separate logging facades. Despite being a one-man project, SLF4J has a substantial number of contributors: https://github.com/qos-ch/slf4j/graphs/contributors <https://github.com/qos-ch/slf4j/graphs/contributors> - 36, to 7 for https://github.com/apache/logging-log4j2/graphs/contributors <https://github.com/apache/logging-log4j2/graphs/contributors>). It’s also widely proven, and stable.
That said, the Log4j 2 to SLF4J adaptor (https://logging.apache.org/log4j/2.0/log4j-to-slf4j/index.html <https://logging.apache.org/log4j/2.0/log4j-to-slf4j/index.html>) looks like it’ll make simple to use Struts with an existing SLF4J environment. Then everyone can get behind coding to a simple API and picking the best logging implementation at runtime.
Thanks for the pointers; looking forward to seeing simplification in Struts.
Re: Log42j
Posted by Christoph Nenning <Ch...@lex-com.net>.
> >>
> >> As long as you’re making changes to logging, have you given
> consideration to making SLF4J the standard facade in Struts? That
> would allow making Log4j2 the preferred implementation without
> impacting anyone who wanted to stick with Log4j “classic”.
> >
> > That's the idea behind using Log4j2 - it has the same capabilities as
> > SLF4J or even more - so we can drop existing XWork logging facade and
> > use directly Log4j2 as a facade but I have doubts if it isn't too
> > early :)
> >
> > https://logging.apache.org/log4j/2.0/log4j-1.2-api/index.html
> > https://logging.apache.org/log4j/2.0/log4j-slf4j-impl/index.html <
> https://logging.apache.org/log4j/2.0/log4j-slf4j-impl/index.html>
>
> These links suggest that code written to the Log4j 1.x API can
> bridge to Log4j 2.x:
>
> > The Log4j 1.2 Bridge allows applications coded to use Log4j 1.2
> API to use Log4j 2 instead.
>
> and that Log4j2 provides an SLF4J backend:
>
> > The Log4j 2 SLF4J Binding allows applications coded to the SLF4J
> API to use Log4j 2 as the implementation.
>
> (I can’t see any information about Log4j 2 providing its own facade,
> at first glance.)
>
> Given that, perhaps direct use of SLF4J’s API would make it easier
> to defer the choice of Log4j 2 or, for example, LogBack to runtime?
> That way there would be no compile-time dependency on Log4j2-specific
API.
>
From the log4j2 front page:
http://logging.apache.org/log4j/2.x/
>API Separation
> The API for Log4j is separate from the implementation making it clear
for application
> developers which classes and methods they can use while ensuring forward
compatibility.
> This allows the Log4j team to improve the implementation safely and in a
compatible manner.
> Support for multiple APIs
> While the Log4j 2 API will provide the best performance, Log4j 2
provides
> support for the SLF4J and Commons Logging APIs.
Log4j2 wants to provide the same benefits as slf4j does. AFAIK slf4j is a
one man show while log4j2 has a bigger team and is backed by the ASF.
Regards,
Christoph
This Email was scanned by Sophos Anti Virus
Re: Log42j
Posted by Joseph Walton <jw...@atlassian.com>.
> On 29 May 2015, at 4:39 pm, Lukasz Lenart <lu...@apache.org> wrote:
>
> 2015-05-29 8:20 GMT+02:00 Joseph Walton <jw...@atlassian.com>:
>>
>> As long as you’re making changes to logging, have you given consideration to making SLF4J the standard facade in Struts? That would allow making Log4j2 the preferred implementation without impacting anyone who wanted to stick with Log4j “classic”.
>
> That's the idea behind using Log4j2 - it has the same capabilities as
> SLF4J or even more - so we can drop existing XWork logging facade and
> use directly Log4j2 as a facade but I have doubts if it isn't too
> early :)
>
> https://logging.apache.org/log4j/2.0/log4j-1.2-api/index.html
> https://logging.apache.org/log4j/2.0/log4j-slf4j-impl/index.html <https://logging.apache.org/log4j/2.0/log4j-slf4j-impl/index.html>
These links suggest that code written to the Log4j 1.x API can bridge to Log4j 2.x:
> The Log4j 1.2 Bridge allows applications coded to use Log4j 1.2 API to use Log4j 2 instead.
and that Log4j2 provides an SLF4J backend:
> The Log4j 2 SLF4J Binding allows applications coded to the SLF4J API to use Log4j 2 as the implementation.
(I can’t see any information about Log4j 2 providing its own facade, at first glance.)
Given that, perhaps direct use of SLF4J’s API would make it easier to defer the choice of Log4j 2 or, for example, LogBack to runtime? That way there would be no compile-time dependency on Log4j2-specific API.
Re: Log42j
Posted by Christoph Nenning <Ch...@lex-com.net>.
> >
> >> On 29 May 2015, at 3:55 pm, Lukasz Lenart <lu...@apache.org>
wrote:
> > ...
> >> My assumption was that we do this in Struts 3 - drop other layers and
> >> use Log4j2 as a main layer.
> >>
> >> What do you think about that?
> >
> > As long as you’re making changes to logging, have you given
> consideration to making SLF4J the standard facade in Struts? That
> would allow making Log4j2 the preferred implementation without
> impacting anyone who wanted to stick with Log4j “classic”.
>
> That's the idea behind using Log4j2 - it has the same capabilities as
> SLF4J or even more - so we can drop existing XWork logging facade and
> use directly Log4j2 as a facade but I have doubts if it isn't too
> early :)
>
> https://logging.apache.org/log4j/2.0/log4j-1.2-api/index.html
> https://logging.apache.org/log4j/2.0/log4j-slf4j-impl/index.html
>
>
Well, there are already some other changes that have impact on users, like
moving plugins to archive or upgrading to JDK7. So IMHO it is ok to do the
logging changes in 2.5.
Regards,
Christoph
This Email was scanned by Sophos Anti Virus
Re: Log42j
Posted by Lukasz Lenart <lu...@apache.org>.
2015-05-29 8:20 GMT+02:00 Joseph Walton <jw...@atlassian.com>:
>
>> On 29 May 2015, at 3:55 pm, Lukasz Lenart <lu...@apache.org> wrote:
> ...
>> My assumption was that we do this in Struts 3 - drop other layers and
>> use Log4j2 as a main layer.
>>
>> What do you think about that?
>
> As long as you’re making changes to logging, have you given consideration to making SLF4J the standard facade in Struts? That would allow making Log4j2 the preferred implementation without impacting anyone who wanted to stick with Log4j “classic”.
That's the idea behind using Log4j2 - it has the same capabilities as
SLF4J or even more - so we can drop existing XWork logging facade and
use directly Log4j2 as a facade but I have doubts if it isn't too
early :)
https://logging.apache.org/log4j/2.0/log4j-1.2-api/index.html
https://logging.apache.org/log4j/2.0/log4j-slf4j-impl/index.html
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Log42j
Posted by Joseph Walton <jw...@atlassian.com>.
> On 29 May 2015, at 3:55 pm, Lukasz Lenart <lu...@apache.org> wrote:
...
> My assumption was that we do this in Struts 3 - drop other layers and
> use Log4j2 as a main layer.
>
> What do you think about that?
As long as you’re making changes to logging, have you given consideration to making SLF4J the standard facade in Struts? That would allow making Log4j2 the preferred implementation without impacting anyone who wanted to stick with Log4j “classic”.
It would also allow clearing out some of the xwork2 logging facade.
I know that the choice of facade is a fairly subjective choice; I’ve had good results with SLF4J.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Log42j
Posted by Johannes Geppert <jo...@gmail.com>.
Yes the old implementation is just marked as deprecated so no third party
plugins should crash.
Users could just use the log4j(1) bridge it's also usefully if you use
other third party components.
http://logging.apache.org/log4j/2.x/log4j-1.2-api/index.html
Indeed the Google App Engine problem is silly.
#################################################
web: http://www.jgeppert.com
twitter: http://twitter.com/jogep
2015-05-29 9:36 GMT+02:00 Lukasz Lenart <lu...@apache.org>:
> 2015-05-29 8:59 GMT+02:00 Johannes Geppert <jo...@apache.org>:
> > I would not say that this change is to big for this release.
> > I mean we drop 4 plugins and change to JDK7.
> > So adding a new dependency is not such a big change.
> > And with log4j2 the users can simply add a bridge.
> > So the migration path is not so hard and requires no code changes.
>
> Do I get it right that plugins which use the old logging facade will
> work without issue? And by default, even for old code, everything will
> be routed to Log4j2?
>
>
> Regards
> --
> Łukasz
> + 48 606 323 122 http://www.lenart.org.pl/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Log42j
Posted by Lukasz Lenart <lu...@apache.org>.
2015-05-29 8:59 GMT+02:00 Johannes Geppert <jo...@apache.org>:
> I would not say that this change is to big for this release.
> I mean we drop 4 plugins and change to JDK7.
> So adding a new dependency is not such a big change.
> And with log4j2 the users can simply add a bridge.
> So the migration path is not so hard and requires no code changes.
Do I get it right that plugins which use the old logging facade will
work without issue? And by default, even for old code, everything will
be routed to Log4j2?
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Log42j
Posted by Lukasz Lenart <lu...@apache.org>.
2015-05-29 8:59 GMT+02:00 Johannes Geppert <jo...@apache.org>:
> I would not say that this change is to big for this release.
> I mean we drop 4 plugins and change to JDK7.
> So adding a new dependency is not such a big change.
> And with log4j2 the users can simply add a bridge.
> So the migration path is not so hard and requires no code changes.
Dropping 4 plugins and switching to JDK7 was a piece-of-cake compering
to new logging facade ;-) Anyway I have some doubts (ie. AppEngine
complains) and would like to address them before we go further :)
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Log42j
Posted by Johannes Geppert <jo...@apache.org>.
I would not say that this change is to big for this release.
I mean we drop 4 plugins and change to JDK7.
So adding a new dependency is not such a big change.
And with log4j2 the users can simply add a bridge.
So the migration path is not so hard and requires no code changes.
Johannes
#################################################
web: http://www.jgeppert.com
twitter: http://twitter.com/jogep
2015-05-29 7:55 GMT+02:00 Lukasz Lenart <lu...@apache.org>:
> Hi,
>
> Johannes started transforming Struts to use Log4j2 as a base logging
> layer but I thought it'd just affect LoggingFactory in the way that
> the Log4j2 would be the first option to consider when looking for
> available logging layers on classpath.
>
> With the current approach user can be surprised that they have to
> reconfigure the whole logging layer because they are upgrading from
> 2.3 to 2.5 - it's too big change for minor update IMHO.
>
> My assumption was that we do this in Struts 3 - drop other layers and
> use Log4j2 as a main layer.
>
> What do you think about that?
>
>
> Regards
> --
> Łukasz
> + 48 606 323 122 http://www.lenart.org.pl/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>