tomcat 7, null tag attributes

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

tomcat 7, null tag attributes

Chris Cheshire-2
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. The value before it hits the tag is null and inside the
tag is 0. If I query the System properties it shows it as set to false, but
Tomcat is not honoring it and is still coercing nulls to zero. I understand
the spec says to do this etc but that defeats the purpose of using an
object vs atomic type in the first place and is horribly shortsighted.

Upgrading to Tomcat 8 is not a solution unfortunately as there is no RPM
for it.

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?

Chris
Reply | Threaded
Open this post in threaded view
|

Re: tomcat 7, null tag attributes

Christopher Schultz-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Chris,

On 5/31/17 6:31 PM, 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. The value before it hits
> the tag is null and inside the tag is 0. If I query the System
> properties it shows it as set to false, but Tomcat is not honoring
> it and is still coercing nulls to zero. I understand the spec says
> to do this etc but that defeats the purpose of using an object vs
> atomic type in the first place and is horribly shortsighted.
>
> Upgrading to Tomcat 8 is not a solution unfortunately as there is
> no RPM for it.
>
> 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?

What exact version of Tomcat 7 are you running?

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJZMCRCAAoJEBzwKT+lPKRYveMP/RbE4suNmhmV6Yk7+OY3iiv0
BuM6TruMa9ijRhewZJJHBE1KSjskZjNkA7Ls8+pdKUDHNExeLSbIY+k56XHT4Yvb
Y8pnIMeFcMTYIBHUjTNmyCYJm8B0CD+B4L5hJM/dLbVLASp82JFPw3lQt0mhsrua
AX7bpE1pRooU1DpiB2FeJhDhmKywWzq34o5QA8jyq2egnlPD2ip0P4TwpjDe7FzM
z2szb6lH2qI/9SWEKOxfc7FKMmtpM2kCtQO8gBY0WatGLxGlMxBAXQVGmV/70dS4
/lIyAsKfiB1HeNMhykRniKKh6miNCvVsslF4pn1wq5MLXSmYHTSV1OpFWG5yVrLe
NZVIJMiLO9NMQLEgjqNwJZfrdd6JB67LUQwulAM7r2AHzHl3LJI6IAxY5LXC41OY
jRqzNCJkriJkThrC/bFYfdb28iishM0wT/q+/JLi/3M9HEPPMKJH80oDFzFsfhum
jUfUENyVwxczUS4IAmEAPuESRZgXoXrs8h1XImH/04FJfwMxIY4Owm5+zlYH2qde
H5qxlYwUkw035dDTBr/Wi7MPh1K7fxwWnnV4qFgPGImFzRx93C5VUO3AfCm6JDsv
obutg31VzU7dxph1o1Bx4UsR/44wcK+y/eiEKgd3RBZNtpWuApJa7Yhuj1qtShJY
nHGeLzQPm33MGBvL62P9
=TQH3
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: tomcat 7, null tag attributes

Chris Cheshire-2
7.0.77 (latest version in EPEL repository)

On Thu, Jun 1, 2017 at 10:27 AM, Christopher Schultz <
[hidden email]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Chris,
>
> On 5/31/17 6:31 PM, 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. The value before it hits
> > the tag is null and inside the tag is 0. If I query the System
> > properties it shows it as set to false, but Tomcat is not honoring
> > it and is still coercing nulls to zero. I understand the spec says
> > to do this etc but that defeats the purpose of using an object vs
> > atomic type in the first place and is horribly shortsighted.
> >
> > Upgrading to Tomcat 8 is not a solution unfortunately as there is
> > no RPM for it.
> >
> > 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?
>
> What exact version of Tomcat 7 are you running?
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJZMCRCAAoJEBzwKT+lPKRYveMP/RbE4suNmhmV6Yk7+OY3iiv0
> BuM6TruMa9ijRhewZJJHBE1KSjskZjNkA7Ls8+pdKUDHNExeLSbIY+k56XHT4Yvb
> Y8pnIMeFcMTYIBHUjTNmyCYJm8B0CD+B4L5hJM/dLbVLASp82JFPw3lQt0mhsrua
> AX7bpE1pRooU1DpiB2FeJhDhmKywWzq34o5QA8jyq2egnlPD2ip0P4TwpjDe7FzM
> z2szb6lH2qI/9SWEKOxfc7FKMmtpM2kCtQO8gBY0WatGLxGlMxBAXQVGmV/70dS4
> /lIyAsKfiB1HeNMhykRniKKh6miNCvVsslF4pn1wq5MLXSmYHTSV1OpFWG5yVrLe
> NZVIJMiLO9NMQLEgjqNwJZfrdd6JB67LUQwulAM7r2AHzHl3LJI6IAxY5LXC41OY
> jRqzNCJkriJkThrC/bFYfdb28iishM0wT/q+/JLi/3M9HEPPMKJH80oDFzFsfhum
> jUfUENyVwxczUS4IAmEAPuESRZgXoXrs8h1XImH/04FJfwMxIY4Owm5+zlYH2qde
> H5qxlYwUkw035dDTBr/Wi7MPh1K7fxwWnnV4qFgPGImFzRx93C5VUO3AfCm6JDsv
> obutg31VzU7dxph1o1Bx4UsR/44wcK+y/eiEKgd3RBZNtpWuApJa7Yhuj1qtShJY
> nHGeLzQPm33MGBvL62P9
> =TQH3
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: tomcat 7, null tag attributes

Christopher Schultz-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Chris,

On 6/1/17 10:51 AM, Chris Cheshire wrote:

> 7.0.77 (latest version in EPEL repository)
>
> On Thu, Jun 1, 2017 at 10:27 AM, Christopher Schultz <
> [hidden email]> wrote:
>
> Chris,
>
> On 5/31/17 6:31 PM, 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. The value
>>>> before it hits the tag is null and inside the tag is 0. If I
>>>> query the System properties it shows it as set to false, but
>>>> Tomcat is not honoring it and is still coercing nulls to
>>>> zero. I understand the spec says to do this etc but that
>>>> defeats the purpose of using an object vs atomic type in the
>>>> first place and is horribly shortsighted.
>>>>
>>>> Upgrading to Tomcat 8 is not a solution unfortunately as
>>>> there is no RPM for it.
>>>>
>>>> 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?
>
> What exact version of Tomcat 7 are you running?

Can you produce a SSCCE[1] for this? If so, and you can reproduce it
in a clean Tomcat 7.0.78 from apache.org, please file a bug[2] and
attach your test case.

- -chris

[1] http://sscce.org/
[2] https://bz.apache.org/bugzilla/enter_bug.cgi?product=Tomcat%207
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJZMDnEAAoJEBzwKT+lPKRY0fcP/ixfCdOkWtPpb/xMUWreadoS
39Zuzii0nwsp4hsH2MkK1mZcdPGe5YElZTF1xMDtYEccUaAdDdy5DLFOnSCiXHse
2gv7nuH9cc4BQgNE6EAYTdEm/uosLwRkTn5cajNhuPdFUoTYKXwB4OGUWSMDKPUk
8nB/A7/36V2qDuu7lneR/ip/VTXLBcEA1mC+InCF7iL4VVXxl6jikc6whDcOn1m+
F5oEWzSjGn3Xu0yni5Qd8Az7GISRP7DLKHNSNoEvLgEHqdZD85R3bNY977iOujfq
3dCaDkjG/gCYdpJY+8ylRf045ZsqOn/Np8ba3WApGllXUzmbed1K+hKkKC/19D74
bGnJNRAtlpraWioWaqCb0eQn3Aml5prYD+3WKWu7bfSweLTzi1uwMV+7QL+z0rDb
9ZOmvtgW+LFlECSV71zFRTaswy1GUjR/ODTLfmLOU3PLYR+md8wgezCZW/z0C1Lt
o3Xm5RaOYc8ar6j4nwBa5LN8V4oSAWtCfzT4xZw+rDFNSbi5LSJYWoae4uuZ0jqY
fcINvOyowB4bxFNEycDi2qWjmShkRPpCljTsmDFSHUJ0yiNbSeEfHShSK/fvDEa7
AuZhS389LE2UcC/2/+0BTmoZqgMPqW1Bta413R6theLJ81sJe88MlmKb8T+JixyY
PpsbS7nvFIjDmJ3pNKcK
=67eb
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: tomcat 7, null tag attributes

markt
In reply to this post by Chris Cheshire-2
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.

> The value before it hits the tag is null and inside the
> tag is 0. If I query the System properties it shows it as set to false, but
> Tomcat is not honoring it and is still coercing nulls to zero. I understand
> the spec says to do this etc but that defeats the purpose of using an
> object vs atomic type in the first place and is horribly shortsighted>
> Upgrading to Tomcat 8 is not a solution unfortunately as there is no RPM
> for it.

I don't believe an upgrade would change the behaviour.

> 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

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: tomcat 7, null tag attributes

Chris Cheshire-2
On Tue, Jun 6, 2017 at 2:29 PM, Mark Thomas <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

RE: tomcat 7, null tag attributes

Naga Ramesh
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:[hidden email]]
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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [OT] tomcat 7, null tag attributes

Christopher Schultz-2
-----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:[hidden email]] 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 <[hidden email]>
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
-----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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: tomcat 7, null tag attributes

markt
In reply to this post by Chris Cheshire-2
On 13/06/17 15:27, Chris Cheshire wrote:

> On Tue, Jun 6, 2017 at 2:29 PM, Mark Thomas <[hidden email]> 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>

value in the set tag has the type object doesn't it? That would explain
the lack of coercion.


>
> 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?

Tomcat behaves this way because the specification says it has to. Plenty
of folks disagree strongly with the specification but Tomcat has to
implement it. COERCE_TO_ZERO is a specification breaking configuration
option to workaround this particular behaviour.

I've been digging in to this some more and it appears that
COERCE_TO_ZERO has been given a wider scope in later versions of Tomcat.
The test case you present above behaves the way you want with
COERCE_TO_ZERO set to false in 8.0.x and above. I need to dig into why
that wider scope wasn't applied to 7.0.x.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: tomcat 7, null tag attributes

markt
On 13/06/17 22:01, Mark Thomas wrote:
> On 13/06/17 15:27, Chris Cheshire wrote:

<snip/>

>> 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?
>
> Tomcat behaves this way because the specification says it has to. Plenty
> of folks disagree strongly with the specification but Tomcat has to
> implement it. COERCE_TO_ZERO is a specification breaking configuration
> option to workaround this particular behaviour.
>
> I've been digging in to this some more and it appears that
> COERCE_TO_ZERO has been given a wider scope in later versions of Tomcat.
> The test case you present above behaves the way you want with
> COERCE_TO_ZERO set to false in 8.0.x and above. I need to dig into why
> that wider scope wasn't applied to 7.0.x.

Mystery solved thanks to some svn archaeology and cross-referencing to
the relevant specs.

Tomcat 7 implements EL 2.2. EL 2.2 requires coercion of "" and null to 0
for numeric types (section 1.18.3). (As did earlier versions of the EL
spec).

Initially there weren't many complaints because the coercion rules
weren't implemented correctly in one important case (i.e. they left
these as null rather than coercing to zero). Then bug 43285 [1] got
fixed and the complaints started.

To address the complaints, Tomcat introduced the system property
org.apache.el.parser.COERCE_TO_ZERO which restored the non-specification
compliant behaviour for the one coercion case that was causing problems.
To align with the EL 2.2. specification, the default was for coercion to
zero to occur.

The level of complaints about the coercion rules was such that a
backwards compatible change was introduced in EL 3.0 to not coerce to
zero. Given Java EE's normal approach that backwards compatibility
concerns trump all others, it is a sign of the seriousness with which
the issue was taken that an incompatible change was made.

Tomcat 8, which implemented EL 3.0, switched to the new coercion rules.
To help migration of 7.0.x applications, the role of COERCE_TO_ZERO was
expanded to cover all instances of EL coercion. To align with EL 3.0,
the default was changed not to coerce to zero.

Which brings us to where we are today.

The problem you are seeing is a spec compliant coercion that is not
covered by the COERCE_TO_ZERO property in 7.0.x.

There are several possible solutions:

1. Upgrade to 8.x (8.5.x recommended in preference to 8.0.x)
   I appreciate that an RPM is not available for Tomcat 8 but 8.0.x has
   had stable releases for three years and 8.5.x for 1 year.

2. Use one of the workarounds. All pretty ugly.

3. Lobby for the extension of scope for COERCE_TO_ZERO in 7.0.x to be
   equivalent to the scope in 8.0.x. At this stage in the 7.0.x that is
   unlikely to happen. The risk of breakage for other users is too
   great.

4. Lobby for an additional configuration option for 7.0.x that extends
   the of scope for COERCE_TO_ZERO in 7.0.x to be equivalent to the
   scope in 8.0.x. This should be doable with care (there was some
   refactoring involved in the scope change that would need careful
   back-porting). This is also dependent on the CentOS distribution
   picking up the change to 7.0.x. I don't know how likely that is.
   Given the current package is based on a version over a year old I
   suspect that the changes of this being quick are very low.

None of those options look ideal. I'd probably go with 1 but my
familiarity with Tomcat is such that I usually prefer to work with an
ASF distribution rather than a downstream one anyway. YMMV.

Mark


[1] https://issues.apache.org/bugzilla/show_bug.cgi?id=43285

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: tomcat 7, null tag attributes

Chris Cheshire-2
On Tue, Jun 13, 2017 at 6:06 PM, Mark Thomas <[hidden email]> wrote:

> On 13/06/17 22:01, Mark Thomas wrote:
> > On 13/06/17 15:27, Chris Cheshire wrote:
>
> <snip/>
>
> >> 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?
> >
> > Tomcat behaves this way because the specification says it has to. Plenty
> > of folks disagree strongly with the specification but Tomcat has to
> > implement it. COERCE_TO_ZERO is a specification breaking configuration
> > option to workaround this particular behaviour.
> >
> > I've been digging in to this some more and it appears that
> > COERCE_TO_ZERO has been given a wider scope in later versions of Tomcat.
> > The test case you present above behaves the way you want with
> > COERCE_TO_ZERO set to false in 8.0.x and above. I need to dig into why
> > that wider scope wasn't applied to 7.0.x.
>
> Mystery solved thanks to some svn archaeology and cross-referencing to
> the relevant specs.
>
> Tomcat 7 implements EL 2.2. EL 2.2 requires coercion of "" and null to 0
> for numeric types (section 1.18.3). (As did earlier versions of the EL
> spec).
>
> Initially there weren't many complaints because the coercion rules
> weren't implemented correctly in one important case (i.e. they left
> these as null rather than coercing to zero). Then bug 43285 [1] got
> fixed and the complaints started.
>
> To address the complaints, Tomcat introduced the system property
> org.apache.el.parser.COERCE_TO_ZERO which restored the non-specification
> compliant behaviour for the one coercion case that was causing problems.
> To align with the EL 2.2. specification, the default was for coercion to
> zero to occur.
>
> The level of complaints about the coercion rules was such that a
> backwards compatible change was introduced in EL 3.0 to not coerce to
> zero. Given Java EE's normal approach that backwards compatibility
> concerns trump all others, it is a sign of the seriousness with which
> the issue was taken that an incompatible change was made.
>
> Tomcat 8, which implemented EL 3.0, switched to the new coercion rules.
> To help migration of 7.0.x applications, the role of COERCE_TO_ZERO was
> expanded to cover all instances of EL coercion. To align with EL 3.0,
> the default was changed not to coerce to zero.
>
> Which brings us to where we are today.
>
> The problem you are seeing is a spec compliant coercion that is not
> covered by the COERCE_TO_ZERO property in 7.0.x.
>
> There are several possible solutions:
>
> 1. Upgrade to 8.x (8.5.x recommended in preference to 8.0.x)
>    I appreciate that an RPM is not available for Tomcat 8 but 8.0.x has
>    had stable releases for three years and 8.5.x for 1 year.
>
> 2. Use one of the workarounds. All pretty ugly.
>
> 3. Lobby for the extension of scope for COERCE_TO_ZERO in 7.0.x to be
>    equivalent to the scope in 8.0.x. At this stage in the 7.0.x that is
>    unlikely to happen. The risk of breakage for other users is too
>    great.
>
> 4. Lobby for an additional configuration option for 7.0.x that extends
>    the of scope for COERCE_TO_ZERO in 7.0.x to be equivalent to the
>    scope in 8.0.x. This should be doable with care (there was some
>    refactoring involved in the scope change that would need careful
>    back-porting). This is also dependent on the CentOS distribution
>    picking up the change to 7.0.x. I don't know how likely that is.
>    Given the current package is based on a version over a year old I
>    suspect that the changes of this being quick are very low.
>
> None of those options look ideal. I'd probably go with 1 but my
> familiarity with Tomcat is such that I usually prefer to work with an
> ASF distribution rather than a downstream one anyway. YMMV.
>
> Mark
>
>
> [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=43285
>
>
>
Mark,

Thanks for the investigation into this.

You are right in that (1) is the best option. Finding time to translate the
ASF distribution into one with appropriate run scripts and configs, along
with a mechanism for in-place updating is tough. Having RPMs for that saves
me a lot of time which is why I stuck with 7.x for so long. In the meantime
I'll figure out the cleanest ugly workaround I can. I definitely won't
lobby for any non-security fixes in a product that is 2+ generations old
and is probably approaching EOL in the not too distant future.

Cheers,

Chris
Reply | Threaded
Open this post in threaded view
|

Re: tomcat 7, null tag attributes

Christopher Schultz-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Chris,

On 6/14/17 10:17 AM, Chris Cheshire wrote:

> On Tue, Jun 13, 2017 at 6:06 PM, Mark Thomas <[hidden email]>
> wrote:
>
>> On 13/06/17 22:01, Mark Thomas wrote:
>>> On 13/06/17 15:27, Chris Cheshire wrote:
>>
>> <snip/>
>>
>>>> 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?
>>>
>>> Tomcat behaves this way because the specification says it has
>>> to. Plenty of folks disagree strongly with the specification
>>> but Tomcat has to implement it. COERCE_TO_ZERO is a
>>> specification breaking configuration option to workaround this
>>> particular behaviour.
>>>
>>> I've been digging in to this some more and it appears that
>>> COERCE_TO_ZERO has been given a wider scope in later versions
>>> of Tomcat. The test case you present above behaves the way you
>>> want with COERCE_TO_ZERO set to false in 8.0.x and above. I
>>> need to dig into why that wider scope wasn't applied to 7.0.x.
>>
>> Mystery solved thanks to some svn archaeology and
>> cross-referencing to the relevant specs.
>>
>> Tomcat 7 implements EL 2.2. EL 2.2 requires coercion of "" and
>> null to 0 for numeric types (section 1.18.3). (As did earlier
>> versions of the EL spec).
>>
>> Initially there weren't many complaints because the coercion
>> rules weren't implemented correctly in one important case (i.e.
>> they left these as null rather than coercing to zero). Then bug
>> 43285 [1] got fixed and the complaints started.
>>
>> To address the complaints, Tomcat introduced the system property
>> org.apache.el.parser.COERCE_TO_ZERO which restored the
>> non-specification compliant behaviour for the one coercion case
>> that was causing problems. To align with the EL 2.2.
>> specification, the default was for coercion to zero to occur.
>>
>> The level of complaints about the coercion rules was such that a
>> backwards compatible change was introduced in EL 3.0 to not
>> coerce to zero. Given Java EE's normal approach that backwards
>> compatibility concerns trump all others, it is a sign of the
>> seriousness with which the issue was taken that an incompatible
>> change was made.
>>
>> Tomcat 8, which implemented EL 3.0, switched to the new coercion
>> rules. To help migration of 7.0.x applications, the role of
>> COERCE_TO_ZERO was expanded to cover all instances of EL
>> coercion. To align with EL 3.0, the default was changed not to
>> coerce to zero.
>>
>> Which brings us to where we are today.
>>
>> The problem you are seeing is a spec compliant coercion that is
>> not covered by the COERCE_TO_ZERO property in 7.0.x.
>>
>> There are several possible solutions:
>>
>> 1. Upgrade to 8.x (8.5.x recommended in preference to 8.0.x) I
>> appreciate that an RPM is not available for Tomcat 8 but 8.0.x
>> has had stable releases for three years and 8.5.x for 1 year.
>>
>> 2. Use one of the workarounds. All pretty ugly.
>>
>> 3. Lobby for the extension of scope for COERCE_TO_ZERO in 7.0.x
>> to be equivalent to the scope in 8.0.x. At this stage in the
>> 7.0.x that is unlikely to happen. The risk of breakage for other
>> users is too great.
>>
>> 4. Lobby for an additional configuration option for 7.0.x that
>> extends the of scope for COERCE_TO_ZERO in 7.0.x to be equivalent
>> to the scope in 8.0.x. This should be doable with care (there was
>> some refactoring involved in the scope change that would need
>> careful back-porting). This is also dependent on the CentOS
>> distribution picking up the change to 7.0.x. I don't know how
>> likely that is. Given the current package is based on a version
>> over a year old I suspect that the changes of this being quick
>> are very low.
>>
>> None of those options look ideal. I'd probably go with 1 but my
>> familiarity with Tomcat is such that I usually prefer to work
>> with an ASF distribution rather than a downstream one anyway.
>> YMMV.
>>
>> Mark
>>
>>
>> [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=43285
>>
>>
>>
> Mark,
>
> Thanks for the investigation into this.
>
> You are right in that (1) is the best option. Finding time to
> translate the ASF distribution into one with appropriate run
> scripts and configs, along with a mechanism for in-place updating
> is tough. Having RPMs for that saves me a lot of time which is why
> I stuck with 7.x for so long. In the meantime I'll figure out the
> cleanest ugly workaround I can. I definitely won't lobby for any
> non-security fixes in a product that is 2+ generations old and is
> probably approaching EOL in the not too distant future.

Coty Sutherland is the package maintainer for RedHat's Tomcat package.
Perhaps he could be persuaded to create a tomcat85 package. Try
posting a new question to the list about a Tomcat 8.5 package for
RHEL/CentOS and see if you can get his attention.

Even if it's not an "official RPM" maybe he can help build one.

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAllBgXkACgkQHPApP6U8
pFh/kQ/+OMAiqr8UV7qRw5FazoOxvLM3f7sVpJz6QMEMWiwgmy1jwI0zFuyE3ZSg
lVCFQo2EIoEiHDxxvaDPicfeROrB30W6hn3b3T0RxFICIBNxdMJKrvN5ahoW5IE0
UWPHB06eiwVI0KlTrnm3XKsGY1RyT9yaEd9JQqJo5JDqCQSpSTNROgBRZUxsMZa2
2URKzhS6h8brv2TMTiywZf71zrcKGBGEuALqLJo+jPii1Cf5TrCwtHPM8EVG6dvF
5wzCwEPUK3Z1jZKVyWh0IZbSVU751DHxRNMSUR5qBDEmOzEXthuZ2AeHSDeN5hPe
KOwSvgEHiV3nrKrEwgSManbfKuobKsdMrPSXCy1W199qBCiMcdP/VR/X4rpiD0cw
ylA+VGzicqHZC/BA1y1MFvatSbEuq6hQ3HmyMajyZDdvd/y29W6kB9POcMuwS5BM
cgQdQLUshkyk0XqE+p4xgBPLVi3LUYhX2RIbWZ2QnubQ0l4STUGEqlN2dj+sUmU1
mQ23y4ugXepXBBLBtujXuVmDhweWwww4Fe/iLzVlUNoTOLw1SxQA2re0MCZwB8Th
9JtX2o4YpNLX5PssOrIgrRAkp4q1KlCv9W4avidCd9GXexWtq5zxXevIhs/2hl4y
RLFiqw9zAy3MnEIMDR6zFb0GIfznEAoPC108OoYfz/77VCpTNXY=
=h6mP
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: tomcat 7, null tag attributes

Coty Sutherland-2
On Wed, Jun 14, 2017 at 2:33 PM, Christopher Schultz
<[hidden email]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Chris,
>
> On 6/14/17 10:17 AM, Chris Cheshire wrote:
>> On Tue, Jun 13, 2017 at 6:06 PM, Mark Thomas <[hidden email]>
>> wrote:
>>
>>> On 13/06/17 22:01, Mark Thomas wrote:
>>>> On 13/06/17 15:27, Chris Cheshire wrote:
>>>
>>> <snip/>
>>>
>>>>> 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?
>>>>
>>>> Tomcat behaves this way because the specification says it has
>>>> to. Plenty of folks disagree strongly with the specification
>>>> but Tomcat has to implement it. COERCE_TO_ZERO is a
>>>> specification breaking configuration option to workaround this
>>>> particular behaviour.
>>>>
>>>> I've been digging in to this some more and it appears that
>>>> COERCE_TO_ZERO has been given a wider scope in later versions
>>>> of Tomcat. The test case you present above behaves the way you
>>>> want with COERCE_TO_ZERO set to false in 8.0.x and above. I
>>>> need to dig into why that wider scope wasn't applied to 7.0.x.
>>>
>>> Mystery solved thanks to some svn archaeology and
>>> cross-referencing to the relevant specs.
>>>
>>> Tomcat 7 implements EL 2.2. EL 2.2 requires coercion of "" and
>>> null to 0 for numeric types (section 1.18.3). (As did earlier
>>> versions of the EL spec).
>>>
>>> Initially there weren't many complaints because the coercion
>>> rules weren't implemented correctly in one important case (i.e.
>>> they left these as null rather than coercing to zero). Then bug
>>> 43285 [1] got fixed and the complaints started.
>>>
>>> To address the complaints, Tomcat introduced the system property
>>> org.apache.el.parser.COERCE_TO_ZERO which restored the
>>> non-specification compliant behaviour for the one coercion case
>>> that was causing problems. To align with the EL 2.2.
>>> specification, the default was for coercion to zero to occur.
>>>
>>> The level of complaints about the coercion rules was such that a
>>> backwards compatible change was introduced in EL 3.0 to not
>>> coerce to zero. Given Java EE's normal approach that backwards
>>> compatibility concerns trump all others, it is a sign of the
>>> seriousness with which the issue was taken that an incompatible
>>> change was made.
>>>
>>> Tomcat 8, which implemented EL 3.0, switched to the new coercion
>>> rules. To help migration of 7.0.x applications, the role of
>>> COERCE_TO_ZERO was expanded to cover all instances of EL
>>> coercion. To align with EL 3.0, the default was changed not to
>>> coerce to zero.
>>>
>>> Which brings us to where we are today.
>>>
>>> The problem you are seeing is a spec compliant coercion that is
>>> not covered by the COERCE_TO_ZERO property in 7.0.x.
>>>
>>> There are several possible solutions:
>>>
>>> 1. Upgrade to 8.x (8.5.x recommended in preference to 8.0.x) I
>>> appreciate that an RPM is not available for Tomcat 8 but 8.0.x
>>> has had stable releases for three years and 8.5.x for 1 year.
>>>
>>> 2. Use one of the workarounds. All pretty ugly.
>>>
>>> 3. Lobby for the extension of scope for COERCE_TO_ZERO in 7.0.x
>>> to be equivalent to the scope in 8.0.x. At this stage in the
>>> 7.0.x that is unlikely to happen. The risk of breakage for other
>>> users is too great.
>>>
>>> 4. Lobby for an additional configuration option for 7.0.x that
>>> extends the of scope for COERCE_TO_ZERO in 7.0.x to be equivalent
>>> to the scope in 8.0.x. This should be doable with care (there was
>>> some refactoring involved in the scope change that would need
>>> careful back-porting). This is also dependent on the CentOS
>>> distribution picking up the change to 7.0.x. I don't know how
>>> likely that is. Given the current package is based on a version
>>> over a year old I suspect that the changes of this being quick
>>> are very low.
>>>
>>> None of those options look ideal. I'd probably go with 1 but my
>>> familiarity with Tomcat is such that I usually prefer to work
>>> with an ASF distribution rather than a downstream one anyway.
>>> YMMV.
>>>
>>> Mark
>>>
>>>
>>> [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=43285
>>>
>>>
>>>
>> Mark,
>>
>> Thanks for the investigation into this.
>>
>> You are right in that (1) is the best option. Finding time to
>> translate the ASF distribution into one with appropriate run
>> scripts and configs, along with a mechanism for in-place updating
>> is tough. Having RPMs for that saves me a lot of time which is why
>> I stuck with 7.x for so long. In the meantime I'll figure out the
>> cleanest ugly workaround I can. I definitely won't lobby for any
>> non-security fixes in a product that is 2+ generations old and is
>> probably approaching EOL in the not too distant future.
>
> Coty Sutherland is the package maintainer for RedHat's Tomcat package.

I'm glad I was reading this thread :)

> Perhaps he could be persuaded to create a tomcat85 package. Try
> posting a new question to the list about a Tomcat 8.5 package for
> RHEL/CentOS and see if you can get his attention.

Actually I already produced a COPR build of tomcat 8.5 in Fedora
(https://copr.fedorainfracloud.org/coprs/csutherl/tomcat/) for a
couple of versions of Fedora (24 and 25). I did something with the
sub-packages that I want to revert in that version (it's not a
functional thing), but it is a working build. I can rebase to the
latest and rebuild for epel-7 if you'd like to use it, just let me
know. Also note that these COPR builds are provided as-is (I do some
basic testing), but if they're useful to the community I don't mind
fixing bugs if any; I think you'd just have to contact me directly or
use some facility other than BZ.

> Even if it's not an "official RPM" maybe he can help build one.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAllBgXkACgkQHPApP6U8
> pFh/kQ/+OMAiqr8UV7qRw5FazoOxvLM3f7sVpJz6QMEMWiwgmy1jwI0zFuyE3ZSg
> lVCFQo2EIoEiHDxxvaDPicfeROrB30W6hn3b3T0RxFICIBNxdMJKrvN5ahoW5IE0
> UWPHB06eiwVI0KlTrnm3XKsGY1RyT9yaEd9JQqJo5JDqCQSpSTNROgBRZUxsMZa2
> 2URKzhS6h8brv2TMTiywZf71zrcKGBGEuALqLJo+jPii1Cf5TrCwtHPM8EVG6dvF
> 5wzCwEPUK3Z1jZKVyWh0IZbSVU751DHxRNMSUR5qBDEmOzEXthuZ2AeHSDeN5hPe
> KOwSvgEHiV3nrKrEwgSManbfKuobKsdMrPSXCy1W199qBCiMcdP/VR/X4rpiD0cw
> ylA+VGzicqHZC/BA1y1MFvatSbEuq6hQ3HmyMajyZDdvd/y29W6kB9POcMuwS5BM
> cgQdQLUshkyk0XqE+p4xgBPLVi3LUYhX2RIbWZ2QnubQ0l4STUGEqlN2dj+sUmU1
> mQ23y4ugXepXBBLBtujXuVmDhweWwww4Fe/iLzVlUNoTOLw1SxQA2re0MCZwB8Th
> 9JtX2o4YpNLX5PssOrIgrRAkp4q1KlCv9W4avidCd9GXexWtq5zxXevIhs/2hl4y
> RLFiqw9zAy3MnEIMDR6zFb0GIfznEAoPC108OoYfz/77VCpTNXY=
> =h6mP
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]