For me, I get four of these messages per request, so there are alot of
messages.  Also I would rather not change the log level.

In your build you should take care of these mistakes, and update your
config accordingly.

This is what I use in my pom, where I set all the dev options to false.

                            <execution>
                                <id>update-struts</id>
                                <phase>process-resources</phase>
                                <configuration>
                                    <target name="struts-update">
                                        <echo level="info">Update
struts.properties dev runtime to false</echo>
                                        <replace
dir="${project.build.directory}/classes">
                                            <include
name="struts.properties" />
                                            <replacefilter
token="struts.devMode=true" value="struts.devMode=false" />
                                            <replacefilter
token="struts.configuration.xml.reload=true"
value="struts.configuration.xml.reload=false" />
                                            <replacefilter
token="struts.i18n.reload=true" value="struts.i18n.reload=false" />
                                        </replace>
                                        <property prefix="check"
file="${project.build.directory}/classes/struts.properties" />
                                        <echo>

struts.devMode=${check.struts.devMode}
                                        </echo>
                                    </target>
                                </configuration>
                                <goals>
                                    <goal>run</goal>
                                </goals>
                            </execution>

Cheers Greg

On Fri, 4 Jan 2019 at 20:15, J C <jcyh24...@yahoo.ca.invalid> wrote:

> Hello Greg (and everyone).
>
> Unfortunately it's a situation of trade-offs for detecting an unexpected
> change to devMode vs. when you have intentionally decided to do so.  Under
> the circumstances there may only be two ways to address the impact:
>
> 1) Suppress all log output below level Error for
> "com.opensymphony.xwork2.ognl.OgnlValueStack" using the application's log
> configuration (for loggers that support such).  If you're doing development
> with devMode true then it could be an appropriate response.
>
>   If you're using Apache Commons Logging then suppressing the warnings
> should be possible with a commons-logging configuration entry something
> like:
>   com.opensymphony.xwork2.ognl.OgnlValueStack.level=ERROR
>
>   If you're using log4j2 then using a sample configuration from the Log4J
> site (
> https://logging.apache.org/log4j/2.x/manual/customloglevels.html#DefiningLevelsInConfiguration)
> as a reference, it should be possible to suppress the unwanted log messages
> using something like:
>     <?xml version="1.0" encoding="UTF-8"?>
>     <Configuration status="WARN">
>        <Appenders>
>           ... define your console/file appenders here ...
>       </Appenders>
>       <Loggers>
>         <Logger name="com.opensymphony.xwork2.ognl.OgnlValueStack"
> level="ERROR" additivity="true">  <!-- Suppress WARN and below -->
>         <Root level="trace">
>           <AppenderRef ref="Console" level="debug" />
>            ... define the rest of your appender reference here ...
>         </Root>
>       </Loggers>
>     </Configuration>
>
> 2) Modify source com.opensymphony.xwork2.ognl.OgnlValueStack line 107 and
> change the log-level for the statement to "debug" in the Struts build.
>   Doing that would avoid the output for logging configurations that use
> INFO and above levels, but developers would still see the message when
> running at debug level.
>
> Trying 1) above with commons-logging worked for me, but unfortunately I
> don't have access to the configuration I used to double-check right now.
> For Log4J2 there's a nice general overview (
> https://www.journaldev.com/7128/log4j2-example-tutorial-configuration-levels-appenders
> ) that might be of use as well.
>
> It's probably possible with SLF4J as well, but I don't have experience
> with the syntax.
>
> Could you try to see if using a log configuration change something like
> the above works in your circumstances (to suppress unwanted warning output)
> and then let the Dev list know ?
>
> Thanks,
> James.
>
> p.s.  I didn't encounter any functional issues with the 2.5.19 test build
> during some checks earlier in the week (mostly with core functionality and
> a little tiles-plugin).
>
>
> On 2019/01/04 08:32:39, Greg Huber <g...@gmail.com> wrote:
> > My dev logs are now full of these messages!>
> >
> > 2019-01-04 08:29:33,861 WARN com.opensymphony.xwork2.ognl.OgnlValueStack>
> > OgnlValueStack:setDevMode - Setting development mode [true] affects the>
> > safety of your application!>
> >
> > We already know this.>
> >
> > Cheers Greg>
> >
> > On Sun, 30 Dec 2018 at 16:05, Lukasz Lenart <lu...@apache.org> wrote:>
> >
> > > Hi,>
> > >>
> > > Please take a time and test the bits - any help is appreciated. Please>
> > > report any problems. I'll call for a vote in a week if no problems>
> > > will be spotted.>
> > >>
> > > Staging Maven repo>
> > > https://repository.apache.org/content/groups/staging/>
> > >>
> > > Standalone artifacts>
> > > https://dist.apache.org/repos/dist/dev/struts/2.5.19/>
> > >>
> > > Release notes>
> > > https://cwiki.apache.org/confluence/display/WW/Version+Notes+2.5.19>
> > >>
> > >>
> > > Kind regards>
> > > -->
> > > Ɓukasz>
> > > + 48 606 323 122 http://www.lenart.org.pl/>
> > >>
> > > --------------------------------------------------------------------->
> > > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org>
> > > For additional commands, e-mail: dev-h...@struts.apache.org>
> > >>
> > >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
> For additional commands, e-mail: dev-h...@struts.apache.org
>
>

Reply via email to