-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Naga,
Please don't hijack threads. If you wish to ask a question, please post a new message (don't REPLY to an old one) to the list. Thanks, - -chris On 6/13/17 1:00 PM, Naga Ramesh wrote: > All, > > As of now we are using the below parameters for tomcat8 version on > production environment, please recheck and confirm, these are fine > or anything need to add or change. > > Please confirm me. > > export CATALINA_OPTS="$CATALINA_OPTS -Xms1024m" export > CATALINA_OPTS="$CATALINA_OPTS -Xmx8192m" export > CATALINA_OPTS="$CATALINA_OPTS -server" export > JAVA_OPTS="$JAVA_OPTS -Xverify:none" export > CATALINA_OPTS="$CATALINA_OPTS -XX:+TieredCompilation > -XX:+AggressiveOpts -XX:+UseG1GC -XX:SurvivorRatio=1 -XX:NewRatio=2 > -XX:MaxTenuringThreshold=15 -XX:+UseTLAB -XX:G1HeapRegionSize=32m > -XX:-UseAdaptiveSizePolicy -XX:MaxMetaspaceSize=512m > -XX:-UseSplitVerifier " > > > > -----Original Message----- From: Chris Cheshire > [mailto:yahoono...@gmail.com] Sent: Tuesday, June 13, 2017 7:58 PM > To: Tomcat Users List Subject: Re: tomcat 7, null tag attributes > > On Tue, Jun 6, 2017 at 2:29 PM, Mark Thomas <ma...@apache.org> > wrote: > >> On 31/05/17 23:31, Chris Cheshire wrote: >>> I am using tomcat 7 on CentOS 7 and I need to pass a null >>> value to tag attributes of type Long/Integer/Float, however it >>> is *always* coerced to zero. >>> >>> <%@attribute name="parentId" required="true" rtexprvalue="true" >>> type="java.lang.Long" %> >>> >>> Changing required to false does nothing. I tried setting the >>> system property org.apache.el.parser.COERCE_TO_ZERO to false >>> in tomcat.conf (-Dorg.apache.el.parser.COERCE_TO_ZERO=false >>> with my other JAVA_OPTS) >> but >>> this does nothing. >> >> As expected. That system property only affects evaluation of EL >> expressions. >> >> > But isn't <tag:thing val="${val}" /> evaluation of an EL > expression? Why is it treated differently than the evaluation of > ${val} when it is used in the same scope as it is > declared/assigned? > > For instance, this tests in a JSP : > > <core:set var="l" value="${null}" /> <core:if test="${l eq > null}"><p>l is null</p></core:if> > > will succeed. > > The moment I pass l into a tag and try the exact same evaluation > inside, it fails because it has been coerced to 0. > > >> >>> How do I pass a null Long/Float/Integer as a tag attribute and >>> have it >> kept >>> as null and not turned into an incorrect value? >> >> Use parentId="<%=null%>" rather than parentId="" >> >> Ugly, but it does the job. Scriplets aren't coerced. >> >> Mark >> > > > I can't use that because I'm not trying to pass the value null, > rather a variable that possibly equates to null. > > Also, if I have a custom bean > > public class Foo { private Long val; > > public Foo() { } public Long getVal() { return val; } public void > setVal(Long val) { this.val = val; } } > > and I pass an instance of Foo into a tag, then val stays as null. > > It seems the only solutions are to use a sentinel value that > "shouldn't" get used (cringeworthy in its own right), or to wrap > everything in a custom bean (also extremely ugly). > > I'm bewildered at why tomcat operates this way when it comes to > Numbers and Strings. Why is it insistent on coercion when null and > zero are absolutely not the same value. If this is because of > autoboxing, then isn't that a bug? A long is not a Long, and when > tag attributes must be objects and not atomic types, shouldn't > they be treated accordingly? > > > Chris > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJZQCtVAAoJEBzwKT+lPKRYqm0QAIC1onD6dKSqA8FBiD2hfSF+ fGM2hQ6j7nWQPQXT8DogrreL8Dhc2u0RU6jllMBh1mMuYOpLa51iWZz3MQpS6bx1 28CcwlHpb04TH4FBzan1a1ENxwWGFqrpzx4tltRmZy6LHi2/ElNcljMIfOcKBE53 qMSUxH8erBamRwXliYBKlTuTNzLdkhqC2tJ3eWwJ4m8vdXg2zHZ9R3crSBqUZB4y NoiOMnr4LO8NMJJp1obI27fLsBf6CnYPSPYFzjqPoXCSe+gk7E0VG47+MOEl2l/K Yu4ZrkmFqsPlwoSjrKuQVcsvERKb8vxJKn9180UweI2WVgzuxhJLUjtuXzjsat6O hyhQk623a33chKmpK9KJV1t2c5p/MzrPqBf+ZoOUHeXUWtwHA/QHqDWxvs4t/9+k UPYy0PxrNLu29UzbRDXuc0CRXq463jHyA/UpnJano35lc5sIKeJb12LijHcvxNfT 5GgGGIHFzM7NEW3TAXzwkSWofGK2lri99qYU+/IJOA8L+1QLFhnn1JEXHsgJXeRs XwP/6VQJv4gupOSk9V3LVfztmlY9H/y+Rba0pMqqj/qulo6QJ4rRhykFrX79KFXr cnCzJsBOzxyN+mz9XHwPYluQaCTRfYz1OnEeWKaOs1L9Fi+ZC0oCjiWRE2KM8IwD 4deH3ritpTrr5PDGaKyX =ZZuh -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
