Re: svn commit: r1098322 - /struts/sandbox/trunk/struts2-cdi-plugin/src/main/java/org/apache/struts2/cdi/CdiObjectFactory.java

2011-05-03 Thread Rene Gielen
Lukasz, why were you removing the logging gates, aka the if blocks around log statements? I agree that for simple String parameters (without concatenation) they might be left out, but for everything else they really help a lot for performance - that's why I use them in general. We should even con

Re: svn commit: r1098322 - /struts/sandbox/trunk/struts2-cdi-plugin/src/main/java/org/apache/struts2/cdi/CdiObjectFactory.java

2011-05-03 Thread Maurizio Cucchiara
I totally agree with René, in this way you pay the cost of string conversion/concatenation. On 3 May 2011 09:07, Rene Gielen wrote: > Lukasz, > > why were you removing the logging gates, aka the if blocks around log > statements? I agree that for simple String parameters (without > concatenation)

Re: [jira] [Commented] (WW-3474) JSR 330, javax.inject implementation in Struts2

2011-05-03 Thread Rene Gielen
Better, of course! On 01.05.11 16:23, Lukasz Lenart wrote: > What was the idea to use caching in CdiObjectFactory::getInjectionTarget() ? > > It can be a bit slow as it's using synchronize(this) each time (for > reading and writing). I've switched into ConcurrentHashMap but maybe > removing cache

Re: svn commit: r1098322 - /struts/sandbox/trunk/struts2-cdi-plugin/src/main/java/org/apache/struts2/cdi/CdiObjectFactory.java

2011-05-03 Thread Johannes Geppert
I also agree to René, we should wrap all debug and info messages. Johannes - -- web: http://www.jgeppert.com twitter: http://twitter.com/jogep -- View this message in context: http://struts.1045723.n5.nabble.com/Re-svn-commit-r1098322-struts-sandbox-trunk-struts2-cdi-plugin-src-

Re: svn commit: r1098322 - /struts/sandbox/trunk/struts2-cdi-plugin/src/main/java/org/apache/struts2/cdi/CdiObjectFactory.java

2011-05-03 Thread Rene Gielen
I'd even wrap WARN - sysops might configure to just log ERROR and FATAL :) On 03.05.11 10:00, Johannes Geppert wrote: > I also agree to René, we should wrap all debug and info messages. > > Johannes > > - > > -- > web: http://www.jgeppert.com > twitter: http://twitter.com/jogep

Re: svn commit: r1098322 - /struts/sandbox/trunk/struts2-cdi-plugin/src/main/java/org/apache/struts2/cdi/CdiObjectFactory.java

2011-05-03 Thread Rene Gielen
There is another possible solution / improvement we might want to think of: Switch our logging system to slf4j facade logging, which addresses - besides a lot of other cool things - the parameter evaluation issue with varags and late concatenation. See: http://www.slf4j.org/ http://www.slf4j.org/f

Re: svn commit: r1098322 - /struts/sandbox/trunk/struts2-cdi-plugin/src/main/java/org/apache/struts2/cdi/CdiObjectFactory.java

2011-05-03 Thread Johannes Geppert
I will going to fix this. https://issues.apache.org/jira/browse/WW-3619 Johannes - -- web: http://www.jgeppert.com twitter: http://twitter.com/jogep -- View this message in context: http://struts.1045723.n5.nabble.com/Re-svn-commit-r1098322-struts-sandbox-trunk-struts2-cdi-plug

Re: [VOTE] Release Struts 2.2.3

2011-05-03 Thread Rainer Hermanns
The things I could test with my running S2 apps work fine. Therefore, +1 GA (binding) cheers, Rainer Am 27.04.2011 um 22:29 schrieb Rene Gielen: > I would have wanted to spend a little more time on testing it, but from > what I can say it looks good, and Matt's performance issue seems to be > no

Re: svn commit: r1098322 - /struts/sandbox/trunk/struts2-cdi-plugin/src/main/java/org/apache/struts2/cdi/CdiObjectFactory.java

2011-05-03 Thread Rene Gielen
Great, thanks for taking this On 03.05.11 11:10, Johannes Geppert wrote: > I will going to fix this. > > https://issues.apache.org/jira/browse/WW-3619 > > Johannes > > - > > -- > web: http://www.jgeppert.com > twitter: http://twitter.com/jogep > -- > View this message in contex

Re: svn commit: r1098322 - /struts/sandbox/trunk/struts2-cdi-plugin/src/main/java/org/apache/struts2/cdi/CdiObjectFactory.java

2011-05-03 Thread Johannes Geppert
Make Struts2 independent from a specific log implementation is a nice goal. +1 Johannes Rene Gielen wrote: > > There is another possible solution / improvement we might want to think > of: Switch our logging system to slf4j facade logging, which addresses - > besides a lot of other cool things