[jira] [Created] (COMPRESS-423) Add support to FB's ZStandard

2017-10-13 Thread Andre F de Miranda (JIRA) 
Andre F de Miranda created COMPRESS-423:
---

 Summary: Add support to FB's ZStandard
 Key: COMPRESS-423
 URL: https://issues.apache.org/jira/browse/COMPRESS-423
 Project: Commons Compress
  Issue Type: Improvement
Reporter: Andre F de Miranda


Give Commons Compress already supports Google's brotli it would be great if it 
also supported Facebook's ZStandard.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (IO-507) Add a ByteOrderUtils class

2017-10-13 Thread Gary Gregory (JIRA) 

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

Gary Gregory closed IO-507.
---

Closes #46.

> Add a ByteOrderUtils class
> --
>
> Key: IO-507
> URL: https://issues.apache.org/jira/browse/IO-507
> Project: Commons IO
>  Issue Type: New Feature
>  Components: Utilities
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00)
> Maven home: E:\Java\apache-maven-3.3.9\bin\..
> Java version: 1.7.0_79, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_79\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.6
>
>
> Add a ByteOrderFactory class to parse Strings and return JRE ByteOrder 
> instances.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (BCEL-296) Incorrect comment in several classes.

2017-10-13 Thread Gary Gregory (JIRA) 

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

Gary Gregory resolved BCEL-296.
---
   Resolution: Fixed
Fix Version/s: 6.2

Patch applied, thank you! This closes #16.

> Incorrect comment in several classes.
> -
>
> Key: BCEL-296
> URL: https://issues.apache.org/jira/browse/BCEL-296
> Project: Commons BCEL
>  Issue Type: Improvement
>Reporter: Mark Roberts
>Priority: Trivial
> Fix For: 6.2
>
>
> There are 70 odd classes in the generic directory that have empty 
> constructors with the following comment:
>  * Empty constructor needed for the Class.newInstance() statement in
>  * Instruction.readInstruction(). Not to be used otherwise.
> Class.newInstance() is no longer called, the empty constructors are 
> referenced directly.  Perhaps the comment should just read:
>  * Empty constructor needed Instruction.readInstruction(). 
>  * Not to be used otherwise.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (BCEL-295) Incorrect live range information in LocalVariableGen

2017-10-13 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/BCEL-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204114#comment-16204114
 ] 

ASF GitHub Bot commented on BCEL-295:
-

GitHub user markro49 opened a pull request:

https://github.com/apache/commons-bcel/pull/17

BCEL-295 fix local variable live range length; add test case



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/markro49/commons-bcel bcel295

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-bcel/pull/17.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #17


commit 9bda4c39979c184c4aa73bf99c93387f30d1
Author: Mark Roberts 
Date:   2017-10-13T20:06:11Z

fix local variable live range length; add test case




> Incorrect live range information in LocalVariableGen
> 
>
> Key: BCEL-295
> URL: https://issues.apache.org/jira/browse/BCEL-295
> Project: Commons BCEL
>  Issue Type: Bug
>Reporter: Mark Roberts
> Attachments: LocalVariableGen.diff
>
>
> (Not sure of priority - blocker for me, but probably of little consequence 
> for most clients.)
> There is a design flaw with the treatment of local variable live ranges.  In 
> the .class file these are demarcated via byte code offsets into the method's 
> instructions.  The range is from start up to, but not including, the length. 
> If the live range lasts through the end of the method, then length points to 
> the first byte 'past' the end of the method.  BCEL converts these offsets 
> into InstructionHandles and in doing so can no longer differentiate between a 
> live range that ends prior to the last instruction of the method or one that 
> includes the last instruction of the method.
> How to fix this is a bit of a problem.  The 'correct' solution would seem to 
> be to keep end as a null InstructionHandle as indicated by some of the 
> comments.  Unfortunately, LocalVariableGen does not have access to the 
> method's InstructionList and thus cannot easily convert this null pointer 
> back to the correct length for output.  We could grab the InstructionHandle 
> for start and then count the instruction bytes as we iterate to the end.
> But all this still begs the question of the fact this would be a change in 
> behavior - a client would now have to check for a null end handle before 
> dereferencing.  The proposed fix I have attached takes another approach.  It 
> sets a flag in the constructor if the initial value for end is null and then 
> lets all else proceed unchanged.  A client may test this flag to see if the 
> special case is active.  Also, the getLocalVariable method uses this flag to 
> correctly set the length on output.  
> I believe this approach would have no effect on existing code.  We would only 
> need to document the new flag for clients that might care.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (BCEL-296) Incorrect comment in several classes.

2017-10-13 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/BCEL-296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16203906#comment-16203906
 ] 

ASF GitHub Bot commented on BCEL-296:
-

GitHub user markro49 opened a pull request:

https://github.com/apache/commons-bcel/pull/16

BCEL-296: correct empty constructor comments



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/markro49/commons-bcel bcel296

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-bcel/pull/16.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #16


commit d06e3fee133eef460289455a3a82f9c3ec525306
Author: Mark Roberts 
Date:   2017-10-13T17:30:02Z

correct empty constructor comments




> Incorrect comment in several classes.
> -
>
> Key: BCEL-296
> URL: https://issues.apache.org/jira/browse/BCEL-296
> Project: Commons BCEL
>  Issue Type: Improvement
>Reporter: Mark Roberts
>Priority: Trivial
>
> There are 70 odd classes in the generic directory that have empty 
> constructors with the following comment:
>  * Empty constructor needed for the Class.newInstance() statement in
>  * Instruction.readInstruction(). Not to be used otherwise.
> Class.newInstance() is no longer called, the empty constructors are 
> referenced directly.  Perhaps the comment should just read:
>  * Empty constructor needed Instruction.readInstruction(). 
>  * Not to be used otherwise.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IO-507) Add a ByteOrderUtils class

2017-10-13 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on IO-507:
---

GitHub user britter opened a pull request:

https://github.com/apache/commons-io/pull/46

IO-507: Rename ByteOrderUtils class to ByteOrderParser and remove some

logic for parsing strings "big" and "little", after discussions on the
ML.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/britter/commons-io IO-507

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-io/pull/46.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #46


commit 7532f2c5ee58581dc6d18ab13bc0c432c6d49c96
Author: Benedikt Ritter 
Date:   2017-10-13T17:19:26Z

IO-507: Rename ByteOrderUtils class to ByteOrderParser and remove some
logic for parsing strings "big" and "little", after discussions on the
ML.




> Add a ByteOrderUtils class
> --
>
> Key: IO-507
> URL: https://issues.apache.org/jira/browse/IO-507
> Project: Commons IO
>  Issue Type: New Feature
>  Components: Utilities
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00)
> Maven home: E:\Java\apache-maven-3.3.9\bin\..
> Java version: 1.7.0_79, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_79\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.6
>
>
> Add a ByteOrderFactory class to parse Strings and return JRE ByteOrder 
> instances.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IO-526) The problem of log acquisition

2017-10-13 Thread Pascal Schumacher (JIRA) 

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

Pascal Schumacher updated IO-526:
-
Fix Version/s: (was: 2.5)

> The problem of log acquisition
> --
>
> Key: IO-526
> URL: https://issues.apache.org/jira/browse/IO-526
> Project: Commons IO
>  Issue Type: Bug
>  Components: Streams/Writers
>Affects Versions: 2.5
>Reporter: 张华
>
> Problem Description:
> Recently a problem appeared in the use of commons io 2.5 when Tailer 
> class is in the process of monitoring and reading log files: there is lost 
> logs and repeatedly collected logs for the collection of log files 
> continuously split by time .
> Scene reproduction:
>   We use log4j-1.2.17 in our project to generate the log file and split 
> it up once every hour. If the current file name is system.log, the file name 
> after splitting is system1.log.The Tailer class in commons io 2.5 monitors 
> changes to the file every 500 milliseconds.
>  1. The current system.log length is 10, position is also 10, after 
> cutting the new system.log length is 20, then this.length is greater than 
> position and position is set to 0, the old file collection then repeats (ie, 
> system1. Log). New log is missing.
>  2. The current system.log length is 10,position is 10, after cutting new 
> system.log length is 10, then this.length is equal to position, no log 
> information is read. New file logs is missing.
> I hope commons io team can solve this problem, thank you!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (IO-546) ClosedOutputStream#flush should throw

2017-10-13 Thread Pascal Schumacher (JIRA) 

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

Pascal Schumacher resolved IO-546.
--
   Resolution: Fixed
 Assignee: Pascal Schumacher
Fix Version/s: 2.6

> ClosedOutputStream#flush should throw
> -
>
> Key: IO-546
> URL: https://issues.apache.org/jira/browse/IO-546
> Project: Commons IO
>  Issue Type: Improvement
>  Components: Streams/Writers
>Reporter: Tomas Celaya
>Assignee: Pascal Schumacher
>Priority: Minor
> Fix For: 2.6
>
> Attachments: IO-546.patch
>
>
> While debugging an issue involving usage of {{CloseShieldOutputStream}} I 
> discovered that {{ClosedOutputStream#flush}} is not overridden and will 
> silently succeed. Not sure how much of a breaking change this might be but I 
> think it makes more sense for {{ClosedOutputStream#flush}} to throw. This is 
> only really meaningful in contexts where multiple streams are being chained 
> together and some of the streams before {{CloseShieldOutputStream}} perform 
> buffering, but it would make behavior more consistent for these more complex 
> use-cases.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IO-546) ClosedOutputStream#flush should throw

2017-10-13 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on IO-546:
---

Github user asfgit closed the pull request at:

https://github.com/apache/commons-io/pull/42


> ClosedOutputStream#flush should throw
> -
>
> Key: IO-546
> URL: https://issues.apache.org/jira/browse/IO-546
> Project: Commons IO
>  Issue Type: Improvement
>  Components: Streams/Writers
>Reporter: Tomas Celaya
>Priority: Minor
> Attachments: IO-546.patch
>
>
> While debugging an issue involving usage of {{CloseShieldOutputStream}} I 
> discovered that {{ClosedOutputStream#flush}} is not overridden and will 
> silently succeed. Not sure how much of a breaking change this might be but I 
> think it makes more sense for {{ClosedOutputStream#flush}} to throw. This is 
> only really meaningful in contexts where multiple streams are being chained 
> together and some of the streams before {{CloseShieldOutputStream}} perform 
> buffering, but it would make behavior more consistent for these more complex 
> use-cases.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TEXT-99) Performance Degradation for Escaping JSON

2017-10-13 Thread Pascal Schumacher (JIRA) 

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

Pascal Schumacher commented on TEXT-99:
---

Thanks for reporting!

I could not find any difference in the implementations that seemed to be the 
cause of this regression, so I have no idea how to fix it.

I sadly lack knowledge in this area, so I won't be able to implement the  
suggested `java.io.write(char cbuf[], int off, int len)` change.

Pull requests welcome!

> Performance Degradation for Escaping JSON
> -
>
> Key: TEXT-99
> URL: https://issues.apache.org/jira/browse/TEXT-99
> Project: Commons Text
>  Issue Type: Bug
>Affects Versions: 1.1
> Environment: OS X 10.11.6
> java version "1.8.0_60"
> Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
> Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)
> JProfiler 9.1 (Build 9128)
>Reporter: Tom Howard
>Priority: Minor
>  Labels: escape, json, performance
>
> There seams to be a small performance degradation on 
> StringEscapeUtils.escapeJson(String) in commons-text v1.1 compared to 
> commons-lang3 v3.5
> I have a performance test that involves (amongst other things) escaping 
> 200,052 strings. Using commons-text v1.1 this consistently takes 100ms to 
> 110ms. Using commons-lang3 v3.5 this consistently takes 92ms to 95ms.
> Also, after escaping I'm writing it to using java.io.Writer.write(String). I 
> would have assumed that StringEscapeUtils.ESCAPE_JSON.translate(CharSequence, 
> writer) would yield better performance, however in the same test, using this 
> method constantly takes approx 210ms and the parent method (which serialises 
> the entire payload to JSON) takes approx 1750ms compared to approx 1400ms 
> using StringEscapeUtils.escapeJson(String) from commons-lang3 v3.5
> I've marked the issue as minor, as it doesn't really impact me, but I thought 
> I should share my findings.
> The serialiser can be found at 
> https://github.com/mountain-pass/ryvr/blob/master/src/main/java/au/com/mountainpass/ryvr/io/RyvrSerialiser.java
>  and the performance test can be executed using `./gradlew 
> testRyvrTests_Integration_Performance_Java_H2Local`
> Also, I should mention that StringEscapeUtils.escapeJson is an order of 
> magnitude faster than the equivalents from:
> - org.json:json:20170516
> - org.unbescape:unbescape:1.1.5.RELEASE
> - com.googlecode.json-simple:1.1.1
> - net.minidev:son-smart:2.3
> They literally take over 1000ms to do what StringEscapeUtils.escapeJson() 
> does in about 100ms. If there are any other libs you would like me to test 
> against for comparison purposes, please let me know.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TEXT-70) Build failure with java 9-ea+159

2017-10-13 Thread Pascal Schumacher (JIRA) 

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

Pascal Schumacher commented on TEXT-70:
---

We have to wait for the release of the maven-site-plugin version 3.7 which will 
included https://issues.apache.org/jira/browse/MSITE-796 which is the maven 
site failure on java 9 mention above (29/8/17).

> Build failure with java 9-ea+159
> 
>
> Key: TEXT-70
> URL: https://issues.apache.org/jira/browse/TEXT-70
> Project: Commons Text
>  Issue Type: Bug
>Affects Versions: 1.0-beta-1
> Environment: $ mvn -X
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
> 2015-11-10T11:41:47-05:00)
> Maven home: /usr/local/Cellar/maven/3.3.9/libexec
> Java version: 9-ea, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.3", arch: "x86_64", family: "mac"
>Reporter: Rob Tompkins
> Fix For: 1.x
>
>
> {{mvn -X clean site}} fails with the following error trace (noting that this 
> feels more like a bug with the maven-site-plugin than with our 
> code...regardless it's worth logging):
> {code}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-site-plugin:3.6:site (default-site) on project 
> commons-text: Execution default-site of goal 
> org.apache.maven.plugins:maven-site-plugin:3.6:site failed: Unable to make 
> private java.io.File(java.lang.String,java.io.File) accessible: module 
> java.base does not "opens java.io" to unnamed module @47313e46 -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-site-plugin:3.6:site (default-site) on 
> project commons-text: Execution default-site of goal 
> org.apache.maven.plugins:maven-site-plugin:3.6:site failed: Unable to make 
> private java.io.File(java.lang.String,java.io.File) accessible: module 
> java.base does not "opens java.io" to unnamed module @47313e46
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
>   at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
>   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
>   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.base/java.lang.reflect.Method.invoke(Method.java:547)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution 
> default-site of goal org.apache.maven.plugins:maven-site-plugin:3.6:site 
> failed: Unable to make private java.io.File(java.lang.String,java.io.File) 
> accessible: module java.base does not "opens java.io" to unnamed module 
> @47313e46
>   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
>   ... 20 more
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make 
> private java.io.File(java.lang.String,java.io.File) accessible: module 
> java.base does not "opens java.io" to unnamed module @47313e46
>   at 
>

[jira] [Updated] (TEXT-100) StringEscapeUtils#UnEscapeJson doesn't recognize escape signs correctly

2017-10-13 Thread Pascal Schumacher (JIRA) 

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

Pascal Schumacher updated TEXT-100:
---
Affects Version/s: 1.1

> StringEscapeUtils#UnEscapeJson doesn't recognize escape signs correctly
> ---
>
> Key: TEXT-100
> URL: https://issues.apache.org/jira/browse/TEXT-100
> Project: Commons Text
>  Issue Type: Bug
>Affects Versions: 1.1
>Reporter: Michael Hausegger
>
> As shown in 
> org.apache.commons.text.StringEscapeUtils#testUnescapeJsonFoundBug JSON 
> escape signs do not get treated correctly.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (TEXT-74) StrSubstitutor: Ability to turn off substitution in values

2017-10-13 Thread Pascal Schumacher (JIRA) 

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

Pascal Schumacher resolved TEXT-74.
---
   Resolution: Fixed
 Assignee: Rob Tompkins
Fix Version/s: (was: 1.x)
   1.2

> StrSubstitutor: Ability to turn off substitution in values
> --
>
> Key: TEXT-74
> URL: https://issues.apache.org/jira/browse/TEXT-74
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Arend v. Reinersdorff
>Assignee: Rob Tompkins
>Priority: Minor
>  Labels: features
> Fix For: 1.2
>
>
> StrSubstitutor replaces variables in values. And currently there's no way to 
> turn this off.
> Why turn it off: I want to replace some variables in a simple template. Some 
> of the replacement values are arbitrary user input.
> At the moment I escape all dollar signs in the replacement values with "$$". 
> This is annoying. Especially as I use one template with variables as a value 
> for another variable. Here I have to escape twice.
> Here's some example code. At the moment it prints:
> {code}
> Hello Hamburg from Hamburg
> {code}
> The commented line is my suggestion for this feature. If it works, it should 
> print:
> {code}
> Hello ${city} from Hamburg
> {code}
> {code}
> // untrusted user input
> String userInputName = "${city}";
> String userInputCity = "Hamburg";
> Map valueMap = new HashMap<>();
> valueMap.put("name", userInputName);
> valueMap.put("city", userInputCity);
> String source = "Hello ${name} from ${city}";
> StrSubstitutor strSubstitutor = new StrSubstitutor(valueMap);
> // strSubstitutor.setEnableSubstitutionInValues(false);
> System.out.println(strSubstitutor.replace(source));
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)