> On 29 May 2015, at 5:12 pm, Christoph Nenning
> 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.
>>
>
>
>
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
2015-05-29 8:59 GMT+02:00 Johannes Geppert :
> 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 ha
2015-05-29 8:59 GMT+02:00 Johannes Geppert :
> 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 ha
2015-05-29 9:12 GMT+02:00 Christoph Nenning :
> 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 :)
Reg
> >>
> >> 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
> On 29 May 2015, at 4:39 pm, Lukasz Lenart wrote:
>
> 2015-05-29 8:20 GMT+02:00 Joseph Walton :
>>
>> 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 wit
> >
> >> On 29 May 2015, at 3:55 pm, Lukasz Lenart
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
> consideratio
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
##
2015-05-29 8:20 GMT+02:00 Joseph Walton :
>
>> On 29 May 2015, at 3:55 pm, Lukasz Lenart 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 yo
> On 29 May 2015, at 3:55 pm, Lukasz Lenart 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
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 tha
12 matches
Mail list logo
