> 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.
>>
>
>
>
> 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
>
> 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
On 2 December 2014 at 20:24, Lukasz Lenart wrote:
> 2014-12-02 10:00 GMT+01:00 Joseph Walton :
> > I have OGNL expressions where I’m invoking static methods, and I’m
> specifically setting 'struts.ognl.allowStaticMethodAccess’ to allow that.
> >
> > Now, in 2.3.20,
I have OGNL expressions where I’m invoking static methods, and I’m specifically
setting 'struts.ognl.allowStaticMethodAccess’ to allow that.
Now, in 2.3.20, these invocations are checked by
SecurityMemberAccess.isClassExcluded with Class.class as the first argument.
Since this appears on the de
During a migration from WebWork to Struts2 I found all unset template
parameters were appearing as 'java.lang.Object@123abc'. It seems like
the underlying cause is WW-3603: after ParametersInterceptor has run
it sets CREATE_NULL_OBJECTS to false. However,
XWorkMapPropertyAccessor is checking for no
