[jira] [Commented] (TEXT-222) StringEscapeUtils.escapeJava() cannot restore string processed by unescapeJava()

2022-11-09 Thread clover (Jira) 


[ 
https://issues.apache.org/jira/browse/TEXT-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17631377#comment-17631377
 ] 

clover commented on TEXT-222:
-

[~aherbert] That makes a bit of sense. But you may notice that the input string 
contains two consecutive backslashes before 'u', in which case it shouldn't be 
deemed as unicode U+202e.

> StringEscapeUtils.escapeJava() cannot restore string processed by 
> unescapeJava()
> 
>
> Key: TEXT-222
> URL: https://issues.apache.org/jira/browse/TEXT-222
> Project: Commons Text
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: clover
>Priority: Minor
> Attachments: code-1.PNG, code.PNG
>
>
> When we called StringEscapeUtils.unescapeJava(orignal) and then called 
> StringEscapeUtils.escapeJava(unescaped), sometimes the orginal string cannot 
> be rest as expected.
> For example: 
>     // Commons Text 1.6
>     String unescapeJava = StringEscapeUtils.unescapeJava("u202
> {color:#ff}e{color}");
>     System.out.println("unescapeJava=" + unescapeJava);   // print 
> unescapeJava=‮
>     System.out.println("escapeJava=" + 
> StringEscapeUtils.escapeJava(unescapeJava)); // print 
> escapeJava=\u202{color:#ff}E{color}
> The lowercase 'e' in "
> u202e" is converted to uppercase 'E'.
>  
> !code.PNG!



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (IO-279) Tailer erroneously considers file as new

2022-11-09 Thread Gary D. Gregory (Jira) 


[ 
https://issues.apache.org/jira/browse/IO-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17631268#comment-17631268
 ] 

Gary D. Gregory commented on IO-279:


I think any PR in this area is likely outdated, so feel free to provide one on 
GitHub. 

> Tailer erroneously considers file as new
> 
>
> Key: IO-279
> URL: https://issues.apache.org/jira/browse/IO-279
> Project: Commons IO
>  Issue Type: Bug
>Affects Versions: 2.0.1, 2.4
>Reporter: Sergio Bossa
>Priority: Major
> Attachments: IO-279.patch, disable_resetting.patch, fix-tailer.patch, 
> modify-test-fixed.patch, modify-test.patch
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Tailer sometimes erroneously considers the tailed file as new, forcing a 
> repositioning at the start of the file: I'm still unable to reproduce this in 
> a test case, because it only happens to me with huge log files during Apache 
> Tomcat startup.
> This is the piece of code causing the problem:
> {code}
> // See if the file needs to be read again
> if (length > position) {
> // The file has more content than it did last time
> last = System.currentTimeMillis();
> position = readLines(reader);
> } else if (FileUtils.isFileNewer(file, last)) {
> /* This can happen if the file is truncated or overwritten
> * with the exact same length of information. In cases like
> * this, the file position needs to be reset
> */
> position = 0;
> reader.seek(position); // cannot be null here
> // Now we can read new lines
> last = System.currentTimeMillis();
> position = readLines(reader);
> }
> {code}
> What probably happens is that the new file content is about to be written on 
> disk, the date is already updated but content is still not flushed, so actual 
> length is untouched and there you go.
> In other words, I think there should be some better method to verify the 
> condition above, rather than relying only on dates: keeping and comparing the 
> hash code of the latest line may be a solution, but may hurt performances ... 
> other ideas?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (IO-279) Tailer erroneously considers file as new

2022-11-09 Thread Hieu Nguyen (Jira) 


[ 
https://issues.apache.org/jira/browse/IO-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17631266#comment-17631266
 ] 

Hieu Nguyen commented on IO-279:


Is there a progress on fixing this issue? I still encounter this problem.

> Tailer erroneously considers file as new
> 
>
> Key: IO-279
> URL: https://issues.apache.org/jira/browse/IO-279
> Project: Commons IO
>  Issue Type: Bug
>Affects Versions: 2.0.1, 2.4
>Reporter: Sergio Bossa
>Priority: Major
> Attachments: IO-279.patch, disable_resetting.patch, fix-tailer.patch, 
> modify-test-fixed.patch, modify-test.patch
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Tailer sometimes erroneously considers the tailed file as new, forcing a 
> repositioning at the start of the file: I'm still unable to reproduce this in 
> a test case, because it only happens to me with huge log files during Apache 
> Tomcat startup.
> This is the piece of code causing the problem:
> {code}
> // See if the file needs to be read again
> if (length > position) {
> // The file has more content than it did last time
> last = System.currentTimeMillis();
> position = readLines(reader);
> } else if (FileUtils.isFileNewer(file, last)) {
> /* This can happen if the file is truncated or overwritten
> * with the exact same length of information. In cases like
> * this, the file position needs to be reset
> */
> position = 0;
> reader.seek(position); // cannot be null here
> // Now we can read new lines
> last = System.currentTimeMillis();
> position = readLines(reader);
> }
> {code}
> What probably happens is that the new file content is about to be written on 
> disk, the date is already updated but content is still not flushed, so actual 
> length is untouched and there you go.
> In other words, I think there should be some better method to verify the 
> condition above, rather than relying only on dates: keeping and comparing the 
> hash code of the latest line may be a solution, but may hurt performances ... 
> other ideas?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[GitHub] [commons-io] garydgregory commented on pull request #74: Add new function: byteCountToDisplayRoundedSize

2022-11-09 Thread GitBox 


garydgregory commented on PR #74:
URL: https://github.com/apache/commons-io/pull/74#issuecomment-1309304322

   I do not think number-text conversion routines belong in Commons IO. Maybe 
in Commons Text?
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [commons-io] RockyMM commented on pull request #74: Add new function: byteCountToDisplayRoundedSize

2022-11-09 Thread GitBox 


RockyMM commented on PR #74:
URL: https://github.com/apache/commons-io/pull/74#issuecomment-1309240881

   @zsoltii your solution looks pretty cool. Could you resolve conflics, or are 
you OK if I take over the PR and resolve them?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Comment Edited] (JEXL-385) Support disabling fortran-style relational operators syntax

2022-11-09 Thread Dmitri Blinov (Jira) 


[ 
https://issues.apache.org/jira/browse/JEXL-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17631152#comment-17631152
 ] 

Dmitri Blinov edited comment on JEXL-385 at 11/9/22 4:55 PM:
-

[~henrib] Do you mean we can now come back to the idea of reintroducing ‘in’ as 
an alias to match operator ? Afaik ‘in’ keyword was dropped from syntax years 
ago.


was (Author: dmitri_blinov):
[~henrib] Do you mean we can now reintroduce ‘in’ as an alias to match operator 
? Afaik ‘in’ keyword was dropped from syntax years ago.

>  Support disabling fortran-style relational operators syntax
> 
>
> Key: JEXL-385
> URL: https://issues.apache.org/jira/browse/JEXL-385
> Project: Commons JEXL
>  Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> Introduce JexlFeature to disable 'eq','ne','gt','ge','le','lt' as operators, 
> treat as plain identifiers
> https://github.com/apache/commons-jexl/pull/139



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (JEXL-385) Support disabling fortran-style relational operators syntax

2022-11-09 Thread Dmitri Blinov (Jira) 


[ 
https://issues.apache.org/jira/browse/JEXL-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17631152#comment-17631152
 ] 

Dmitri Blinov commented on JEXL-385:


[~henrib] Do you mean we can now reintroduce ‘in’ as an alias to match operator 
? Afaik ‘in’ keyword was dropped from syntax years ago.

>  Support disabling fortran-style relational operators syntax
> 
>
> Key: JEXL-385
> URL: https://issues.apache.org/jira/browse/JEXL-385
> Project: Commons JEXL
>  Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> Introduce JexlFeature to disable 'eq','ne','gt','ge','le','lt' as operators, 
> treat as plain identifiers
> https://github.com/apache/commons-jexl/pull/139



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (NUMBERS-191) Stirling number of the first kind

2022-11-09 Thread Alex Herbert (Jira) 


 [ 
https://issues.apache.org/jira/browse/NUMBERS-191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Herbert resolved NUMBERS-191.
--
Resolution: Implemented

Added in commit:

2ec97e42be39f410a06a3ba9c60f89ddea65614c

> Stirling number of the first kind
> -
>
> Key: NUMBERS-191
> URL: https://issues.apache.org/jira/browse/NUMBERS-191
> Project: Commons Numbers
>  Issue Type: New Feature
>  Components: combinatorics
>Affects Versions: 1.1
>Reporter: Alex Herbert
>Assignee: Alex Herbert
>Priority: Minor
> Fix For: 1.2
>
>
> Add computation of the [Stirling number of the first 
> kind|https://mathworld.wolfram.com/StirlingNumberoftheFirstKind.html]: s(n, 
> k).
> This can be performed using the recurrence relation:
> {noformat}
> s(n + 1, k) = s(n, k - 1) - n * s(n, k)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[GitHub] [commons-numbers] asfgit merged pull request #127: Numbers-191: Compute Stirling number of the first kind

2022-11-09 Thread GitBox 


asfgit merged PR #127:
URL: https://github.com/apache/commons-numbers/pull/127


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (NUMBERS-191) Stirling number of the first kind

2022-11-09 Thread Alex Herbert (Jira) 


[ 
https://issues.apache.org/jira/browse/NUMBERS-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17631034#comment-17631034
 ] 

Alex Herbert commented on NUMBERS-191:
--

Some useful [simple s1 
identities|https://en.wikipedia.org/wiki/Stirling_numbers_of_the_first_kind#Simple_identities]
 are listed on Wikipedia:
{noformat}
s(n, n-1) = -binom(n, 2)
s(n, n-2) = (3n-1) * binom(n, 3) / 4
s(n, n-3) = -binom(n, 2) * binom(n, 4)
{noformat}
Where {{binom}} is the binomial coefficient. These are useful as these cases 
allow large n and computation using recursion requires many iterations. The 
limits of a 64-bit long are:
{noformat}
// Upper limits for n with k in [n-9, n-1]
35, 26, -5576855646887454930
44, 36, 6364808704290634598
61, 54, -8424028440309413250
95, 89, 8864929183170733205
181, 176, -8872439767850041020
495, 491, 9161199664152744351
2761, 2758, -9205676356399769400
92682, 92680, 9223080114771128550
2147483647, 2147483646, -2305843005992468481{noformat}
Care must be taken when computing {{(3n-1) * binom(n, 3) / 4}} to avoid 
intermediate overflow. This can be done by dividing an even mutiplicand by 2, 
and their product by 2, e.g.
{noformat}
long a = ...
long b = ...
return (b & 1) == 0
  ? ((b >>> 1) * a) >>> 1
  : ((a >>> 1) * b) >>> 1;{noformat}
 

> Stirling number of the first kind
> -
>
> Key: NUMBERS-191
> URL: https://issues.apache.org/jira/browse/NUMBERS-191
> Project: Commons Numbers
>  Issue Type: New Feature
>  Components: combinatorics
>Affects Versions: 1.1
>Reporter: Alex Herbert
>Assignee: Alex Herbert
>Priority: Minor
> Fix For: 1.2
>
>
> Add computation of the [Stirling number of the first 
> kind|https://mathworld.wolfram.com/StirlingNumberoftheFirstKind.html]: s(n, 
> k).
> This can be performed using the recurrence relation:
> {noformat}
> s(n + 1, k) = s(n, k - 1) - n * s(n, k)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (IMAGING-338) Sanselan returns an empty set when retrieving the image metadata

2022-11-09 Thread Gary D. Gregory (Jira) 


[ 
https://issues.apache.org/jira/browse/IMAGING-338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17630987#comment-17630987
 ] 

Gary D. Gregory commented on IMAGING-338:
-

Hi [~somasaninikhil] 

Thank you for your ticket. 

Did you check if the code is still like this in git master?

Do you have an image to reproduce this? 

The best way to move forward is to create a ticket on GitHub, this will allow 
the patch to get automatically tested in a build. 

 

 

> Sanselan returns an empty set when retrieving the image metadata
> 
>
> Key: IMAGING-338
> URL: https://issues.apache.org/jira/browse/IMAGING-338
> Project: Commons Imaging
>  Issue Type: Bug
>Affects Versions: 0.97
>Reporter: Nikhil
>Priority: Major
>
> We were using Sanselan to extract IPTC metadata. Recently there were images 
> thats causing Sanselan to return an empty set when retrieving the metadata, 
> despite the fact that there is clearly iptc metadata in the image.
>  
> The problem is seen in the following codebase
> IPTCParser.parseIPTCBlock(...), and is the second 'if' statement within the
> while loop. In particular, instead of the following:
> if (tagMarker != IPTC_RECORD_TAG_MARKER) {
>   if (verbose) {
>       System.out.println("Unexpected record tag marker in IPTC data.");
>   }
>   {*}return elements{*};
>  }
>  
> You should do the following to fix the issue:
>  
> if (tagMarker != IPTC_RECORD_TAG_MARKER) {
>   if (verbose) {
>       System.out.println("Unexpected record tag marker in IPTC data.");
>   }
>   *continue;*
> }
>  
> Credit @ 
> [https://www.mail-archive.com/sanselan-dev@incubator.apache.org/msg00430.html]
>  for the detailed notes



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (TEXT-222) StringEscapeUtils.escapeJava() cannot restore string processed by unescapeJava()

2022-11-09 Thread Alex Herbert (Jira) 


 [ 
https://issues.apache.org/jira/browse/TEXT-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Herbert resolved TEXT-222.
---
Resolution: Not A Bug

> StringEscapeUtils.escapeJava() cannot restore string processed by 
> unescapeJava()
> 
>
> Key: TEXT-222
> URL: https://issues.apache.org/jira/browse/TEXT-222
> Project: Commons Text
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: clover
>Priority: Minor
> Attachments: code-1.PNG, code.PNG
>
>
> When we called StringEscapeUtils.unescapeJava(orignal) and then called 
> StringEscapeUtils.escapeJava(unescaped), sometimes the orginal string cannot 
> be rest as expected.
> For example: 
>     // Commons Text 1.6
>     String unescapeJava = StringEscapeUtils.unescapeJava("u202
> {color:#ff}e{color}");
>     System.out.println("unescapeJava=" + unescapeJava);   // print 
> unescapeJava=‮
>     System.out.println("escapeJava=" + 
> StringEscapeUtils.escapeJava(unescapeJava)); // print 
> escapeJava=\u202{color:#ff}E{color}
> The lowercase 'e' in "
> u202e" is converted to uppercase 'E'.
>  
> !code.PNG!



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (TEXT-222) StringEscapeUtils.escapeJava() cannot restore string processed by unescapeJava()

2022-11-09 Thread Alex Herbert (Jira) 


[ 
https://issues.apache.org/jira/browse/TEXT-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17630978#comment-17630978
 ] 

Alex Herbert commented on TEXT-222:
---

The underlying unicode escaper uses upper case hex characters. So the 
round-trip translation will change the original lower case 'e' to 'E'. This 
will still refer to the same unicode entity, i.e. U+202E == U+202e. Any 
software that renders the character will handle this as identical.


> StringEscapeUtils.escapeJava() cannot restore string processed by 
> unescapeJava()
> 
>
> Key: TEXT-222
> URL: https://issues.apache.org/jira/browse/TEXT-222
> Project: Commons Text
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: clover
>Priority: Minor
> Attachments: code-1.PNG, code.PNG
>
>
> When we called StringEscapeUtils.unescapeJava(orignal) and then called 
> StringEscapeUtils.escapeJava(unescaped), sometimes the orginal string cannot 
> be rest as expected.
> For example: 
>     // Commons Text 1.6
>     String unescapeJava = StringEscapeUtils.unescapeJava("u202
> {color:#ff}e{color}");
>     System.out.println("unescapeJava=" + unescapeJava);   // print 
> unescapeJava=‮
>     System.out.println("escapeJava=" + 
> StringEscapeUtils.escapeJava(unescapeJava)); // print 
> escapeJava=\u202{color:#ff}E{color}
> The lowercase 'e' in "
> u202e" is converted to uppercase 'E'.
>  
> !code.PNG!



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (IMAGING-338) Sanselan returns an empty set when retrieving the image metadata

2022-11-09 Thread Nikhil (Jira) 
Nikhil created IMAGING-338:
--

 Summary: Sanselan returns an empty set when retrieving the image 
metadata
 Key: IMAGING-338
 URL: https://issues.apache.org/jira/browse/IMAGING-338
 Project: Commons Imaging
  Issue Type: Bug
Affects Versions: 0.97
Reporter: Nikhil


We were using Sanselan to extract IPTC metadata. Recently there were images 
thats causing Sanselan to return an empty set when retrieving the metadata, 
despite the fact that there is clearly iptc metadata in the image.

 

The problem is seen in the following codebase

IPTCParser.parseIPTCBlock(...), and is the second 'if' statement within the
while loop. In particular, instead of the following:
if (tagMarker != IPTC_RECORD_TAG_MARKER) {
  if (verbose) {
      System.out.println("Unexpected record tag marker in IPTC data.");
  }
  {*}return elements{*};
 }

 

You should do the following to fix the issue:

 

if (tagMarker != IPTC_RECORD_TAG_MARKER) {
  if (verbose) {
      System.out.println("Unexpected record tag marker in IPTC data.");
  }
  *continue;*
}

 

Credit @ 
[https://www.mail-archive.com/sanselan-dev@incubator.apache.org/msg00430.html] 
for the detailed notes



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (JEXL-385) Support disabling fortran-style relational operators syntax

2022-11-09 Thread Henri Biestro (Jira) 


[ 
https://issues.apache.org/jira/browse/JEXL-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17630899#comment-17630899
 ] 

Henri Biestro commented on JEXL-385:


Shouldn't the 'in' be part of those as well ?

>  Support disabling fortran-style relational operators syntax
> 
>
> Key: JEXL-385
> URL: https://issues.apache.org/jira/browse/JEXL-385
> Project: Commons JEXL
>  Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> Introduce JexlFeature to disable 'eq','ne','gt','ge','le','lt' as operators, 
> treat as plain identifiers
> https://github.com/apache/commons-jexl/pull/139



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (JEXL-385) Support disabling fortran-style relational operators syntax

2022-11-09 Thread Henri Biestro (Jira) 


 [ 
https://issues.apache.org/jira/browse/JEXL-385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Henri Biestro updated JEXL-385:
---
Affects Version/s: 3.2.1

>  Support disabling fortran-style relational operators syntax
> 
>
> Key: JEXL-385
> URL: https://issues.apache.org/jira/browse/JEXL-385
> Project: Commons JEXL
>  Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Major
>
> Introduce JexlFeature to disable 'eq','ne','gt','ge','le','lt' as operators, 
> treat as plain identifiers
> https://github.com/apache/commons-jexl/pull/139



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (JEXL-384) Improve control over JexlArithmetic null argument handling

2022-11-09 Thread Henri Biestro (Jira) 


 [ 
https://issues.apache.org/jira/browse/JEXL-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Henri Biestro resolved JEXL-384.

Resolution: Fixed

Added strict flag to most coercion methods in JexlArithmetic;
Use that flag according to operator strictness;
Should be closer to what was expected. :-)

Commit 
[1b9d1051|https://github.com/apache/commons-jexl/commit/1b9d10513f8963230efe39aec73b7383d386345d].

> Improve control over JexlArithmetic null argument handling
> --
>
> Key: JEXL-384
> URL: https://issues.apache.org/jira/browse/JEXL-384
> Project: Commons JEXL
>  Issue Type: Task
>Affects Versions: 3.3
>Reporter: Hussachai Puripunpinyo
>Assignee: Henri Biestro
>Priority: Major
>
> https://issues.apache.org/jira/browse/JEXL-359 
> {quote}A typical case is '+' for string and null where one would like to 
> consider null as a valid argument even if arithmetic is strict. 
> {quote}
> While the above reason is valid, the code introduced in JEXL-359 causes more 
> confusion, and the behavior is now inconsistent.
> Also, I'd like to give some counter arguments about not supporting null + 
> string in the strict mode. If we want to make null + string works even if 
> arithmetic is strict, there will be no difference between "" + "ABC" and null 
> + "ABC" because both cases yield "ABC" in both strict and non-strict mode. In 
> our code base, we set the engine to be strict, so users have to be careful 
> about null since it can give an undesirable result. In a non-strict mode, we 
> don't have a way to distinguish whether the result is the combination of null 
> or empty string and a string. Users need to explicitly check for null, but 
> there will be no enforcement
> which means nobody will do that check. That's why we prefer it to be strict 
> and a user has to check null before using or use some namespace functions 
> that we provide where null will be explicitly handled. Otherwise, the 
> exception will be thrown.
> Let me elaborate why some part of JEXL-359 causes the behavior to be 
> inconsistent.
> *Strict Mode*
> {code:java}
> var i = null;
> i + 'ABC'; // This will throw an exception.
> null + 'ABC'; // This yields 'ABC' - the same as non-strict mode.
> {code}
>  
> *Non Strict Mode*
> {code:java}
> var i = null;
> i + 'ABC'; // This yields 'ABC';
> null + 'ABC'; // This also yields 'ABC';
> {code}
>  
> You can see that the behavior of null + 'ABC' in the strict mode is not 
> consistent with the null variable.
> Also, there is a way to allow string concatenation with null using a 
> namespace function in a strict mode, and I think JEXL shouldn't make an 
> exception for this one particular case.
> I'd like to propose the PR with some regression tests that applies to only 
> null (literal) + string case.
> [https://github.com/apache/commons-jexl/pull/136]
> *Note:* I ignored one test *testNullArgs* because the feature doesn't seem to 
> be defined well. It won't work with numeric types.
> I can pass around the JexlOperator to isStrict function everywhere to address 
> that, but I'm trying to refrain from changing things too much since you may 
> have some ideas and my code might get in the way. 
> Please let me know if I can help with that, or you can merge my PR, take part 
> of it or ignore it completely :) 
> My idea about fixing *testNullArgs* properly is that all toString, toDouble, 
> toBigDecimal functions should take an additional argument which is 
> JexlOperator where a user can override for specific operator as stated in 
> testNullArgs test. If that sounds right to you, I can help creating another 
> Jira and PR to tackle this. Thank you.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (JEXL-385) Support disabling fortran-style relational operators syntax

2022-11-09 Thread Henri Biestro (Jira) 


 [ 
https://issues.apache.org/jira/browse/JEXL-385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Henri Biestro updated JEXL-385:
---
Fix Version/s: 3.3

>  Support disabling fortran-style relational operators syntax
> 
>
> Key: JEXL-385
> URL: https://issues.apache.org/jira/browse/JEXL-385
> Project: Commons JEXL
>  Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> Introduce JexlFeature to disable 'eq','ne','gt','ge','le','lt' as operators, 
> treat as plain identifiers
> https://github.com/apache/commons-jexl/pull/139



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (JEXL-385) Support disabling fortran-style relational operators syntax

2022-11-09 Thread Henri Biestro (Jira) 


 [ 
https://issues.apache.org/jira/browse/JEXL-385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Henri Biestro updated JEXL-385:
---
Assignee: Henri Biestro

>  Support disabling fortran-style relational operators syntax
> 
>
> Key: JEXL-385
> URL: https://issues.apache.org/jira/browse/JEXL-385
> Project: Commons JEXL
>  Issue Type: Improvement
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Major
>
> Introduce JexlFeature to disable 'eq','ne','gt','ge','le','lt' as operators, 
> treat as plain identifiers
> https://github.com/apache/commons-jexl/pull/139



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[GitHub] [commons-collections] XenoAmess commented on pull request #359: add function CollectionUtils.sizeIsNotEmpty

2022-11-09 Thread GitBox 


XenoAmess commented on PR #359:
URL: 
https://github.com/apache/commons-collections/pull/359#issuecomment-1308504483

   when you need a lambda or functional interface you will see it useful.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org