[jira] [Commented] (VELOCITY-950) Skipping empty lines
[
https://issues.apache.org/jira/browse/VELOCITY-950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17464023#comment-17464023
]
Sergiu Dumitriu commented on VELOCITY-950:
--
Can you try something like this:
{noformat}
#if ($xxx == "true)1
#end##
#if ($yyy == "true)1
#end##
#if ($zzz == "true)1
#end##
{noformat}
> Skipping empty lines
>
>
> Key: VELOCITY-950
> URL: https://issues.apache.org/jira/browse/VELOCITY-950
> Project: Velocity
> Issue Type: Wish
> Components: Engine
>Reporter: Ivan Galkin
>Priority: Major
>
> I need to convert text from Word to PDF using "if" (or others) construction
> of Velocity. I need to get rid of empty lines.
> Example:
> In Word it looks like:
> «#if(xxx == "true)»1«#end»
> «#if(yyy == "true)»1«#end»
> «#if(zzz == "true)»1«#end»
> If yyy == false, xxx and zzz are true in PDF we will get:
> 1
>
> 1
> But I need get it without an empty line somehow:
> 1
> 1
> Is it possible to do it with such functionality?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELTOOLS-182) MathTool.max longtime bug with args (0,0)
[
https://issues.apache.org/jira/browse/VELTOOLS-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16854923#comment-16854923
]
Sergiu Dumitriu commented on VELTOOLS-182:
--
The problem is even worse since whenever negative values are used,
max(negative, negative) -> positive.
> MathTool.max longtime bug with args (0,0)
> -
>
> Key: VELTOOLS-182
> URL: https://issues.apache.org/jira/browse/VELTOOLS-182
> Project: Velocity Tools
> Issue Type: Bug
> Components: GenericTools
>Affects Versions: 2.0
>Reporter: Sanford Whiteman
>Priority: Major
>
> It appears that {{$math.max}} has had a bug since at least 2.0, or at least
> I'm at a loss as to why the observed behavior would be expected, and it
> doesn't appear to be documented.
>
> {code:java}
> $math.max(0,0) {code}
>
> returns
>
> {code:java}
> 4.9E-324{code}
>
> that is, Double.MIN_VALUE.
>
> It's easy to see why in the source. Using
> [3.0|https://apache.googlesource.com/velocity-tools/+/trunk/velocity-tools-generic/src/main/java/org/apache/velocity/tools/generic/MathTool.java#377]
> here, we see:
>
> {code:java}
> public Number max(Object... nums)
> {
> double value = Double.MIN_VALUE;
> Number[] ns = new Number[nums.length];
> for (int i=0; i {
> Number n = toNumber(nums[i]);
> if (n == null)
> {
> return null;
> }
> value = Math.max(value, n.doubleValue());
> ns[i] = n;
> }
> return matchType(value, ns);
> }
> {code}
>
> So rather than delegating to {{Java.lang.Math.max}} directly, each iter takes
> the {{Math.max}} of the current value and Double.MIN_VALUE. Ergo, if the
> arguments are 0, that's always < Double.MIN_VALUE, so the result is in turn
> Double.MIN_VALUE.
> The same goes for {{$math.min(0)}} (just one arg) but at least that could be
> considered a usage error.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELTOOLS-182) MathTool.max longtime bug with args (0,0)
[
https://issues.apache.org/jira/browse/VELTOOLS-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16854922#comment-16854922
]
Sergiu Dumitriu commented on VELTOOLS-182:
--
{{Double.NEGATIVE_INFINITY}} should be used instead of {{Double.MIN_VALUE}}.
That's a pitfall of Java, since for floating point numbers (Float, Double)
MIN_VALUE is the smallest positive number that can be represented, while for
whole numbers (Long, Integer) MIN_VALUE is the smallest negative number (-2^31,
respectively -2^63).
> MathTool.max longtime bug with args (0,0)
> -
>
> Key: VELTOOLS-182
> URL: https://issues.apache.org/jira/browse/VELTOOLS-182
> Project: Velocity Tools
> Issue Type: Bug
> Components: GenericTools
>Affects Versions: 2.0
>Reporter: Sanford Whiteman
>Priority: Major
>
> It appears that {{$math.max}} has had a bug since at least 2.0, or at least
> I'm at a loss as to why the observed behavior would be expected, and it
> doesn't appear to be documented.
>
> {code:java}
> $math.max(0,0) {code}
>
> returns
>
> {code:java}
> 4.9E-324{code}
>
> that is, Double.MIN_VALUE.
>
> It's easy to see why in the source. Using
> [3.0|https://apache.googlesource.com/velocity-tools/+/trunk/velocity-tools-generic/src/main/java/org/apache/velocity/tools/generic/MathTool.java#377]
> here, we see:
>
> {code:java}
> public Number max(Object... nums)
> {
> double value = Double.MIN_VALUE;
> Number[] ns = new Number[nums.length];
> for (int i=0; i {
> Number n = toNumber(nums[i]);
> if (n == null)
> {
> return null;
> }
> value = Math.max(value, n.doubleValue());
> ns[i] = n;
> }
> return matchType(value, ns);
> }
> {code}
>
> So rather than delegating to {{Java.lang.Math.max}} directly, each iter takes
> the {{Math.max}} of the current value and Double.MIN_VALUE. Ergo, if the
> arguments are 0, that's always < Double.MIN_VALUE, so the result is in turn
> Double.MIN_VALUE.
> The same goes for {{$math.min(0)}} (just one arg) but at least that could be
> considered a usage error.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-917) VTL Grammar Characters Configuration
[ https://issues.apache.org/jira/browse/VELOCITY-917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16853405#comment-16853405 ] Sergiu Dumitriu commented on VELOCITY-917: -- On a more general note, are you sure it is a good idea to add this configuration? Velocity is supposed to be an extremely lightweight language, and while I see the usefulness of this feature, it may complicate documentation, split the community if a major user decides to change the syntax, and reduce the cohesiveness in general. > VTL Grammar Characters Configuration > > > Key: VELOCITY-917 > URL: https://issues.apache.org/jira/browse/VELOCITY-917 > Project: Velocity > Issue Type: New Feature > Components: Engine >Affects Versions: 2.2 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Major > > Experimental feature. > The goal is to introduce new configuration parameters to be able to change > the VTL grammar. For instance: > parser.character.dollar = '~' > parser.character.hash = '@' > parser.character.arobase = '%' > parser.character.star = '?' > Requirements: > + fully B.C. > + done at runtime, without the need to recompile the parser > + null impact on performance > Implementation: > 1. Parametrize code that needs explicit references to those characters > 2. Define a ParserTokenManager interface and have the parser use this > interface rather than a concrete class > 3. Use a custom class loader to *patch* the concrete token manager .class > file, instantiate this custom token manager and initialize parsers with it > The binary patch is prepared at compilation time (there will be one patch per > JRE vendor and class file version). > Due to the limited capability of this technique, the chosen characters are > restricted to UTF-8 single bytes characters. Patches _could_ be prepared for > two-bytes or more characters, but there would be the need to have as many > parser objects as variants in one/two/... characters combinations. > Also, some characters and combinations are obviously invalid. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-917) VTL Grammar Characters Configuration
[
https://issues.apache.org/jira/browse/VELOCITY-917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16853402#comment-16853402
]
Sergiu Dumitriu commented on VELOCITY-917:
--
I think multiple settings should be defined, since it makes sense to have {{@}}
for directives, but {{//}} for comments. Note that my example list is not
exhaustive, but just a small example.
> VTL Grammar Characters Configuration
>
>
> Key: VELOCITY-917
> URL: https://issues.apache.org/jira/browse/VELOCITY-917
> Project: Velocity
> Issue Type: New Feature
> Components: Engine
>Affects Versions: 2.2
>Reporter: Claude Brisson
>Assignee: Claude Brisson
>Priority: Major
>
> Experimental feature.
> The goal is to introduce new configuration parameters to be able to change
> the VTL grammar. For instance:
> parser.character.dollar = '~'
> parser.character.hash = '@'
> parser.character.arobase = '%'
> parser.character.star = '?'
> Requirements:
> + fully B.C.
> + done at runtime, without the need to recompile the parser
> + null impact on performance
> Implementation:
> 1. Parametrize code that needs explicit references to those characters
> 2. Define a ParserTokenManager interface and have the parser use this
> interface rather than a concrete class
> 3. Use a custom class loader to *patch* the concrete token manager .class
> file, instantiate this custom token manager and initialize parsers with it
> The binary patch is prepared at compilation time (there will be one patch per
> JRE vendor and class file version).
> Due to the limited capability of this technique, the chosen characters are
> restricted to UTF-8 single bytes characters. Patches _could_ be prepared for
> two-bytes or more characters, but there would be the need to have as many
> parser objects as variants in one/two/... characters combinations.
> Also, some characters and combinations are obviously invalid.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-917) VTL Grammar Characters Configuration
[
https://issues.apache.org/jira/browse/VELOCITY-917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16853379#comment-16853379
]
Sergiu Dumitriu commented on VELOCITY-917:
--
I would prefer more semantic names for the parameters, such as
{{parser.character.variable}}, {{.directive}}, {{.silent}},
{{.formalNotationStart}} and {{.formalNotationEnd}}.
> VTL Grammar Characters Configuration
>
>
> Key: VELOCITY-917
> URL: https://issues.apache.org/jira/browse/VELOCITY-917
> Project: Velocity
> Issue Type: New Feature
> Components: Engine
>Affects Versions: 2.2
>Reporter: Claude Brisson
>Assignee: Claude Brisson
>Priority: Major
>
> Experimental feature.
> The goal is to introduce new configuration parameters to be able to change
> the VTL grammar. For instance:
> parser.character.dollar = '~'
> parser.character.hash = '@'
> parser.character.arobase = '%'
> parser.character.star = '?'
> Requirements:
> + fully B.C.
> + done at runtime, without the need to recompile the parser
> + null impact on performance
> Implementation:
> 1. Parametrize code that needs explicit references to those characters
> 2. Define a ParserTokenManager interface and have the parser use this
> interface rather than a concrete class
> 3. Use a custom class loader to *patch* the concrete token manager .class
> file, instantiate this custom token manager and initialize parsers with it
> The binary patch is prepared at compilation time (there will be one patch per
> JRE vendor and class file version).
> Due to the limited capability of this technique, the chosen characters are
> restricted to UTF-8 single bytes characters. Patches _could_ be prepared for
> two-bytes or more characters, but there would be the need to have as many
> parser objects as variants in one/two/... characters combinations.
> Also, some characters and combinations are obviously invalid.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-911) Incorrect evaluation of IF-Directive for objects with isEmpty-method
[
https://issues.apache.org/jira/browse/VELOCITY-911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808766#comment-16808766
]
Sergiu Dumitriu commented on VELOCITY-911:
--
[~luppim] I closed the issue because as it is stated, it is not valid. The
evaluation is correct, according to the intended behavior.
If you feel that the documentation needs to be further enhanced to be less
ambiguous about how being "empty" is defined, then feel free to create another
issue.
About "and other objects that have a public isEmpty() method", this applies to
all the other checks as well. In general, Velocity only calls public methods by
default, so it's not relevant to mention that the method must be public here.
And all method checks work simply by checking if such a method exists and is
accessible, the actual type of the object isn't considered. I like your wording
here: "$foo is an object with an isEmpty() method which evaluates to a true
value". How about this instead: "$foo is an object with a public isEmpty()
method which evaluates to true", and similar for all the other checks.
One option would be to put the longer technical description from the
{{directive.if.empty_check}} definition into the {{If / ElseIf / Else}}
definition in the user guide, but I feel that it is too technical for the user
guide, which is supposed to be short and simple.
> Incorrect evaluation of IF-Directive for objects with isEmpty-method
>
>
> Key: VELOCITY-911
> URL: https://issues.apache.org/jira/browse/VELOCITY-911
> Project: Velocity
> Issue Type: Bug
>Affects Versions: 2.0, 2.1
>Reporter: M. Luppi
>Assignee: Claude Brisson
>Priority: Major
> Attachments: VelocityIsEmptyBugMCVE.java, mcve-project.zip,
> template.vm
>
>
> With Velocity 2.0 the logic of evaluation for IF-Directives changed and now
> uses an extended approach to determine whether it is true. This bug report
> only refers to the case where $foo is an +object+. The documentation for 2.0
> and 2.1 state as follows:
> {quote}The variable $foo is evaluated to determine whether it is true, which
> will happen under one of those circumstances: [...]
> $foo is an object (other than a string, a number or a collection) which is
> not null
> _Source:
> [http://velocity.apache.org/engine/2.0/user-guide.html#if-elseif-else|http://velocity.apache.org/engine/2.0/user-guide.html#if-elseif-else]_
> {quote}
> After a long debugging session I have found that objects with a public
> isEmpty-method are not being handled according to the documentation cited
> above. Thereby, such objects are evaluated as false if there is an
> isEmpty-method that returns false. The correct evaluation result according to
> the documentation should be true since the object is not null and not a
> string, a number or a collection.
> It gets even more confusing when we take access modifiers into account. If
> the access of the isEmpty-method is not public, the behaviour is as it should
> be. When we make it public, however, the above explained bug occurs in
> version 2.0 as well as 2.1.
> See the attached classes and the template or the whole project of the MCVE
> (minimal, complete, and verifiable example) as ZIP.
> _The output of the test is as follows:_
> {code:java}
> null object
> ---
> [ OK ] Expected.
> non-null object with isEmpty-method (public)
>
> isEmpty evaluates to true
> [FAIL] Not expected since object is not null.
> isEmpty evaluates to false
> [ OK ] Expected.
> non-null object with isEmpty-method (package-private)
> -
> isEmpty evaluates to true
> [ OK ] Expected.
> isEmpty evaluates to false
> [ OK ] Expected.
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (VELOCITY-911) Incorrect evaluation of IF-Directive for objects with isEmpty-method
[
https://issues.apache.org/jira/browse/VELOCITY-911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergiu Dumitriu closed VELOCITY-911.
Resolution: Not A Problem
Assignee: Claude Brisson
> Incorrect evaluation of IF-Directive for objects with isEmpty-method
>
>
> Key: VELOCITY-911
> URL: https://issues.apache.org/jira/browse/VELOCITY-911
> Project: Velocity
> Issue Type: Bug
>Affects Versions: 2.0, 2.1
>Reporter: M. Luppi
>Assignee: Claude Brisson
>Priority: Major
> Attachments: VelocityIsEmptyBugMCVE.java, mcve-project.zip,
> template.vm
>
>
> With Velocity 2.0 the logic of evaluation for IF-Directives changed and now
> uses an extended approach to determine whether it is true. This bug report
> only refers to the case where $foo is an +object+. The documentation for 2.0
> and 2.1 state as follows:
> {quote}The variable $foo is evaluated to determine whether it is true, which
> will happen under one of those circumstances: [...]
> $foo is an object (other than a string, a number or a collection) which is
> not null
> _Source:
> [http://velocity.apache.org/engine/2.0/user-guide.html#if-elseif-else|http://velocity.apache.org/engine/2.0/user-guide.html#if-elseif-else]_
> {quote}
> After a long debugging session I have found that objects with a public
> isEmpty-method are not being handled according to the documentation cited
> above. Thereby, such objects are evaluated as false if there is an
> isEmpty-method that returns false. The correct evaluation result according to
> the documentation should be true since the object is not null and not a
> string, a number or a collection.
> It gets even more confusing when we take access modifiers into account. If
> the access of the isEmpty-method is not public, the behaviour is as it should
> be. When we make it public, however, the above explained bug occurs in
> version 2.0 as well as 2.1.
> See the attached classes and the template or the whole project of the MCVE
> (minimal, complete, and verifiable example) as ZIP.
> _The output of the test is as follows:_
> {code:java}
> null object
> ---
> [ OK ] Expected.
> non-null object with isEmpty-method (public)
>
> isEmpty evaluates to true
> [FAIL] Not expected since object is not null.
> isEmpty evaluates to false
> [ OK ] Expected.
> non-null object with isEmpty-method (package-private)
> -
> isEmpty evaluates to true
> [ OK ] Expected.
> isEmpty evaluates to false
> [ OK ] Expected.
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-901) hyphen in identifiers cause parse error
[
https://issues.apache.org/jira/browse/VELOCITY-901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16609306#comment-16609306
]
Sergiu Dumitriu commented on VELOCITY-901:
--
Does it work if you put curlies around the variable name?
{noformat}
#set(${test-var-w-hyphen} = "test")
test-var-w-hyphen : ${test-var-w-hyphen}
{noformat}
> hyphen in identifiers cause parse error
> ---
>
> Key: VELOCITY-901
> URL: https://issues.apache.org/jira/browse/VELOCITY-901
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 2.0
>Reporter: Mark Newton
>Assignee: Claude Brisson
>Priority: Major
> Fix For: 2.0
>
> Attachments: err, example2.vm.snip, run.sh
>
>
> Upon upgrading to Velocity 2.0 from a very old version (1.4), hyphens in
> identifiers in templates throw a ParseException.
> To verify what was happening, I did a clean install of velocity 2.0 to test
> your example code. After running the unmodified "example2.vm" successfully I
> added an identifier with a hyphen and the parse error occurred.
> Apologies if I am missing something (e.g. spec change on identifiers). If
> this is an issue that will take a while to fix, please let me know so that I
> can change out the hyphens to underbars in id's in my template sets.
> Attached are: 1) code snippet 2) parse exception msg 3) cl used to invoke
> velocity 2.0 upon example2.vm
> Best Regards
>
> 1) code snippet
> #set($test-var-w-hyphen = "test")
> test-var-w-hyphen : $test-var-w-hyphen
> --
> 2) Parse exception
> [main] ERROR org.apache.velocity.parser - example2.vm: Encountered "-" at
> line 20, column 11.
> Was expecting one of:
> "[" ...
> ...
> ...
> "=" ...
> --
> 3) Command Script
> #/bin/bash
> java -cp
> .:/home/test-a/.ant/lib/commons-lang3-3.8.jar:/home/test-a/.ant/lib/slf4j-api-1.7.25.jar:/home/test-a/.ant/lib/velocity-engine-core-2.0.jar:/home/test-a/.ant/lib/velocity-engine-scripting-2.0.jar:/home/test-a/.ant/lib/slf4j-simple-1.7.25.jar
> org.apache.velocity.example.Example2
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELTOOLS-170) Upgrade beanutils to 1.9.3 & supress access to class and Class
[
https://issues.apache.org/jira/browse/VELTOOLS-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergiu Dumitriu updated VELTOOLS-170:
-
Summary: Upgrade beanutils to 1.9.3 & supress access to class and Class
(was: Upgrade beanutils to 1.9.2 & supress access to class and Class)
> Upgrade beanutils to 1.9.3 & supress access to class and Class
> --
>
> Key: VELTOOLS-170
> URL: https://issues.apache.org/jira/browse/VELTOOLS-170
> Project: Velocity Tools
> Issue Type: Bug
> Components: Build
>Affects Versions: 2.0
>Reporter: Mark Symons
>Assignee: Claude Brisson
>Priority: Critical
> Fix For: 3.0
>
>
> Update dependency on commons-beanutils:commons-beanutils to v1.9.2 and
> mitigate CVE-2014-0114. See BEANUTILS-463 for fix info.
> Velocity Tools v2.0 currently uses bean-utils v1.7.0
> Whilst the CVE text references beanutils v1.8.0, Black Duck Hub threat
> analysis have updated affected versions to include 1.7.0.
> {quote}
> Apache Commons BeanUtils, as distributed in lib/commons-beanutils-1.8.0.jar
> in Apache Struts 1.x through 1.3.10 and in other products requiring
> commons-beanutils through 1.9.2, does not suppress the class property, which
> allows remote attackers to "manipulate" the ClassLoader and execute arbitrary
> code via the class parameter, as demonstrated by the passing of this
> parameter to the getClass method of the ActionForm object in Struts 1.
> {quote}
> h5.CVSS Version 2 Metrics:
> Access Vector: Network exploitable
> Access Complexity: Low
> Authentication: Not required to exploit
> Impact Type:
> * Allows unauthorized disclosure of information
> * Allows unauthorized modification
> * Allows disruption of service
> h3.Edit: 28th November 2016
> Sonatype Nexus IQ identifies beanutils as a threat as of v1.24 (late November
> 2016). From the vulnerability information provided (and highlighting in red
> the bit that applies to Velocity Tools):
> {quote}
> h4.Explanation
> Apache Commons BeanUtils is vulnerable to ClassLoader manipulation which can
> lead to Remote Code Execution (RCE). Access to the {{class}} and {{Class}}
> properties is not suppressed, exposing them by default. An attacker can
> construct malicious input using the {{class property}} in order to manipulate
> the {{ClassLoader}} potentially leading to arbitrary code execution.
> h4.Detection
> {color:red}If you are the calling application, you are vulnerable by running
> this component without filtering the property names {{class}} and
> {{Class}}{color}. If this is a transitive dependency, you will want to
> contact the parent project to ensure they have added a mitigating control.
> Note: If you are using the built-in implementation of
> {{SuppressPropertiesBeanIntrospector}} added in version 1.9.2 of
> {{commons-beanutils}} as your mitigation you are still vulnerable. Although
> the built-in implementation specifically suppresses the {{class}} properly,
> it does not also suppress {{Class}}.
> h4.Recommendation
> Although commons-beanutils offers a built-in implementation of
> SuppressPropertiesBeanIntrospector in version 1.9.2 that specifically
> suppresses the “class” properly, it does not also suppress “Class”. Due to
> this insufficient fix which is also not enabled by default, we recommend
> implementing your own custom mitigating control such as the one found here -
> https://community.hpe.com/t5/Security-Research/Protect-your-Struts1-applications/ba-p/6463188#.VCUfrhYvBaV.
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Reopened] (VELTOOLS-163) Apache Struts Vulnerabilities - Velocity Tool (2.0)
[ https://issues.apache.org/jira/browse/VELTOOLS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergiu Dumitriu reopened VELTOOLS-163: -- > Apache Struts Vulnerabilities - Velocity Tool (2.0) > --- > > Key: VELTOOLS-163 > URL: https://issues.apache.org/jira/browse/VELTOOLS-163 > Project: Velocity Tools > Issue Type: Bug > Components: VelocityStruts >Reporter: Pankaj Singh >Assignee: Claude Brisson >Priority: Critical > > Velocity Tools version 2.0 uses struts 1.3.8 which has associated > vulnerabilities: > Struts 1 > • CVE-2014-0114 – > http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0114 > Strut 2 > • CVE-2014-0113 – > http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0113 > • CVE-2014-0112 - > http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0112 > • CVE-2014-0094 - > http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0094 > The desired remediation goal for all affected applications is to update the > respective Apache Struts component to version 2.3.16.3. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (VELTOOLS-163) Apache Struts Vulnerabilities - Velocity Tool (2.0)
[ https://issues.apache.org/jira/browse/VELTOOLS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergiu Dumitriu closed VELTOOLS-163. Resolution: Duplicate Fix Version/s: (was: 3.0) > Apache Struts Vulnerabilities - Velocity Tool (2.0) > --- > > Key: VELTOOLS-163 > URL: https://issues.apache.org/jira/browse/VELTOOLS-163 > Project: Velocity Tools > Issue Type: Bug > Components: VelocityStruts >Reporter: Pankaj Singh >Assignee: Claude Brisson >Priority: Critical > > Velocity Tools version 2.0 uses struts 1.3.8 which has associated > vulnerabilities: > Struts 1 > • CVE-2014-0114 – > http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0114 > Strut 2 > • CVE-2014-0113 – > http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0113 > • CVE-2014-0112 - > http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0112 > • CVE-2014-0094 - > http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0094 > The desired remediation goal for all affected applications is to update the > respective Apache Struts component to version 2.3.16.3. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELTOOLS-172) Remove dependency on Apache Commons Validator
[ https://issues.apache.org/jira/browse/VELTOOLS-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergiu Dumitriu updated VELTOOLS-172: - Summary: Remove dependency on Apache Commons Validator (was: Upgrade to supported, secure version of Apache Commons Validator) > Remove dependency on Apache Commons Validator > - > > Key: VELTOOLS-172 > URL: https://issues.apache.org/jira/browse/VELTOOLS-172 > Project: Velocity Tools > Issue Type: Bug > Components: VelocityStruts >Affects Versions: 2.0, 2.0.x, 2.x >Reporter: Aaron Katz >Priority: Major > Labels: security > Fix For: 3.0 > > > *Please upgrade Apache Commons Validator to a supported, secure version*. At > this time, that appears to mean [upgrading to > 1.6|https://commons.apache.org/proper/commons-validator/changes-report.html] > h2. vulnerabilities > There is at least one publicly known high severity vulnerability > ([CVE-2014-0114|https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0114]), > allowing remote code execution, affecting all versions from 1.3.1 through > 1.4.1. > A cursory review shows that there do not appear to be publicly known > vulnerabilities in 1.5 and above. > h2. support > Apache Commons Validator 1.3.x [has not had a release since > 2006|https://commons.apache.org/proper/commons-validator/changes-report.html], > but [VelocityTools depends upon Validator > 1.3|http://velocity.apache.org/tools/2.0/dependencies.html]. I was unable to > determine which branches Validator considers to be supported, so am > suggesting upgrade to 1.6. Given the release history of one major release > followed by one minor release, then moving immediately to the next major > release, this seems like a reasonable starting target. > When vulnerabilities are discovered in unsupported software, the industry > standard response is "you need to patch to a supported version." If you get > too far behind in patch levels, then it may be very difficult to upgrade due > to broken backwards compatibility. > Furthermore, when vulnerabilities are discovered in supported software, there > is no industry standard for determining if it affects unsupported versions. > It's entirely possible that there are known vulnerabilities that affect the > apparantly-unsupported Apache Commons Validator 1.3 required by Velocity, and > nobody will know until they're breached. On the other hand, when there's a > supported major version, it's a de-facto industry standard to announce all > supported versions that are affected. This means that staying on a supported > version increases the chances of seeing vulnerability announcements for vulns > that affect Velocity. It also means that staying on an unsupported version > is considered equivalent to staying on a known vulnerable version. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELTOOLS-171) Remove Struts dependency
[ https://issues.apache.org/jira/browse/VELTOOLS-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergiu Dumitriu updated VELTOOLS-171: - Summary: Remove Struts dependency (was: Upgrade to supported, secure version of Struts) > Remove Struts dependency > > > Key: VELTOOLS-171 > URL: https://issues.apache.org/jira/browse/VELTOOLS-171 > Project: Velocity Tools > Issue Type: Bug > Components: VelocityStruts >Affects Versions: 2.0, 2.0.x, 2.x >Reporter: Aaron Katz >Assignee: Claude Brisson >Priority: Major > Labels: security > Fix For: 3.0 > > > *Please upgrade struts to a supported, secure version*. At this time, that > means upgrading to 2.3.32 or 2.5.10.1 > h2. vulnerabilities > There are publicly known high severity vulnerabilities, including remote code > execution vulns, affecting all versions of Struts 2 except the versions cited > above. > * > https://web.nvd.nist.gov/view/vuln/search-results?adv_search=true=on_vendor=cpe%3a%2f%3aapache_product=cpe%3a%2f%3a%3astruts_version=3_id= > * (details not yet in NVD) > https://cwiki.apache.org/confluence/display/WW/S2-045 > h2. support > Apache struts 1 [reached end of life in the year > 2000|https://struts.apache.org/struts1eol-announcement.html], but > [VelocityTools depends upon Struts > 1.3.8|http://velocity.apache.org/tools/2.0/dependencies.html]. > When vulnerabilities are discovered in unsupported software, the industry > standard response is "you need to patch to a supported version." If you get > too far behind in patch levels, then it may be very difficult to upgrade due > to broken backwards compatibility. > Furthermore, when vulnerabilities are discovered in supported software, there > is no industry standard for determining if it affects unsupported versions. > It's entirely possible that there are known vulnerabilities that affect the > unsupported Struts 1.3.8 required by Velocity, and nobody will know until > they're breached. On the other hand, when there's a supported major version, > it's a de-facto industry standard to announce all supported versions that are > affected. This means that staying on a supported version increases the > chances of seeing vulnerability announcements for vulns that affect Velocity. > It also means that staying on an unsupported version is considered > equivalent to staying on a known vulnerable version. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-867) Website does not link to issue tracking system
[ https://issues.apache.org/jira/browse/VELOCITY-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15487102#comment-15487102 ] Sergiu Dumitriu commented on VELOCITY-867: -- Or to the main project, the engine. Or to [all projects in the Velocity category|https://issues.apache.org/jira/secure/BrowseProjects.jspa#10200]. > Website does not link to issue tracking system > -- > > Key: VELOCITY-867 > URL: https://issues.apache.org/jira/browse/VELOCITY-867 > Project: Velocity > Issue Type: Bug > Environment: http://velocity.apache.org/issue-tracking.html >Reporter: Sebb >Assignee: Claude Brisson > Fix For: 1.7.x, 2.x > > > The website does not mention the issue tracking system -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (VELOCITY-877) Access to critical fields/methods allows execution of arbitrary code ('Template Injection')
[
https://issues.apache.org/jira/browse/VELOCITY-877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergiu Dumitriu closed VELOCITY-877.
Resolution: Not A Problem
Assignee: Sergiu Dumitriu
Yes, this is by design, **if** you are using the default uberspector. Velocity
also comes with a secure uberspector, which is designed to prevent exactly this
kind of security issues.
{noformat}
runtime.introspector.uberspect =
org.apache.velocity.util.introspection.SecureUberspector
{noformat}
> Access to critical fields/methods allows execution of arbitrary code
> ('Template Injection')
> ---
>
> Key: VELOCITY-877
> URL: https://issues.apache.org/jira/browse/VELOCITY-877
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 1.7
>Reporter: Markus Wulftange
>Assignee: Sergiu Dumitriu
>Priority: Critical
> Labels: security
>
> It is possible to reference certain fields/methods, which eventually allow
> the execution of arbitrary methods.
> For example, by utilizing the '{{class}}' field or '{{getClass()}}' method of
> any variable, it is possible to get the variable's class object. This can be
> extended to get arbitrary class objects and execute arbitrary methods.
> For example, the following statement results in the execution of the
> '{{xterm}}':
> {code}
> $var.class.class.forName('java.lang.Runtime').getRuntime().exec('xterm').waitFor()
> {code}
> As a standalone:
> {code:java}
> import org.apache.velocity.VelocityContext;
> import org.apache.velocity.app.Velocity;
> import org.apache.velocity.context.Context;
> public class VelocityTest {
> public static void main(String[] args) {
> Context context = new VelocityContext();
> context.put("var", "foo");
> String instring =
> "$var.class.class.forName('java.lang.Runtime').getRuntime().exec('xterm').waitFor()";
> Velocity.evaluate(context, null, "templateName", instring);
> }
> }
> {code}
> This issue has already been made public in the past by James Kettle in August
> 2015 (see
> http://blog.portswigger.net/2015/08/server-side-template-injection.html#Velocity)
> and via CVE-2015-5603 (see
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5603) and possibly
> others.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-826) OutOfMemoryError using #parse and resource.loader.cache off
[ https://issues.apache.org/jira/browse/VELOCITY-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergiu Dumitriu updated VELOCITY-826: - Fix Version/s: (was: 2.x) > OutOfMemoryError using #parse and resource.loader.cache off > --- > > Key: VELOCITY-826 > URL: https://issues.apache.org/jira/browse/VELOCITY-826 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 1.7 > Environment: Windows, Java 1.6, low heap (-Xmx10m) >Reporter: Marnix Bindels >Assignee: Claude Brisson >Priority: Minor > Attachments: VelocityOutOfMemoryTest.java, heap.png, script_1.vm, > script_2.vm, script_3.vm > > > I was testing a template collection that uses #parse inside some #foreach, > which worked all fine inside eclipse but crashed when used in the stand-alone > application running with a low heap setting with an OutOfMemoryError: Java > heap space. I was able overcome this by setting the > .resource.loader.cache to "true". > Still I wanted to let you know about this as it may be an indicator of a > resource management issue of sorts anyway. The parsed resource is constant, > with caching off it gets reported as found and loaded by the ResourceManager > for each iteration (some 6000 times in the example). I understand that > without caching it gets loaded every time, but why do the previously loaded > instances keep occupying memory? > When published on teh dev mailing list, it was suggested to file this bug > report. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-799) Optionally add context to itself
[
https://issues.apache.org/jira/browse/VELOCITY-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15383115#comment-15383115
]
Sergiu Dumitriu edited comment on VELOCITY-799 at 7/18/16 9:32 PM:
---
I'm not sure, but I think jsr233 (or whatever the name of the java scripting
API) actually requires that the context is available under the {{context}}
binding/variable.
was (Author: sdumitriu):
I'm not sure, but I think jsr233 (or whatever the bame of the java scripting
API) actually requires that the context is available under the {{context}}
binding/variable.
> Optionally add context to itself
>
>
> Key: VELOCITY-799
> URL: https://issues.apache.org/jira/browse/VELOCITY-799
> Project: Velocity
> Issue Type: Improvement
>Reporter: Sebb
>Assignee: Claude Brisson
> Fix For: 2.x
>
>
> For debugging scripts, it would sometimes be useful to have access to the
> context within a VM script.
> For example, one could then print out all the variables that are defined in
> the context.
> The suggestion is to enable this via a properties file or a system property.
> If the property is defined, its value would be used as the name of the
> variable holding the context.
> e.g. -Dvelocity.context.variable=ctx
> Obviously feel free to choose a better property name.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-799) Optionally add context to itself
[
https://issues.apache.org/jira/browse/VELOCITY-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15383115#comment-15383115
]
Sergiu Dumitriu commented on VELOCITY-799:
--
I'm not sure, but I think jsr233 (or whatever the bame of the java scripting
API) actually requires that the context is available under the {{context}}
binding/variable.
> Optionally add context to itself
>
>
> Key: VELOCITY-799
> URL: https://issues.apache.org/jira/browse/VELOCITY-799
> Project: Velocity
> Issue Type: Improvement
>Reporter: Sebb
>Assignee: Claude Brisson
> Fix For: 2.x
>
>
> For debugging scripts, it would sometimes be useful to have access to the
> context within a VM script.
> For example, one could then print out all the variables that are defined in
> the context.
> The suggestion is to enable this via a properties file or a system property.
> If the property is defined, its value would be used as the name of the
> variable holding the context.
> e.g. -Dvelocity.context.variable=ctx
> Obviously feel free to choose a better property name.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-806) Can't access map values when get(Object key) is overriden
[
https://issues.apache.org/jira/browse/VELOCITY-806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergiu Dumitriu updated VELOCITY-806:
-
Fix Version/s: (was: 2.x)
> Can't access map values when get(Object key) is overriden
> -
>
> Key: VELOCITY-806
> URL: https://issues.apache.org/jira/browse/VELOCITY-806
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 1.7
>Reporter: Mateusz Matela
>Assignee: Claude Brisson
>Priority: Minor
>
> I try to add a java.util.Map instance to Velocity context and access its
> values from a template, for example: ${map.get("someKey")}
> It doesn't work if use my own implementation of Map.get(Object key). It
> doesn't matter whether I implement Map from scratch, or subclass HashMap and
> override the get(Object key) metho. The get method is never called and the
> engine output is: ${map.get("someKey")}.
> It does work if I use my own subclass of HashMap without overriding the
> get(Object key) method.
> It does work if I use my own implementation of Map with the get(String key)
> method added: the get(String key) is called instead of get(Object key).
> It does work if I use my class that doesn't implement Map, but has a
> get(Object key) method.
> More discussion of this on Velocity-User mailing list:
> http://old.nabble.com/Can%27t-acces-map-values-when-get%28%29-is-overriden-td31955214.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-745) Modify ClassMap.java to use getMethods() rather than get getDeclaredMethods()
[ https://issues.apache.org/jira/browse/VELOCITY-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15379601#comment-15379601 ] Sergiu Dumitriu commented on VELOCITY-745: -- I wonder what happens with Java8 and interface default methods... > Modify ClassMap.java to use getMethods() rather than get getDeclaredMethods() > - > > Key: VELOCITY-745 > URL: https://issues.apache.org/jira/browse/VELOCITY-745 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 1.6.2 > Environment: All >Reporter: Steve O'Hara >Priority: Minor > > The code that recurses up the super classes to find all public methods using > getDeclaredMethods() is now redundant and can be replaced with a single call > to getMethods() - this intrinsically provides all inherited public methods. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-553) Posibility to configure ReportInvalidReferences to don't report report variables,properties and method which exist, but only have null value
[ https://issues.apache.org/jira/browse/VELOCITY-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15376174#comment-15376174 ] Sergiu Dumitriu commented on VELOCITY-553: -- What about the $!silent notation? Will all of them be silently ignored? > Posibility to configure ReportInvalidReferences to don't report report > variables,properties and method which exist, but only have null value > > > Key: VELOCITY-553 > URL: https://issues.apache.org/jira/browse/VELOCITY-553 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 1.5 > Environment: any >Reporter: Tomáš Procházka > Fix For: 2.x > > Attachments: InvalidEventHandlerTestCase.java.patch > > > ReportInvalidReferences has very big imperfection, it report by default all > variables, properties and method which has null value. > This may cause many problems for developer. > I for example need only validate template without any data, only check which > contain right variables, properties or method (which exist), it's value is > not important for me. > I tried use my own ReferenceInsertionEventHandler for replace null value with > "" (empty String) but Velocity call InvalidReference handler before > ReferenceInsertionEventHandler. > I suggest configuration options for this (repor or doesn't report null value) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-874) Subtraction doesn't work as expected
[
https://issues.apache.org/jira/browse/VELOCITY-874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15275916#comment-15275916
]
Sergiu Dumitriu commented on VELOCITY-874:
--
Probably because {{-}} is a valid variable name character:
{noformat}
#set ($some-var = 42)
$some-var -> 42
{noformat}
> Subtraction doesn't work as expected
>
>
> Key: VELOCITY-874
> URL: https://issues.apache.org/jira/browse/VELOCITY-874
> Project: Velocity
> Issue Type: Bug
> Environment: VTL in user macro in Atlassian Confluence 5.9.4
>Reporter: Alexander Rosenberg
>
> This works as expected:
> {noformat}
> ## @noparams
> #set ($n = 5)
> #set ($m = $n+1)
> $m
> {noformat}
> Output: {{6}}
> However, subtraction doesn't work:
> {noformat}
> ## @noparams
> #set ($n = 5)
> #set ($m = $n-1)
> $m
> {noformat}
> Output: {{$m}}
> From [SO Q
> #15448108|http://stackoverflow.com/questions/15448108/subtraction-is-not-working-with-velocity-template],
> it appears that this behavior is due to the parser treating the
> hyphen/dash/minus-sign as part of the identifier, but certainly an exception
> should be made for when the "identifier" ends with only digits and/or hyphens.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-869) Vulnerability in dependency: commons-collections:3.2.1
[
https://issues.apache.org/jira/browse/VELOCITY-869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15245550#comment-15245550
]
Sergiu Dumitriu commented on VELOCITY-869:
--
Depends on how your build works. If you're using Maven, you can either add a
{{}} on commons-collections 3.2.2 (no need to exclude 3.2.1, Maven
automatically selects just one version for a library), or add a
[{{}}|https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management]
on 3.2.2, which will make Maven automatically upgrade the transitive
dependency, without declaring a dependency that's not actually used by your
code.
> Vulnerability in dependency: commons-collections:3.2.1
> --
>
> Key: VELOCITY-869
> URL: https://issues.apache.org/jira/browse/VELOCITY-869
> Project: Velocity
> Issue Type: Bug
> Components: Build
>Affects Versions: 1.7
>Reporter: Ryan Blue
>Assignee: Sergiu Dumitriu
> Fix For: 2.x, 1.x
>
>
> There is an arbitrary remote code execution bug in commons-collections,
> tracked by COLLECTIONS-580. Updating to the version where this bug is fixed,
> 3.2.2, will help downstream libraries (like avro-ipc) from pulling in the bad
> version. Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-869) Vulnerability in dependency: commons-collections:3.2.1
[ https://issues.apache.org/jira/browse/VELOCITY-869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15242894#comment-15242894 ] Sergiu Dumitriu commented on VELOCITY-869: -- There are no real code changes, so all you have to do is replace one jar with the other in your project. > Vulnerability in dependency: commons-collections:3.2.1 > -- > > Key: VELOCITY-869 > URL: https://issues.apache.org/jira/browse/VELOCITY-869 > Project: Velocity > Issue Type: Bug > Components: Build >Affects Versions: 1.7 >Reporter: Ryan Blue >Assignee: Sergiu Dumitriu > Fix For: 2.x, 1.x > > > There is an arbitrary remote code execution bug in commons-collections, > tracked by COLLECTIONS-580. Updating to the version where this bug is fixed, > 3.2.2, will help downstream libraries (like avro-ipc) from pulling in the bad > version. Thanks! -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Assigned] (VELOCITY-870) Exception displayed when trying to loop over an Iterable private class
[
https://issues.apache.org/jira/browse/VELOCITY-870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergiu Dumitriu reassigned VELOCITY-870:
Assignee: Sergiu Dumitriu
> Exception displayed when trying to loop over an Iterable private class
> --
>
> Key: VELOCITY-870
> URL: https://issues.apache.org/jira/browse/VELOCITY-870
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 1.7
>Reporter: Vincent Massol
>Assignee: Sergiu Dumitriu
>
> Specifically I got the following failure (see also
> https://java.net/jira/browse/TRUEVFS-158):
> {noformat}
> ...
> Caused by: java.lang.IllegalAccessException: Class
> org.apache.velocity.util.introspection.UberspectImpl can not access a member
> of class net.java.truevfs.access.TFileSystem$Stream with modifiers "public"
> at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:109)
> at
> java.lang.reflect.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:261)
> at java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:253)
> at java.lang.reflect.Method.invoke(Method.java:599)
> at
> org.apache.velocity.util.introspection.UberspectImpl.getIterator(UberspectImpl.java:158)
> {noformat}
> The problem as I understand it is that TrueVFS returns a private class and
> Velocity shouldn't try to call iterator() on it since it's private.
> Right now the UberspectImpl code does this:
> {code}
> Class type = obj.getClass();
> try
> {
> Method iter = type.getMethod("iterator", null);
> Class returns = iter.getReturnType();
> if (Iterator.class.isAssignableFrom(returns))
> {
> try
> {
> return (Iterator)iter.invoke(obj, null);
> ...
> {code}
> Instead, it could continue to do this but if the method is private then it
> could also fallback to something like the following:
> {code}
> Class type = Iterable.class;
> if (obj instanceof Iterable) {
> Method iter = type.getMethod("iterator", null);
> return (Iterator) iter.invoke(obj, null);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Created] (VELOCITY-871) #foreach should work over any Iterable class
Sergiu Dumitriu created VELOCITY-871:
Summary: #foreach should work over any Iterable class
Key: VELOCITY-871
URL: https://issues.apache.org/jira/browse/VELOCITY-871
Project: Velocity
Issue Type: Improvement
Components: Engine
Affects Versions: 1.7
Reporter: Sergiu Dumitriu
Assignee: Sergiu Dumitriu
Fix For: 1.7.1
The current code was written before Java 1.5 added the {{Iterable}} class, so
it tries to partially add support for it by invoking the {{iterator}} method
through reflection, but this doesn't work for inaccessible classes (see
VELOCITY-870). Since 1.7 requires Java 1.5, we can check if the target object
implements {{Iterable}} directly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-870) Exception displayed when trying to loop over an Iterable private class
[
https://issues.apache.org/jira/browse/VELOCITY-870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergiu Dumitriu updated VELOCITY-870:
-
Summary: Exception displayed when trying to loop over an Iterable private
class (was: UberspectImpl should check class visibility before calling
iterator())
> Exception displayed when trying to loop over an Iterable private class
> --
>
> Key: VELOCITY-870
> URL: https://issues.apache.org/jira/browse/VELOCITY-870
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 1.7
>Reporter: Vincent Massol
>
> Specifically I got the following failure (see also
> https://java.net/jira/browse/TRUEVFS-158):
> {noformat}
> ...
> Caused by: java.lang.IllegalAccessException: Class
> org.apache.velocity.util.introspection.UberspectImpl can not access a member
> of class net.java.truevfs.access.TFileSystem$Stream with modifiers "public"
> at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:109)
> at
> java.lang.reflect.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:261)
> at java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:253)
> at java.lang.reflect.Method.invoke(Method.java:599)
> at
> org.apache.velocity.util.introspection.UberspectImpl.getIterator(UberspectImpl.java:158)
> {noformat}
> The problem as I understand it is that TrueVFS returns a private class and
> Velocity shouldn't try to call iterator() on it since it's private.
> Right now the UberspectImpl code does this:
> {code}
> Class type = obj.getClass();
> try
> {
> Method iter = type.getMethod("iterator", null);
> Class returns = iter.getReturnType();
> if (Iterator.class.isAssignableFrom(returns))
> {
> try
> {
> return (Iterator)iter.invoke(obj, null);
> ...
> {code}
> Instead, it could continue to do this but if the method is private then it
> could also fallback to something like the following:
> {code}
> Class type = Iterable.class;
> if (obj instanceof Iterable) {
> Method iter = type.getMethod("iterator", null);
> return (Iterator) iter.invoke(obj, null);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (VELOCITY-871) #foreach should work over any Iterable class
[
https://issues.apache.org/jira/browse/VELOCITY-871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergiu Dumitriu closed VELOCITY-871.
Resolution: Fixed
Fix Version/s: 1.x
2.x
> #foreach should work over any Iterable class
>
>
> Key: VELOCITY-871
> URL: https://issues.apache.org/jira/browse/VELOCITY-871
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
>Affects Versions: 1.7
>Reporter: Sergiu Dumitriu
>Assignee: Sergiu Dumitriu
> Fix For: 2.x, 1.7.1, 1.x
>
>
> The current code was written before Java 1.5 added the {{Iterable}} class, so
> it tries to partially add support for it by invoking the {{iterator}} method
> through reflection, but this doesn't work for inaccessible classes (see
> VELOCITY-870). Since 1.7 requires Java 1.5, we can check if the target object
> implements {{Iterable}} directly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (VELOCITY-870) Exception displayed when trying to loop over an Iterable private class
[
https://issues.apache.org/jira/browse/VELOCITY-870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergiu Dumitriu closed VELOCITY-870.
Resolution: Fixed
Fix Version/s: 1.x
2.x
1.7.x
> Exception displayed when trying to loop over an Iterable private class
> --
>
> Key: VELOCITY-870
> URL: https://issues.apache.org/jira/browse/VELOCITY-870
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 1.7
>Reporter: Vincent Massol
>Assignee: Sergiu Dumitriu
> Fix For: 1.7.x, 2.x, 1.x
>
>
> Specifically I got the following failure (see also
> https://java.net/jira/browse/TRUEVFS-158):
> {noformat}
> ...
> Caused by: java.lang.IllegalAccessException: Class
> org.apache.velocity.util.introspection.UberspectImpl can not access a member
> of class net.java.truevfs.access.TFileSystem$Stream with modifiers "public"
> at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:109)
> at
> java.lang.reflect.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:261)
> at java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:253)
> at java.lang.reflect.Method.invoke(Method.java:599)
> at
> org.apache.velocity.util.introspection.UberspectImpl.getIterator(UberspectImpl.java:158)
> {noformat}
> The problem as I understand it is that TrueVFS returns a private class and
> Velocity shouldn't try to call iterator() on it since it's private.
> Right now the UberspectImpl code does this:
> {code}
> Class type = obj.getClass();
> try
> {
> Method iter = type.getMethod("iterator", null);
> Class returns = iter.getReturnType();
> if (Iterator.class.isAssignableFrom(returns))
> {
> try
> {
> return (Iterator)iter.invoke(obj, null);
> ...
> {code}
> Instead, it could continue to do this but if the method is private then it
> could also fallback to something like the following:
> {code}
> Class type = Iterable.class;
> if (obj instanceof Iterable) {
> Method iter = type.getMethod("iterator", null);
> return (Iterator) iter.invoke(obj, null);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Resolved] (VELOCITY-869) Vulnerability in dependency: commons-collections:3.2.1
[ https://issues.apache.org/jira/browse/VELOCITY-869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergiu Dumitriu resolved VELOCITY-869. -- Resolution: Fixed Assignee: Sergiu Dumitriu Fix Version/s: 1.x 2.x Committed, thanks for reporting it. > Vulnerability in dependency: commons-collections:3.2.1 > -- > > Key: VELOCITY-869 > URL: https://issues.apache.org/jira/browse/VELOCITY-869 > Project: Velocity > Issue Type: Bug > Components: Build >Affects Versions: 1.7 >Reporter: Ryan Blue >Assignee: Sergiu Dumitriu > Fix For: 2.x, 1.x > > > There is an arbitrary remote code execution bug in commons-collections, > tracked by COLLECTIONS-580. Updating to the version where this bug is fixed, > 3.2.2, will help downstream libraries (like avro-ipc) from pulling in the bad > version. Thanks! -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELTOOLS-167) Dealing with missing keys in resource bundle
[
https://issues.apache.org/jira/browse/VELTOOLS-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14613311#comment-14613311
]
Sergiu Dumitriu commented on VELTOOLS-167:
--
That behavior should be configurable.
Dealing with missing keys in resource bundle
Key: VELTOOLS-167
URL: https://issues.apache.org/jira/browse/VELTOOLS-167
Project: Velocity Tools
Issue Type: Bug
Components: GenericTools
Affects Versions: 2.0
Reporter: Mohan Palisetti
Priority: Minor
No exception is thrown when doing a template merge with a non-existent key
from the resource bundle.
eg. if the template has ${resource.NON_EXISTENT_KEY}, then we end up with the
string {noformat}???NON_EXISTENT_KEY???{noformat}
This has to do with the
org.apache.velocity.tools.generic.ResourceTool.Key.toString implementation as
shown below:
{code:java}
public String toString()
{
if (this.key == null)
{
return ;
}
if (!getExists())
{
return ???+this.key+???;
}
return ResourceTool.this.render(this.rawValue, this.args);
}
{code}
Any reason why we can't force a FormatException when running in strict mode?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELTOOLS-167) Dealing with missing keys in resource bundle
[
https://issues.apache.org/jira/browse/VELTOOLS-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergiu Dumitriu updated VELTOOLS-167:
-
Description:
No exception is thrown when doing a template merge with a non-existent key from
the resource bundle.
eg. if the template has ${resource.NON_EXISTENT_KEY}, then we end up with the
string {noformat}???NON_EXISTENT_KEY???{noformat}
This has to do with the
org.apache.velocity.tools.generic.ResourceTool.Key.toString implementation as
shown below:
{code:java}
public String toString()
{
if (this.key == null)
{
return ;
}
if (!getExists())
{
return ???+this.key+???;
}
return ResourceTool.this.render(this.rawValue, this.args);
}
{code}
Any reason why we can't force a FormatException when running in strict mode?
was:
No exception is thrown when doing a template merge with a non-existent key from
the resource bundle.
eg. if the template has ${resource.NON_EXISTENT_KEY}, then we end up with the
string {noformat}???NON_EXISTENT_KEY???{noformat}
This has to do with the
org.apache.velocity.tools.generic.ResourceTool.Key.toString implementation as
shown below:
public String toString()
{
if (this.key == null)
{
return ;
}
if (!getExists())
{
return ???+this.key+???;
}
return ResourceTool.this.render(this.rawValue, this.args);
}
Any reason why we can't force a FormatException when running in strict mode?
Dealing with missing keys in resource bundle
Key: VELTOOLS-167
URL: https://issues.apache.org/jira/browse/VELTOOLS-167
Project: Velocity Tools
Issue Type: Bug
Components: GenericTools
Affects Versions: 2.0
Reporter: Mohan Palisetti
Priority: Minor
No exception is thrown when doing a template merge with a non-existent key
from the resource bundle.
eg. if the template has ${resource.NON_EXISTENT_KEY}, then we end up with the
string {noformat}???NON_EXISTENT_KEY???{noformat}
This has to do with the
org.apache.velocity.tools.generic.ResourceTool.Key.toString implementation as
shown below:
{code:java}
public String toString()
{
if (this.key == null)
{
return ;
}
if (!getExists())
{
return ???+this.key+???;
}
return ResourceTool.this.render(this.rawValue, this.args);
}
{code}
Any reason why we can't force a FormatException when running in strict mode?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-818) Case-insensitive matching ${object.methodName} == ${object.methodname} == ${object.methodName}
[
https://issues.apache.org/jira/browse/VELOCITY-818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14570219#comment-14570219
]
Sergiu Dumitriu commented on VELOCITY-818:
--
I agree that it doesn't make sense as a default language feature, but this
could be an optional uberspector that could be enabled in the configuration.
Case-insensitive matching ${object.methodName} == ${object.methodname} ==
${object.methodName}
--
Key: VELOCITY-818
URL: https://issues.apache.org/jira/browse/VELOCITY-818
Project: Velocity
Issue Type: New Feature
Components: Engine
Affects Versions: 1.7
Reporter: Mark S
Labels: api-change
Original Estimate: 4h
Remaining Estimate: 4h
I thought I would share the following code with the Apache Velocity
community.
Currently there is no easy way for Velocity to do a case-insensitive match on
a property or method. Below is my implementation to achieve this.
VelocityContext velocityContext = new VelocityContext();
{
context.put( aNumericValue, 1234567890 );
}
| If String template = | Then String evaluatedTemplate = |
| ${aNumericValue} | 1234567890 |
| ${anumericvalue} | 1234567890 |
| ${anumericValue} | 1234567890 |
| ${aNumericvalue} | 1234567890 |
| ${aNumericValue.toString()} | 1234567890 |
| ${anumericvalue.tostring()} | 1234567890 |
-- Setup Snippet --
Properties p = new Properties();
p.setProperty( RuntimeConstants.INPUT_ENCODING, DEFAULT_ENCODING );
p.setProperty( RuntimeConstants.OUTPUT_ENCODING, DEFAULT_ENCODING );
p.setProperty( RuntimeConstants.UBERSPECT_CLASSNAME,
custom.CustomSecureUberspector ); //$NON-NLS-1$
VelocityEngine engine = new VelocityEngine( p );
engine.init();
RuntimeInstance ri = new RuntimeInstance();
ri.init( p );
uberspector = (CustomSecureUberspector)ri.getUberspect();
-- Setup Snippet --
-- Call Snippet --
VelocityContext velocityContext = new VelocityContext();
{
context.put( aNumericValue, 1234567890 );
}
EventCartridge eventCartridge = new EventCartridge();
eventCartridge.addEventHandler( new SloppyNameReferenceEventHandler(
uberspector ) );
eventCartridge.addEventHandler( new NullValueReferenceInsertionEventHandler()
);
eventCartridge.attachToContext( velocityContext );
String template = ${aNumericvalue};
StringWriter velocityWriter = new StringWriter();
velocityEngine.evaluate( velocityContext, velocityWriter, LOG, template );
String evaluatedTemplate = velocityWriter.toString();
-- Call Snippet --
-- Supporting Classes Snippet --
package custom;
import org.apache.velocity.util.introspection.SecureIntrospectorImpl;
import org.apache.velocity.util.introspection.SecureUberspector;
public class CustomSecureUberspector extends SecureUberspector
{
public SecureIntrospectorImpl getSecureIntrospector()
{
return (SecureIntrospectorImpl)introspector;
}
}
package custom;
import java.lang.reflect.Method;
import java.util.ArrayList;
import java.util.List;
import org.apache.velocity.app.event.InvalidReferenceEventHandler;
import org.apache.velocity.context.Context;
import org.apache.velocity.util.introspection.Info;
import org.apache.velocity.util.introspection.SecureIntrospectorImpl;
import custom.CustomSecureUberspector;
@SuppressWarnings( { unused } )
public class SloppyNameReferenceEventHandler implements
InvalidReferenceEventHandler
{
protected CustomSecureUberspector uberspector;
public SloppyNameReferenceEventHandler( CustomSecureUberspector
uberspector )
{
this.uberspector = uberspector;
}
@Override
public Object invalidGetMethod( Context context, String reference, Object
object, String property, Info info )
{
try
{
return callMethod( object, property );
}
catch ( Exception e )
{
return null;
}
}
@Override
public boolean invalidSetMethod( Context context, String leftReference,
String rightReference, Info info )
{
// Do nothing
return false;
}
@Override
public Object invalidMethod( Context context, String reference, Object
object, String method, Info info )
{
try
{
return callMethod( object, method );
}
catch ( Exception e )
{
return null;
}
}
protected Object callMethod( Object object, String method )
throws
[jira] [Closed] (VELOCITY-824) Wrong pom in velocity trunk
[ https://issues.apache.org/jira/browse/VELOCITY-824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergiu Dumitriu closed VELOCITY-824. Resolution: Fixed Fix Version/s: 2.x Assignee: Sergiu Dumitriu Wrong pom in velocity trunk --- Key: VELOCITY-824 URL: https://issues.apache.org/jira/browse/VELOCITY-824 Project: Velocity Issue Type: Bug Environment: Linux, velocity trunk Reporter: Dishara Wijewardana Assignee: Sergiu Dumitriu Fix For: 2.x Attachments: correct_trunk_pom.patch The current velocity trunk points to the wrong velocity master version pom. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (VELOCITY-854) Problem Creating a Default description
[
https://issues.apache.org/jira/browse/VELOCITY-854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergiu Dumitriu closed VELOCITY-854.
Resolution: Invalid
Assignee: Sergiu Dumitriu
Problem Creating a Default description
--
Key: VELOCITY-854
URL: https://issues.apache.org/jira/browse/VELOCITY-854
Project: Velocity
Issue Type: Bug
Components: Build
Reporter: Brian
Assignee: Sergiu Dumitriu
Priority: Minor
Hi Experts
I have an issue with creating a default description based on Issue Type and
Based on what Option is selected from the Custom Field. (Single Select List)
Not sure whether I am working on this correctly but I will explain what I
expecting first.
For Issue Type: Service Request I have a Custom Field Called Request Type (3
Options are available) For each of these 3 options when one is selected I
would like a different Description to display. Currently it doesn't actually
change the description based on Custom Field
This is my code what I have placed in
/opt/jira/atlassian-jira/WEB-INF/classes/templates/jira/issue/field/description_edit.vm
{noformat}
#disable_html_escaping()
#customControlHeader ($action $field.id $i18n.getText($field.nameKey)
$fieldLayoutItem.required $displayParameters $auiparams)
## setup some additional parameters
$!rendererParams.put(class, long-field)
$!rendererParams.put(rows, 12)
$!rendererParams.put(wrap, virtual)
#if ($mentionable)
$!rendererParams.put(mentionable, true)
#if ($issue.project.key $issue.project.key != )
$!rendererParams.put(data-projectkey, $!issue.project.key)
#end
#if ($issue.key $issue.key != )
$!rendererParams.put(data-issuekey, $!issue.key)
#end
#end
##===
START CUSTOMIZATION
## SET INCIDENT
#if (($issue.key == $null) ($issue.getIssueTypeObject().getName() ==
Incident))
#set ($description = 'h6. Steps to Reproduce
# Navigate to ...
# Click on ...
\
h6. Expected Results
\
h6. Actual Results
\
h6. Other Information (Browser, Browser Version,
Environment)')
#set ($description = $description.replace('\',''))
## SET SERVICE REQUEST 'NONE'
#elseif ((($issue.key == $null) ($issue.getIssueTypeObject().getName() ==
Service Request))
*($ComponentAccessor.getCustomFieldManager().getCustomFieldObjectByValue(customfield_11504)));
#if ($getcustomfieldObjectByValue ==
customfield_11504).getOptionbyName == Enhancement)
#set ($description = 'Please select a Request Type')
#set ($description = $description.replace('\',''))
## SET SERVICE REQUEST 'DEPLOYMENT'
#elseif ($getcustomfieldObjectByValue ==
customfield_11504).getOptionbyName == Deployment)
#set ($description = 'h6. Name of System -
\
h6. Environment -
\
h6. Expected Delivery Date / Time -')
#set ($description = $description.replace('\',''))
## SET SERVICE REQUEST 'NEW ACCOUNT'
#elseif ($getcustomfieldObjectByValue ==
customfield_11504).getOptionbyName == New Account)
#set ($description = 'h6. Are you requesting for a new
account to be set up?
\
h6. Name of System -
\
h6. Name of New User -
\
h6. Contact Information (Email Address, Contact Number) -')
#set ($description = $description.replace('\',''))
#end
## SET CHANGE REQUEST
#if (($issue.key == $null) ($issue.getIssueTypeObject().getName() ==
Change Request))
#set ($description = 'h6. Change Logs
\
h6. Deployment Script
\
h6. Deployment Verification
\
h6. Roll Back Plan')
#set ($description = $description.replace('\',''))
#end
## END CUSTOMIZATION
## ===
## let the renderer display the edit component
$rendererDescriptor.getEditVM($!description, $!issue.key,
$!fieldLayoutItem.rendererType, $!field.id, $field.name, $rendererParams,
false)
#customControlFooter ($action $field.id
$fieldLayoutItem.getFieldDescription() $displayParameters $auiparams)
{noformat}
I receive this error
{noformat}
An error occurred whilst rendering this message. Please contact the
administrators, and inform them of this bug. Details: ---
org.apache.velocity.exception.ParseErrorException: Encountered EOF at
templates/jira/issue/field/description-edit.vm[line 80, column 110] Was
expecting one
[jira] [Closed] (VELOCITY-863) Regression: #settableft-paren no longer valid grammar
[ https://issues.apache.org/jira/browse/VELOCITY-863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergiu Dumitriu closed VELOCITY-863. Resolution: Fixed Fix Version/s: 1.7.1 2.x Assignee: Sergiu Dumitriu Patch applied on trunk, 1.7.x and 1.x, thank you. Regression: #settableft-paren no longer valid grammar --- Key: VELOCITY-863 URL: https://issues.apache.org/jira/browse/VELOCITY-863 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.7, 1.7.x Reporter: Mike Kienenberger Assignee: Sergiu Dumitriu Fix For: 2.x, 1.7.1 Attachments: Parser.jjt-set-directive-followed-by-tab.patch, javacc4.1-ParserTokenManager.java-set-directive-followed-by-tab.patch In velocity 1.3.1, tab was considered whitespace between the set directive and the first left-parenthesis. When the grammar was redesigned in Velocity 1.4, the ability to use tab as whitespace after #set was lost. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELTOOLS-142) $mathTool.roundTo fails for negative numbers
[ https://issues.apache.org/jira/browse/VELTOOLS-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13051140#comment-13051140 ] Sergiu Dumitriu commented on VELTOOLS-142: -- It's not good to introduce fixed issues in the release notes. This should be closed as Duplicate instead. $mathTool.roundTo fails for negative numbers Key: VELTOOLS-142 URL: https://issues.apache.org/jira/browse/VELTOOLS-142 Project: Velocity Tools Issue Type: Bug Components: GenericTools Environment: Linux Ubunu 8.05 Reporter: Marc Dzaebel Fix For: 1.4 MathTool.roundTo(1, -1) = 0.9 I use Polarion, which uses an old version (I think 1.4?) and can't be upgraded. Any workaround? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELTOOLS-142) $mathTool.roundTo fails for negative numbers
[ https://issues.apache.org/jira/browse/VELTOOLS-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13050467#comment-13050467 ] Sergiu Dumitriu commented on VELTOOLS-142: -- Works for me on velocity-tools-1.4. Are you sure 1.4 isn't the version of velocity-engine? $mathTool.roundTo fails for negative numbers Key: VELTOOLS-142 URL: https://issues.apache.org/jira/browse/VELTOOLS-142 Project: Velocity Tools Issue Type: Bug Components: GenericTools Affects Versions: 1.4 Environment: Linux Ubunu 8.05 Reporter: Marc Dzaebel Priority: Critical MathTool.roundTo(1, -1) = 0.9 I use Polarion, which uses an old version (I think 1.4?) and can't be upgraded. Any workaround? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-801) Velocity 1.7 uses string interning
[ https://issues.apache.org/jira/browse/VELOCITY-801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13027060#comment-13027060 ] Sergiu Dumitriu commented on VELOCITY-801: -- myth3 has one important if: the internalized strings are garbage collected *if* there are no more references to them, and, IIRC, Velocity also caches the parsed templates, which counts as existing references. Velocity 1.7 uses string interning -- Key: VELOCITY-801 URL: https://issues.apache.org/jira/browse/VELOCITY-801 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.7.x Environment: n.a. Reporter: Alexander Veit Priority: Critical String interning consumes memory that cannot be reclaimed by the java runtime even if the velocity runtime singleton is being discarded. This is an issue for server applications that use Velocity (e.g. we have a software product that may use tens of thousands of Velocity files to create content dynamically). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] Commented: (VELOCITY-796) Velocity #parse not parsing content.
[ https://issues.apache.org/jira/browse/VELOCITY-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12988029#action_12988029 ] Sergiu Dumitriu commented on VELOCITY-796: -- We've encountered this occasionally for a long time (1.6, and I think 1.5 as well), but it was pretty rare, and a refresh usually solved the problem until the next time. If I remember correctly, I think I did a little debugging a while ago and the problem was with parallel requests trying to add the same macro namespace in the macro cache. Velocity #parse not parsing content. Key: VELOCITY-796 URL: https://issues.apache.org/jira/browse/VELOCITY-796 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.7 Environment: Linux Server running Apache Web Server in front of a JBoss 5 Application Server Reporter: Wayne Baskin Attachments: Velocity Screen Shot.jpg, viewer.png The issue is occuring randomly and could be load related. The issue has only appeared since upgrading to Version 1.7. The parse element will display all Velccity code it was suppose to parse. I have a screen shot if required. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] Commented: (VELOCITY-692) have #if handle empty strings/arrays/collections/maps more conveniently
[ https://issues.apache.org/jira/browse/VELOCITY-692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12975498#action_12975498 ] Sergiu Dumitriu commented on VELOCITY-692: -- How about 0, either as a Number with that value, or as the result of a getAsNumber method? JavaScript considers 0 as falsey as well. Why not put the length() and size() check before getAsString, since length/size are closer in meaning to isEmpty, while getAsString is closer to toString? have #if handle empty strings/arrays/collections/maps more conveniently --- Key: VELOCITY-692 URL: https://issues.apache.org/jira/browse/VELOCITY-692 Project: Velocity Issue Type: New Feature Components: Engine Reporter: Nathan Bubna Priority: Trivial An idea from the dev list: - On Sat, Feb 7, 2009 at 3:41 PM, serg...@gmail.com wrote: Hello, I wanted to share with you a few ideas I have about new simple improvements for DisplayTools. I should be able to make patches for them if you are interested. 1. Add new method isEmpty(object) that will return true if the object is null or empty (for strings it's zero length; for collections, maps and arrays it's zero size). This should help with annoying null checks. (Probably a better place for this method would be Engine, not Tools) yeah, not something for tools. would be interesting to have the Uberspect pretend that every non-null reference has an isEmpty() method, or perhaps just add 0-length strings, empty collections, empty maps and 0-length arrays to the list of things that #if( $foo ) considers false. - -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] Commented: (VELOCITY-684) Passing a map literal to a macro call forbids altering the map in any way, while maps bound to an actual parameter may be changed
[
https://issues.apache.org/jira/browse/VELOCITY-684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12863424#action_12863424
]
Sergiu Dumitriu commented on VELOCITY-684:
--
See http://wiki.apache.org/velocity/MacroEvaluationStrategy
Passing a map literal to a macro call forbids altering the map in any way,
while maps bound to an actual parameter may be changed
-
Key: VELOCITY-684
URL: https://issues.apache.org/jira/browse/VELOCITY-684
Project: Velocity
Issue Type: Bug
Components: Engine
Affects Versions: 1.6.1
Reporter: Sergiu Dumitriu
For example, with the following macro:
#macro(changeMap $map)
Before: $map.someKey
#set($map.someKey = 'new value')
After: $map.someKey
#end
This call works as expected:
#set($actualMap = {'someKey' : 'old value'})
#changeMap($actualMap) = old value, then new value
But this one doesn't:
#changeMap({'someKey' : 'old value'}) = old value, then again old value
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] Commented: (VELOCITY-681) [regression] Changes on the macro parameters are not persisted outside the macro call
[
https://issues.apache.org/jira/browse/VELOCITY-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12863426#action_12863426
]
Sergiu Dumitriu commented on VELOCITY-681:
--
See http://wiki.apache.org/velocity/MacroEvaluationStrategy
[regression] Changes on the macro parameters are not persisted outside the
macro call
-
Key: VELOCITY-681
URL: https://issues.apache.org/jira/browse/VELOCITY-681
Project: Velocity
Issue Type: Bug
Components: Engine
Affects Versions: 1.6.1
Reporter: Sergiu Dumitriu
Priority: Critical
Fix For: 1.6.2
Attachments: VELOCITY-681-1.6.patch, VELOCITY-681-trunk.patch
The fix for VELOCITY-615 was too radical, since it completely disables
#setting new values to the formal arguments. A minimalistic example that used
to work up to 1.6 (but not with 1.6.1) is:
{noformat}
#macro(myMacro $result)
#set($result = 'some value')
#end
#myMacro($x)
$x
{/noformat}
which prints $x (as an undefined variable).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] Commented: (VELOCITY-684) Passing a map literal to a macro call forbids altering the map in any way, while maps bound to an actual parameter may be changed
[
https://issues.apache.org/jira/browse/VELOCITY-684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1233#action_1233
]
Sergiu Dumitriu commented on VELOCITY-684:
--
No, there's no real usecase, I simply found this writing tests for VELOCITY-681
(you can see them commented in test/templates/velocimacro.vm). I just find it
surprising and counter-intuitive for a user.
Passing a map literal to a macro call forbids altering the map in any way,
while maps bound to an actual parameter may be changed
-
Key: VELOCITY-684
URL: https://issues.apache.org/jira/browse/VELOCITY-684
Project: Velocity
Issue Type: Bug
Components: Engine
Affects Versions: 1.6.1
Reporter: Sergiu Dumitriu
For example, with the following macro:
#macro(changeMap $map)
Before: $map.someKey
#set($map.someKey = 'new value')
After: $map.someKey
#end
This call works as expected:
#set($actualMap = {'someKey' : 'old value'})
#changeMap($actualMap) = old value, then new value
But this one doesn't:
#changeMap({'someKey' : 'old value'}) = old value, then again old value
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] Commented: (VELOCITY-681) [regression] Changes on the macro parameters are not persisted outside the macro call
[
https://issues.apache.org/jira/browse/VELOCITY-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1245#action_1245
]
Sergiu Dumitriu commented on VELOCITY-681:
--
After reading a bit more, I think that velocimacros are supposed to work as
pass-by-name, and pass-by-name should allow the usecase described above. So,
even if the behavior is not intuitive for some, it is correct for pass-by-name.
[regression] Changes on the macro parameters are not persisted outside the
macro call
-
Key: VELOCITY-681
URL: https://issues.apache.org/jira/browse/VELOCITY-681
Project: Velocity
Issue Type: Bug
Components: Engine
Affects Versions: 1.6.1
Reporter: Sergiu Dumitriu
Priority: Critical
Fix For: 1.6.2, 1.7
Attachments: VELOCITY-681-1.6.patch, VELOCITY-681-trunk.patch
The fix for VELOCITY-615 was too radical, since it completely disables
#setting new values to the formal arguments. A minimalistic example that used
to work up to 1.6 (but not with 1.6.1) is:
{noformat}
#macro(myMacro $result)
#set($result = 'some value')
#end
#myMacro($x)
$x
{/noformat}
which prints $x (as an undefined variable).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] Created: (VELOCITY-681) [regression] Changes on the macro parameters are not persisted outside the macro call
[regression] Changes on the macro parameters are not persisted outside the
macro call
-
Key: VELOCITY-681
URL: https://issues.apache.org/jira/browse/VELOCITY-681
Project: Velocity
Issue Type: Bug
Components: Engine
Affects Versions: 1.6.1
Reporter: Sergiu Dumitriu
Priority: Critical
Fix For: 1.6.2, 1.7
The fix for VELOCITY-615 was too radical, since it completely disables #setting
new values to the formal arguments. A minimalistic example that used to work up
until 1.6 is:
{noformat}
#macro(myMacro $result)
#set($result = 'some value')
#end
#myMacro($x)
$x
{/noformat}
which prints $x (as an undefined variable).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] Updated: (VELOCITY-681) [regression] Changes on the macro parameters are not persisted outside the macro call
[
https://issues.apache.org/jira/browse/VELOCITY-681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergiu Dumitriu updated VELOCITY-681:
-
Attachment: VELOCITY-681-trunk.patch
[regression] Changes on the macro parameters are not persisted outside the
macro call
-
Key: VELOCITY-681
URL: https://issues.apache.org/jira/browse/VELOCITY-681
Project: Velocity
Issue Type: Bug
Components: Engine
Affects Versions: 1.6.1
Reporter: Sergiu Dumitriu
Priority: Critical
Fix For: 1.6.2, 1.7
Attachments: VELOCITY-681-1.6.patch, VELOCITY-681-trunk.patch
The fix for VELOCITY-615 was too radical, since it completely disables
#setting new values to the formal arguments. A minimalistic example that used
to work up until 1.6 is:
{noformat}
#macro(myMacro $result)
#set($result = 'some value')
#end
#myMacro($x)
$x
{/noformat}
which prints $x (as an undefined variable).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] Commented: (VELOCITY-681) [regression] Changes on the macro parameters are not persisted outside the macro call
[
https://issues.apache.org/jira/browse/VELOCITY-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12666381#action_12666381
]
Sergiu Dumitriu commented on VELOCITY-681:
--
Provided a fix, which doesn't break any of the existing tests.
The behavior of org.apache.velocity.context.ProxyVMContext#put was changed to
match the following behavior:
- If this is a valid proxy to a variable, set the value of the proxied
variable; otherwise:
- If a local scope is enforced, set a local variable; otherwise:
- If this is a local variable, set a local variable; otherwise:
- If this is a proxy to a literal, set a local literal variable, and a global
variable; otherwise:
- Set a global variable (where global means the parent context)
Also, #get was changed to take into account local literal variables.
Local literal variable means a context parameter with the key
.literal.$varName, which was already used in #addVMProxyArg.
[regression] Changes on the macro parameters are not persisted outside the
macro call
-
Key: VELOCITY-681
URL: https://issues.apache.org/jira/browse/VELOCITY-681
Project: Velocity
Issue Type: Bug
Components: Engine
Affects Versions: 1.6.1
Reporter: Sergiu Dumitriu
Priority: Critical
Fix For: 1.6.2, 1.7
Attachments: VELOCITY-681-1.6.patch, VELOCITY-681-trunk.patch
The fix for VELOCITY-615 was too radical, since it completely disables
#setting new values to the formal arguments. A minimalistic example that used
to work up until 1.6 is:
{noformat}
#macro(myMacro $result)
#set($result = 'some value')
#end
#myMacro($x)
$x
{/noformat}
which prints $x (as an undefined variable).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] Created: (VELOCITY-682) #evaluate breaks macro processing
#evaluate breaks macro processing
-
Key: VELOCITY-682
URL: https://issues.apache.org/jira/browse/VELOCITY-682
Project: Velocity
Issue Type: Bug
Components: Engine
Affects Versions: 1.6.1
Reporter: Sergiu Dumitriu
When using #evaluate, all further macro processing is broken; old macros are
not recognized anymore, and new macros cannot be defined.
For example:
{noformat}
#macro(aSimpleMacro)
This is a simple macro
#end
## called 3 times to show that it works each time
#aSimpleMacro()
#aSimpleMacro()
#aSimpleMacro()
#macro(doEval $b)
#evaluate($x)
#end
#set($x = 'value of x')
#doEval('$x')
## after the first call, which used an #evaluate, these two won't work anymore:
#doEval('$x')
#doEval('$x')
#macro(anotherSimpleMacro)
This is another simple macro
#end
## This newly defined macro doesn't work, either...
#anotherSimpleMacro()
## And the first macro, which worked well before, suddenly stops working
#aSimpleMacro()
{/noformat}
should print:
{noformat}
This is a simple macro
This is a simple macro
This is a simple macro
value of x
value of x
value of x
This is another simple macro
This is a simple macro
{/noformat}
but instead prints:
{noformat}
This is a simple macro
This is a simple macro
This is a simple macro
value of x
#doEval('$x')
#doEval('$x')
#anotherSimpleMacro()
#aSimpleMacro()
{/noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] Updated: (VELOCITY-681) [regression] Changes on the macro parameters are not persisted outside the macro call
[
https://issues.apache.org/jira/browse/VELOCITY-681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergiu Dumitriu updated VELOCITY-681:
-
Description:
The fix for VELOCITY-615 was too radical, since it completely disables #setting
new values to the formal arguments. A minimalistic example that used to work up
to 1.6 (but not with 1.6.1) is:
{noformat}
#macro(myMacro $result)
#set($result = 'some value')
#end
#myMacro($x)
$x
{/noformat}
which prints $x (as an undefined variable).
was:
The fix for VELOCITY-615 was too radical, since it completely disables #setting
new values to the formal arguments. A minimalistic example that used to work up
until 1.6 is:
{noformat}
#macro(myMacro $result)
#set($result = 'some value')
#end
#myMacro($x)
$x
{/noformat}
which prints $x (as an undefined variable).
[regression] Changes on the macro parameters are not persisted outside the
macro call
-
Key: VELOCITY-681
URL: https://issues.apache.org/jira/browse/VELOCITY-681
Project: Velocity
Issue Type: Bug
Components: Engine
Affects Versions: 1.6.1
Reporter: Sergiu Dumitriu
Priority: Critical
Fix For: 1.6.2, 1.7
Attachments: VELOCITY-681-1.6.patch, VELOCITY-681-trunk.patch
The fix for VELOCITY-615 was too radical, since it completely disables
#setting new values to the formal arguments. A minimalistic example that used
to work up to 1.6 (but not with 1.6.1) is:
{noformat}
#macro(myMacro $result)
#set($result = 'some value')
#end
#myMacro($x)
$x
{/noformat}
which prints $x (as an undefined variable).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] Created: (VELOCITY-683) When passing literals other than strings to macro calls, setting new values the formal parameters does not propagate the changes outside the local scope
When passing literals other than strings to macro calls, setting new values the
formal parameters does not propagate the changes outside the local scope
Key: VELOCITY-683
URL: https://issues.apache.org/jira/browse/VELOCITY-683
Project: Velocity
Issue Type: Bug
Components: Engine
Affects Versions: 1.6.1, 1.6, 1.5
Reporter: Sergiu Dumitriu
Priority: Minor
With this macro definition:
#macro(setValueToEmpty $value)
#set($value = '')
#end
While the following works well:
#set($value = 'abc')
#setValueToEmpty('abc') = $value == ''
this fails:
#set($value = 'abc')
#setValueToEmpty(3) = $value == 'abc'
This is caused by the fact that in
org.apache.velocity.context.ProxyVMContext#addVMProxyArg if the parameter is a
constant (which somehow doesn't include strings), then a local variable is
created with the node's value as its value. For string literals, the actual
node is placed in the proxy map, which allows setting a new value for it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] Created: (VELOCITY-684) Passing a map literal to a macro call forbids altering the map in any way, while maps bound to an actual parameter may be changed
Passing a map literal to a macro call forbids altering the map in any way,
while maps bound to an actual parameter may be changed
-
Key: VELOCITY-684
URL: https://issues.apache.org/jira/browse/VELOCITY-684
Project: Velocity
Issue Type: Bug
Components: Engine
Affects Versions: 1.6.1
Reporter: Sergiu Dumitriu
For example, with the following macro:
#macro(changeMap $map)
Before: $map.someKey
#set($map.someKey = 'new value')
After: $map.someKey
#end
This call works as expected:
#set($actualMap = {'someKey' : 'old value'})
#changeMap($actualMap) = old value, then new value
But this one doesn't:
#changeMap({'someKey' : 'old value'}) = old value, then again old value
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] Commented: (VELOCITY-588) Provide a an ubespector that allows chaining other uberspectors
[ https://issues.apache.org/jira/browse/VELOCITY-588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12624301#action_12624301 ] Sergiu Dumitriu commented on VELOCITY-588: -- I had it about 60% done, but during the past month I had several hardware problems, starting with a hdd failure, so I'll have to redo it. Provide a an ubespector that allows chaining other uberspectors --- Key: VELOCITY-588 URL: https://issues.apache.org/jira/browse/VELOCITY-588 Project: Velocity Issue Type: Improvement Components: Engine Affects Versions: 1.5 Reporter: Vincent Massol Priority: Minor Fix For: 1.6 Attachments: ChainableUberspectorsXWiki.patch In XWiki project we're using Velocity and have a need to write several uberspectors that we'd like to chain (see http://jira.xwiki.org/jira/browse/XWIKI-2182). We're writing a custom uberspector that'll allow chaining other uberspectors but we think that uberspector should best be located in the Velocity project if you're interested. Let us know what you think and if you agree we can donate it to you or you could create one from scratch if you agree with the use case. Thanks -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-588) Provide a an ubespector that allows chaining other uberspectors
[ https://issues.apache.org/jira/browse/VELOCITY-588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergiu Dumitriu updated VELOCITY-588: - Attachment: ChainableUberspectorsXWiki.patch This is the first version of the implementation done for XWiki. Please review it, and if it looks good I can make a patch for the velocity trunk. Provide a an ubespector that allows chaining other uberspectors --- Key: VELOCITY-588 URL: https://issues.apache.org/jira/browse/VELOCITY-588 Project: Velocity Issue Type: Improvement Components: Engine Affects Versions: 1.5 Reporter: Vincent Massol Priority: Minor Attachments: ChainableUberspectorsXWiki.patch In XWiki project we're using Velocity and have a need to write several uberspectors that we'd like to chain (see http://jira.xwiki.org/jira/browse/XWIKI-2182). We're writing a custom uberspector that'll allow chaining other uberspectors but we think that uberspector should best be located in the Velocity project if you're interested. Let us know what you think and if you agree we can donate it to you or you could create one from scratch if you agree with the use case. Thanks -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
