> > > /sigh... This is one of the great debates of struts2 development. On > one side you have a camp that wants to know any time a parameter is > submitted that doesn't have a matching getter/setter on the action, on > the other side, you have a group that doesn't want a bunch of errors > in the log. IMO, I get around it by setting the logging level > differently from dev to production. The problem is a bit basic in it's > nature, the current mechanisms for parameter parsing using OGNL to set > values against the action class. OGNL will throw an exception if a > passed parameter does not match a property on the target action. > Obviously, not all situations warrant a property on the target action, > but at the same time, when you are developing your application and you > forget a getter/setter on an action, you want to know. We've tried a > few different solutions, including using the value of devMode to > decide whether or not to show the errors, but it seems that there is > no perfect solution. Honestly, I think that if someone wants to help > tackle this issue, go ahead and file a JIRA, but I can say with > confidence that bugs and patches that indiscriminately turn the > exceptions and logging off or on will not be considered. > > -Wes > > I do use a different log4j.properties file for devel vs. production which helps.
I think the best you (committers) can do is be aware of the differing needs and make the logging fine grained enough so users can turn individual messages on or off as needed. You may need several loggers in a class in order to permit fine grained tuning. The only other thing I would suggest is to reserve 'error' level reporting to only times when things go horribly wrong and recovery is not possible. Nobody wants to ever see "ERROR" show up in the logs when it isn't really an error. (E.g. in 2.1.6 https://issues.apache.org/struts/browse/WW-1714)
