Re: tomcat 7, null tag attributes

[Coty Sutherland]

On Wed, Jun 14, 2017 at 2:33 PM, Christopher Schultz
 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 
>> wrote:
>>
>>> On 13/06/17 22:01, Mark Thomas wrote:
 On 13/06/17 15:27, Chris Cheshire wrote:
>>>
>>> 
>>>
> 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 

Re: tomcat 7, null tag attributes

[Christopher Schultz]

-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 
> wrote:
> 
>> On 13/06/17 22:01, Mark Thomas wrote:
>>> On 13/06/17 15:27, Chris Cheshire wrote:
>> 
>> 
>> 
 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 

Re: tomcat 7, null tag attributes

[Chris Cheshire]

On Tue, Jun 13, 2017 at 6:06 PM, Mark Thomas  wrote:

> On 13/06/17 22:01, Mark Thomas wrote:
> > On 13/06/17 15:27, Chris Cheshire wrote:
>
> 
>
> >> 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

Re: tomcat 7, null tag attributes

[Mark Thomas]

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



>> 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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: tomcat 7, null tag attributes

[Mark Thomas]

On 13/06/17 15:27, Chris Cheshire wrote:
> On Tue, Jun 6, 2017 at 2:29 PM, Mark Thomas  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  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 :
> 
> 
> l is null

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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

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


l is null

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

Re: tomcat 7, null tag attributes

[Chris Cheshire]

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


l is null

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

Re: tomcat 7, null tag attributes

[Mark Thomas]

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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: tomcat 7, null tag attributes

[Christopher Schultz]

-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 < 
> ch...@christopherschultz.net> 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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: tomcat 7, null tag attributes

[Chris Cheshire]

7.0.77 (latest version in EPEL repository)

On Thu, Jun 1, 2017 at 10:27 AM, Christopher Schultz <
ch...@christopherschultz.net> 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: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: tomcat 7, null tag attributes

[Christopher Schultz]

-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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org