[jira] [Commented] (VELOCITY-933) Spring support for Velocity
[ https://issues.apache.org/jira/browse/VELOCITY-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17284007#comment-17284007 ] Nathan Bubna commented on VELOCITY-933: --- I didn't actually try that. And actually, i can't figure out a way to edit it, despite the fact that it claims to be fully unlocked. > Spring support for Velocity > --- > > Key: VELOCITY-933 > URL: https://issues.apache.org/jira/browse/VELOCITY-933 > Project: Velocity > Issue Type: Task > Components: Engine >Affects Versions: 2.3 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Major > Fix For: 2.3 > > Attachments: 2021-02-12 Vel 2.2 shows 1.7.png, Velocity Search > Results.png, image-2021-02-12-12-13-04-901.png > > > Add a new jar submodule for Velocity Spring support -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-933) Spring support for Velocity
[ https://issues.apache.org/jira/browse/VELOCITY-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17283956#comment-17283956 ] Nathan Bubna edited comment on VELOCITY-933 at 2/12/21, 8:13 PM: - Not sure i have any perms to edit wiki restrictions, nor whether you need special permission: !image-2021-02-12-12-13-04-901.png|width=601,height=197! was (Author: nbubna): Not sure i have any perms to edit wiki restrictions, nor whether you need special permission: !image-2021-02-12-12-13-04-901.png! > Spring support for Velocity > --- > > Key: VELOCITY-933 > URL: https://issues.apache.org/jira/browse/VELOCITY-933 > Project: Velocity > Issue Type: Task > Components: Engine >Affects Versions: 2.3 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Major > Fix For: 2.3 > > Attachments: 2021-02-12 Vel 2.2 shows 1.7.png, Velocity Search > Results.png, image-2021-02-12-12-13-04-901.png > > > Add a new jar submodule for Velocity Spring support -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-933) Spring support for Velocity
[ https://issues.apache.org/jira/browse/VELOCITY-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17283956#comment-17283956 ] Nathan Bubna commented on VELOCITY-933: --- Not sure i have any perms to edit wiki restrictions, nor whether you need special permission: !image-2021-02-12-12-13-04-901.png! > Spring support for Velocity > --- > > Key: VELOCITY-933 > URL: https://issues.apache.org/jira/browse/VELOCITY-933 > Project: Velocity > Issue Type: Task > Components: Engine >Affects Versions: 2.3 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Major > Fix For: 2.3 > > Attachments: 2021-02-12 Vel 2.2 shows 1.7.png, Velocity Search > Results.png, image-2021-02-12-12-13-04-901.png > > > Add a new jar submodule for Velocity Spring support -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Updated] (VELOCITY-933) Spring support for Velocity
[ https://issues.apache.org/jira/browse/VELOCITY-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Bubna updated VELOCITY-933: -- Attachment: image-2021-02-12-12-13-04-901.png > Spring support for Velocity > --- > > Key: VELOCITY-933 > URL: https://issues.apache.org/jira/browse/VELOCITY-933 > Project: Velocity > Issue Type: Task > Components: Engine >Affects Versions: 2.3 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Major > Fix For: 2.3 > > Attachments: 2021-02-12 Vel 2.2 shows 1.7.png, Velocity Search > Results.png, image-2021-02-12-12-13-04-901.png > > > Add a new jar submodule for Velocity Spring support -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELTOOLS-184) EscapeTool: add a json method, or a javascript method with a second parameter
[ https://issues.apache.org/jira/browse/VELTOOLS-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17037238#comment-17037238 ] Nathan Bubna commented on VELTOOLS-184: --- LOL. Sorry, didn't read carefully. I get it now, a single quote in a double quoted string is being escaped when it shouldn't be. Got it. Yeah, a JSON-escaping method would be good. You interested in contributing a patch? > EscapeTool: add a json method, or a javascript method with a second parameter > - > > Key: VELTOOLS-184 > URL: https://issues.apache.org/jira/browse/VELTOOLS-184 > Project: Velocity Tools > Issue Type: Improvement > Components: GenericTools >Affects Versions: 2.x > Environment: any >Reporter: Maurice Perry >Priority: Minor > Labels: EscapeTool, escape, javascript, json > > The string returned by EscapeTool.javascript() method is not alway compliant > with the JSON syntax. For instance, when the input string contains an > apostrophe ', a backslash is inserted before it because there is no way for > the method to know if the string is enclosed with single or double quotes. > This is not compliant with the JSON syntax, and some JSON parsers will reject > the string. > There may be other differences between javascript and JSON strings, but this > is the one I encountered, and I had to use a workaround. > This issue can be solved either with a JSON method, or with a second > javascript method with a second parameter indicating the type of quote used. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELTOOLS-184) EscapeTool: add a json method, or a javascript method with a second parameter
[ https://issues.apache.org/jira/browse/VELTOOLS-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17037112#comment-17037112 ] Nathan Bubna commented on VELTOOLS-184: --- [https://www.json.org/json-en.html] Only double quoted strings are allowed in JSON. > EscapeTool: add a json method, or a javascript method with a second parameter > - > > Key: VELTOOLS-184 > URL: https://issues.apache.org/jira/browse/VELTOOLS-184 > Project: Velocity Tools > Issue Type: Improvement > Components: GenericTools >Affects Versions: 2.x > Environment: any >Reporter: Maurice Perry >Priority: Minor > Labels: EscapeTool, escape, javascript, json > > The string returned by EscapeTool.javascript() method is not alway compliant > with the JSON syntax. For instance, when the input string contains an > apostrophe ', a backslash is inserted before it because there is no way for > the method to know if the string is enclosed with single or double quotes. > This is not compliant with the JSON syntax, and some JSON parsers will reject > the string. > There may be other differences between javascript and JSON strings, but this > is the one I encountered, and I had to use a workaround. > This issue can be solved either with a JSON method, or with a second > javascript method with a second parameter indicating the type of quote used. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELTOOLS-180) New velocity-tools-model architecture
[ https://issues.apache.org/jira/browse/VELTOOLS-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16829744#comment-16829744 ] Nathan Bubna commented on VELTOOLS-180: --- Gah, i'm stuck in jello. Sorry, been too busy with other things to stop and really think on this. I think the way you went is fine, of course, though i do think a velocity-model type project might make sense, particularly if you can get any community to work with you. What i wouldn't want is to bring it in under the Velocity PMC responsibility and have it ultimately be a one-man piece of an already-hurting-for-active-participants Apache project. > New velocity-tools-model architecture > - > > Key: VELTOOLS-180 > URL: https://issues.apache.org/jira/browse/VELTOOLS-180 > Project: Velocity Tools > Issue Type: New Feature > Components: Misc >Affects Versions: 3.1 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Major > > The new data access layer (or persistence-less ORM) module that constitutes > the Model Tool, and which once was the > [Velosurf|https://github.com/arkanovicz/velosurf] library but rewritten at > 90%, sits in the [model > branch|http://svn.apache.org/viewvc/velocity/tools/branches/model/velocity-tools-model/]. > But I started having second thoughts while coding. If you look at [this class > diagram|https://republicate.com/class_diagram.svg], you'll see that there are > only 5/6 objects that will appear in VTL contexts. The remaining of the > library is about 40 classes, and offers by itself an ORM which I tried to > keep simple and efficient also on the Java side. > So I'm starting to think that I should just publish here the VTL related > objects and host the ORM library elsewhere. It's more in the spirit of > VelocityTools to keep things lightweight, and separate projects are the best > guaranty of code isolation. > For instance, I can publish it along with other projects that I publish on > maven central in the com.republicate group id, like the > [webapp-slf4j-logger|https://github.com/arkanovicz/webapp-slf4j-logger]. > It makes velocity-tools-model rely on a project external to apache, but it's > not a problem per se. Or the ORM library can find its way to the apache > codebase through, like, a commons-model project. Or start at com.republicate > and then migrate. Or start here then migrate elsewhere... > -- 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-180) New velocity-tools-model architecture
[ https://issues.apache.org/jira/browse/VELTOOLS-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823341#comment-16823341 ] Nathan Bubna commented on VELTOOLS-180: --- Do the VTL related objects have any utility without your ORM? > New velocity-tools-model architecture > - > > Key: VELTOOLS-180 > URL: https://issues.apache.org/jira/browse/VELTOOLS-180 > Project: Velocity Tools > Issue Type: New Feature > Components: Misc >Affects Versions: 3.1 >Reporter: Claude Brisson >Assignee: Claude Brisson >Priority: Major > > The new data access layer (or persistence-less ORM) module that constitutes > the Model Tool, and which once was the > [Velosurf|https://github.com/arkanovicz/velosurf] library but rewritten at > 90%, sits in the [model > branch|http://svn.apache.org/viewvc/velocity/tools/branches/model/velocity-tools-model/]. > But I started having second thoughts while coding. If you look at [this class > diagram|https://republicate.com/class_diagram.svg], you'll see that there are > only 5/6 objects that will appear in VTL contexts. The remaining of the > library is about 40 classes, and offers by itself an ORM which I tried to > keep simple and efficient also on the Java side. > So I'm starting to think that I should just publish here the VTL related > objects and host the ORM library elsewhere. It's more in the spirit of > VelocityTools to keep things lightweight, and separate projects are the best > guaranty of code isolation. > For instance, I can publish it along with other projects that I publish on > maven central in the com.republicate group id, like the > [webapp-slf4j-logger|https://github.com/arkanovicz/webapp-slf4j-logger]. > It makes velocity-tools-model rely on a project external to apache, but it's > not a problem per se. Or the ORM library can find its way to the apache > codebase through, like, a commons-model project. Or start at com.republicate > and then migrate. Or start here then migrate elsewhere... > -- 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-143) LinkTool.uri() causes mailto: links to ignore parameters added using param() method
[ https://issues.apache.org/jira/browse/VELTOOLS-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16633614#comment-16633614 ] Nathan Bubna commented on VELTOOLS-143: --- I never was happy with the complexity of this tool. 30 seconds of re-evaluation (so take this with a grain of salt), makes me think this could also be re-written with a "sub-tool" that gathers all the params/uris/etc as it goes and then only tries to sort out what things to set in an intelligent order when toString() (or some build() method) is finally called. That last part could be done using URIBuilder or URI, the main point is to delay construction/merging/etc until called for so that the order of the calls does not have to be the order of the merging/constructing/etc. Of course, i have no time to do such things myself... :( > LinkTool.uri() causes mailto: links to ignore parameters added using param() > method > --- > > Key: VELTOOLS-143 > URL: https://issues.apache.org/jira/browse/VELTOOLS-143 > Project: Velocity Tools > Issue Type: Bug > Components: GenericTools >Affects Versions: 2.0 > Environment: Velocity 1.7, Velocity Tools 2.0 >Reporter: Christopher Schultz >Priority: Minor > > This worked in Velocity Tools 1.4. -- 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-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=15376888#comment-15376888 ] Nathan Bubna commented on VELOCITY-553: --- Yes, that one i'm sure about. Strict mode should act more like strict typing and never be generous about invalid refs, only null ones. > 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-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=15376262#comment-15376262 ] Nathan Bubna commented on VELOCITY-553: --- Good question. My instinct is to say yes, silent is silent and give that control to the template instead of letting the configuration override it. But i can see arguments either way. > 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-812) Parser.jj_scan_token very slow during debugging
[ https://issues.apache.org/jira/browse/VELOCITY-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13109594#comment-13109594 ] Nathan Bubna commented on VELOCITY-812: --- Just to be sure you know, that code is pretty much all generated by JavaCC. You might try building Velocity with the latest JavaCC version to see if that helps. We are not going to be applying any patches or fixes directly to generated code, as that is unmaintainable for us. Parser.jj_scan_token very slow during debugging --- Key: VELOCITY-812 URL: https://issues.apache.org/jira/browse/VELOCITY-812 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.7 Environment: linux, windows, tomcat 6 running via maven, JDK7 (but had same issue with JDK6) Reporter: Konstantinos Kougios Attachments: profile.png Parser.jj_scan_token runs very slowly during java debugging mode. I've allocated more than enough memory for Java (Xmx , Xss, PermGen) and made sure it is enough by monitoring via visualvm. I am working on a springframework mvc project, with velocity as the template engine. Spring has a macro file that is loaded during startup : spring.vm (10kb). My box (6 core phenom processor) takes 10 seconds to parse that macro. After profiling with visualvm, I found out that 9 secs are spend on jj_scan_token method. When running the project without debugging enabled, the parsing is very fast. Please note that the issue occurs without any customization of velocity properties. Typically though the properties look like this: springMacro.resource.loader.cache=true, resource.loader=[springMacro], velocimacro.library=org/springframework/web/servlet/view/velocity/spring.vm, output.encoding=UTF-8, input.encoding=UTF-8, springMacro.resource.loader.class=org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader Please note that I've tried removing the encoding, but still the problem persists. -- 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-812) Parser.jj_scan_token very slow during debugging
[ https://issues.apache.org/jira/browse/VELOCITY-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13109642#comment-13109642 ] Nathan Bubna commented on VELOCITY-812: --- hmm. not generated at all? or perhaps ends up in the wrong package? Parser.jj_scan_token very slow during debugging --- Key: VELOCITY-812 URL: https://issues.apache.org/jira/browse/VELOCITY-812 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.7 Environment: linux, windows, tomcat 6 running via maven, JDK7 (but had same issue with JDK6) Reporter: Konstantinos Kougios Attachments: profile.png Parser.jj_scan_token runs very slowly during java debugging mode. I've allocated more than enough memory for Java (Xmx , Xss, PermGen) and made sure it is enough by monitoring via visualvm. I am working on a springframework mvc project, with velocity as the template engine. Spring has a macro file that is loaded during startup : spring.vm (10kb). My box (6 core phenom processor) takes 10 seconds to parse that macro. After profiling with visualvm, I found out that 9 secs are spend on jj_scan_token method. When running the project without debugging enabled, the parsing is very fast. Please note that the issue occurs without any customization of velocity properties. Typically though the properties look like this: springMacro.resource.loader.cache=true, resource.loader=[springMacro], velocimacro.library=org/springframework/web/servlet/view/velocity/spring.vm, output.encoding=UTF-8, input.encoding=UTF-8, springMacro.resource.loader.class=org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader Please note that I've tried removing the encoding, but still the problem persists. -- 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] [Resolved] (VELOCITY-811) Concurrency problems with rendering macros
[ https://issues.apache.org/jira/browse/VELOCITY-811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Bubna resolved VELOCITY-811. --- Resolution: Duplicate Fix Version/s: 2.x 1.7.x I'd be shocked if it weren't the same as VELOCITY-776, enough so that i'm marking it as a duplicate. Alex, can you confirm that the workarounds in VELOCITY-776 resolve the concurrency issue? Also, please weigh in on the proposed solutions. Anyone interested in stepping up with a patch to implement #3 in the 1.7.x branch? Or even better, implement #5 in trunk/2.x? Concurrency problems with rendering macros -- Key: VELOCITY-811 URL: https://issues.apache.org/jira/browse/VELOCITY-811 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.7.x Environment: Oracle JVM 1.6.0_26-b03 on Ubuntu 11.04 Reporter: Alex Fix For: 1.7.x, 2.x When using a single instance of Velocity engine from multiple threads sometimes the macro invocation is rendered as literal (#macroName...) as opposed to rendering the macro itself. I looked at source code and there is at least one problem with the implementation of VelocimacroManager.addNamespace. The code there is strange from the multi-threading point of view and puts an empty namespace into the ConcurrentHashMap before restoring it back. It should probably use putIfAbsent method instead. -- 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-808) Proposal to add ability to pass variables to #parse()
[
https://issues.apache.org/jira/browse/VELOCITY-808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13078854#comment-13078854
]
Nathan Bubna commented on VELOCITY-808:
---
hmm. that is better, but the $args variable would be global and get stomped in
recursive or multi-level #parses, which has the potential to cause many
headaches. i would suggest that the $args would need to become $template.args
(i.e. put into the $template scope object) so that it is properly
nested/popped/etc. you should probably even override the
template.provide.scope.control=false default and automatically turn $template
on when #parse is invoked with arguments, to ensure that the template has
access to $template.args.
or, if you want named arguments, you could have #parse only accept a map (e.g.
#parse('tpl.vm' {'foo':$bar}) ) and then automatically copy those map values to
the $template scope object's storage to make $template.foo automatically
available.
Proposal to add ability to pass variables to #parse()
-
Key: VELOCITY-808
URL: https://issues.apache.org/jira/browse/VELOCITY-808
Project: Velocity
Issue Type: Improvement
Components: Engine
Affects Versions: 1.7
Reporter: Sergiy Kovalchuk
Labels: parse
I think it would be very useful to be able to pass variables to #parse(),
just like to #macro():
#parse(tpl.vm $var1 $var2 $var3)
This would add $var's to a local scope of tpl.vm.
Current approach of adding vars to a parent template above pollutes global
namespace.
--
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-146) LinkTool.relative(url) and LinkTool.absolute(url) improperly handle URLs with query strings or anchors
[
https://issues.apache.org/jira/browse/VELTOOLS-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13071786#comment-13071786
]
Nathan Bubna commented on VELTOOLS-146:
---
Actually, instead of creating a setFromURI that doesn't override actual values
with null ones, i think there is no good reason that setFromURI should ever do
that. So we should just adapt setFromURI to have a lighter touch and have
relative(url) and absolute(url) use that.
LinkTool.relative(url) and LinkTool.absolute(url) improperly handle URLs with
query strings or anchors
--
Key: VELTOOLS-146
URL: https://issues.apache.org/jira/browse/VELTOOLS-146
Project: Velocity Tools
Issue Type: Bug
Components: GenericTools
Affects Versions: 2.0
Reporter: Nathan Bubna
Priority: Minor
Fix For: 2.1
On Tue, Jul 26, 2011 at 2:27 PM, Christopher Schultz
ch...@christopherschultz.net wrote:
...
We use StrutsLinkTool pretty much everywhere and had been relying on the
previous behavior (tools 1.4) of StrutsLinkTool.setForward(String) which
takes a reference to a Struts-defined forward which is basically just
a URL.
In the past, we were able to define a URL in Struts like this:
forward name=some-reference path=/path/to/resource?foo=bar /
Then, in the markup:
a href=$link.setForward('some-reference')link text/a
It appears that somewhere in the modifications, the URL ha sbeen
sanitized and now /path/to/resource?foo=bar has been helpfully
replaced by /path/to/resource%3Ffoo=bar.
Was this intentional? Is there a way to get the old behavior back?
It was unintentionally changed, in part because i wasn't aware that forwards
could/would contain query strings. Basically, setForward passes the url to
absolute(url) which would correctly handle absolute urls with query strings
but treats relative urls as merely paths, without parsing out anchors or
query strings.
I think we should adapt both $link.relative($url) and $link.absolute($url) to
accept paths with query strings and anchors. This probably will require a
setFromURI(url, withoutOverriding) adapted from what absolute($url) does for
actual absolute URIs.
--
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] [Resolved] (VELTOOLS-146) LinkTool.relative(url) and LinkTool.absolute(url) improperly handle URLs with query strings or anchors
[
https://issues.apache.org/jira/browse/VELTOOLS-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Bubna resolved VELTOOLS-146.
---
Resolution: Fixed
Fix Version/s: 2.0.x
Fixed in r1151728. Also improves the $link.uri($uri) method and generally
simplifies the implementation of absolute(uri). :)
LinkTool.relative(url) and LinkTool.absolute(url) improperly handle URLs with
query strings or anchors
--
Key: VELTOOLS-146
URL: https://issues.apache.org/jira/browse/VELTOOLS-146
Project: Velocity Tools
Issue Type: Bug
Components: GenericTools
Affects Versions: 2.0
Reporter: Nathan Bubna
Assignee: Nathan Bubna
Priority: Minor
Fix For: 2.0.x, 2.1
On Tue, Jul 26, 2011 at 2:27 PM, Christopher Schultz
ch...@christopherschultz.net wrote:
...
We use StrutsLinkTool pretty much everywhere and had been relying on the
previous behavior (tools 1.4) of StrutsLinkTool.setForward(String) which
takes a reference to a Struts-defined forward which is basically just
a URL.
In the past, we were able to define a URL in Struts like this:
forward name=some-reference path=/path/to/resource?foo=bar /
Then, in the markup:
a href=$link.setForward('some-reference')link text/a
It appears that somewhere in the modifications, the URL ha sbeen
sanitized and now /path/to/resource?foo=bar has been helpfully
replaced by /path/to/resource%3Ffoo=bar.
Was this intentional? Is there a way to get the old behavior back?
It was unintentionally changed, in part because i wasn't aware that forwards
could/would contain query strings. Basically, setForward passes the url to
absolute(url) which would correctly handle absolute urls with query strings
but treats relative urls as merely paths, without parsing out anchors or
query strings.
I think we should adapt both $link.relative($url) and $link.absolute($url) to
accept paths with query strings and anchors. This probably will require a
setFromURI(url, withoutOverriding) adapted from what absolute($url) does for
actual absolute URIs.
--
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] [Created] (VELTOOLS-146) LinkTool.relative(url) and LinkTool.absolute(url) improperly handle URLs with query strings or anchors
LinkTool.relative(url) and LinkTool.absolute(url) improperly handle URLs with
query strings or anchors
--
Key: VELTOOLS-146
URL: https://issues.apache.org/jira/browse/VELTOOLS-146
Project: Velocity Tools
Issue Type: Bug
Components: GenericTools
Affects Versions: 2.0
Reporter: Nathan Bubna
Priority: Minor
Fix For: 2.1
On Tue, Jul 26, 2011 at 2:27 PM, Christopher Schultz
ch...@christopherschultz.net wrote:
...
We use StrutsLinkTool pretty much everywhere and had been relying on the
previous behavior (tools 1.4) of StrutsLinkTool.setForward(String) which
takes a reference to a Struts-defined forward which is basically just
a URL.
In the past, we were able to define a URL in Struts like this:
forward name=some-reference path=/path/to/resource?foo=bar /
Then, in the markup:
a href=$link.setForward('some-reference')link text/a
It appears that somewhere in the modifications, the URL ha sbeen
sanitized and now /path/to/resource?foo=bar has been helpfully
replaced by /path/to/resource%3Ffoo=bar.
Was this intentional? Is there a way to get the old behavior back?
It was unintentionally changed, in part because i wasn't aware that forwards
could/would contain query strings. Basically, setForward passes the url to
absolute(url) which would correctly handle absolute urls with query strings but
treats relative urls as merely paths, without parsing out anchors or query
strings.
I think we should adapt both $link.relative($url) and $link.absolute($url) to
accept paths with query strings and anchors. This probably will require a
setFromURI(url, withoutOverriding) adapted from what absolute($url) does for
actual absolute URIs.
--
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=13027071#comment-13027071 ] Nathan Bubna commented on VELOCITY-801: --- Those cached templates are discarded if the RuntimeInstance is discarded. Here's the bottom line on this. No relevant changes are going to be made for this without a test that demonstrates the problem and thus allows us to confirm the benefit of whatever solution is proposed. The use of string.intern() was added because it was demonstrated that it fixed some major performance issues. It will not be removed unless it is A) demonstrated to be a problem, as claimed and B) a replacement solution is offered that does not simply restore our previous issues. Also, since we are talking about a native method and deep JVM voodoo :), Alexander, it would be best if you included more environment info. Most especially, the JDK version, as that may well be relevant. Evidence/description of your application's particular symptom(s) would also be meaningful in supporting your diagnosis. 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-12) Access to public member variable of a class
[ https://issues.apache.org/jira/browse/VELOCITY-12?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13014017#comment-13014017 ] Nathan Bubna commented on VELOCITY-12: -- You're probably thinking of simple member types in apps where the developer also writes the templates. Anyway, thanks for contributing the Uberspect. I'll re-open the issue. Hopefully that makes the attachment option appear. I'm still getting used to this new JIRA version though. Access to public member variable of a class --- Key: VELOCITY-12 URL: https://issues.apache.org/jira/browse/VELOCITY-12 Project: Velocity Issue Type: Improvement Components: Engine Affects Versions: 1.1 Environment: Operating System: All Platform: PC Reporter: Rich Doyle Priority: Minor It would be nice if I could reference public instance variables in a class that is put in the velocity context using a syntax such as $theClass.instanceVarName. I am aware that this syntax is used to reference the getInstanceVarName() method of the class that is put in the context...maybe a variation on the syntax could be used for instance variables. I am also aware that it is probably not good to expose instance variables as public, however the classes I am dealing with are generated via a CORBA IDL compiler. My servlet makes a CORBA call, which returns data in such an object (public instance vars, no accessor methods), and it would be nice if I could stuff this object into the velocity context and reference it directly in a template. What I have to do with the current implementation of velocity is wrap these IDL compiler generated classes to provide get methods for the instance variables. This is very easy, but adds up to a lot of classes that exist merely so public members can be accessed via a get method. bootlickingon I evaluated velocity as an alternative to JSP for use on my current project, and Velocity wins hands down, even given this inconvenience./bootlickingoff -- 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] [Reopened] (VELOCITY-12) Access to public member variable of a class
[ https://issues.apache.org/jira/browse/VELOCITY-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Bubna reopened VELOCITY-12: -- Access to public member variable of a class --- Key: VELOCITY-12 URL: https://issues.apache.org/jira/browse/VELOCITY-12 Project: Velocity Issue Type: Improvement Components: Engine Affects Versions: 1.1 Environment: Operating System: All Platform: PC Reporter: Rich Doyle Priority: Minor It would be nice if I could reference public instance variables in a class that is put in the velocity context using a syntax such as $theClass.instanceVarName. I am aware that this syntax is used to reference the getInstanceVarName() method of the class that is put in the context...maybe a variation on the syntax could be used for instance variables. I am also aware that it is probably not good to expose instance variables as public, however the classes I am dealing with are generated via a CORBA IDL compiler. My servlet makes a CORBA call, which returns data in such an object (public instance vars, no accessor methods), and it would be nice if I could stuff this object into the velocity context and reference it directly in a template. What I have to do with the current implementation of velocity is wrap these IDL compiler generated classes to provide get methods for the instance variables. This is very easy, but adds up to a lot of classes that exist merely so public members can be accessed via a get method. bootlickingon I evaluated velocity as an alternative to JSP for use on my current project, and Velocity wins hands down, even given this inconvenience./bootlickingoff -- 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-139) Bundle a NullTool in velocity Tools
[
https://issues.apache.org/jira/browse/VELTOOLS-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13014055#comment-13014055
]
Nathan Bubna commented on VELTOOLS-139:
---
Not just any undefined variable. Use $NULL or $null. If someone with access
to the context is putting in a non-null value with NULL or null as the key,
you have problems. In fact, my primary objection to the NullTool is the
implied/suggested key of $null. Terrible idea! Maybe an isNull(Object) method
could easily be added to the ContextTool (which does have a
$context.contains('var') method that is very close). But personally, i think
#if( $var == $null ) is very straightforward and cleaner than
$context.isNull($var).
Bundle a NullTool in velocity Tools
---
Key: VELTOOLS-139
URL: https://issues.apache.org/jira/browse/VELTOOLS-139
Project: Velocity Tools
Issue Type: Wish
Components: GenericTools
Affects Versions: 2.0
Reporter: Vincent Massol
Right now, in order to check for null we have to use:
{code}#if ((! $var) ($!var == )){code}
which is painful when you have lots of checks to do in several places.
It would be nice either to have better null check support in velocity core or
to bundle to NullTool in Velocity Tools:
http://wiki.apache.org/velocity/NullTool
I checked the user guide and googled around and couldn't find any simple way
to check for null except using an undefined variable which I find way too
magical and dangerous (what if someone defines that variable in the context).
--
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-12) Access to public member variable of a class
[ https://issues.apache.org/jira/browse/VELOCITY-12?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13013762#comment-13013762 ] Nathan Bubna commented on VELOCITY-12: -- Yeah, please attach the patch to this issue, so we can use it without license concerns. Personally, i'm not very opposed to the idea anymore. Of course, i don't need it and won't use it, as i do still see cases where java devs might want something to be public but not accessible in a template, but i also think it should be easier to override that default than it is. I think it makes sense to ship an Uberspect impl that supports this, so it is just a property change away for users that want it. Access to public member variable of a class --- Key: VELOCITY-12 URL: https://issues.apache.org/jira/browse/VELOCITY-12 Project: Velocity Issue Type: Improvement Components: Engine Affects Versions: 1.1 Environment: Operating System: All Platform: PC Reporter: Rich Doyle Priority: Minor It would be nice if I could reference public instance variables in a class that is put in the velocity context using a syntax such as $theClass.instanceVarName. I am aware that this syntax is used to reference the getInstanceVarName() method of the class that is put in the context...maybe a variation on the syntax could be used for instance variables. I am also aware that it is probably not good to expose instance variables as public, however the classes I am dealing with are generated via a CORBA IDL compiler. My servlet makes a CORBA call, which returns data in such an object (public instance vars, no accessor methods), and it would be nice if I could stuff this object into the velocity context and reference it directly in a template. What I have to do with the current implementation of velocity is wrap these IDL compiler generated classes to provide get methods for the instance variables. This is very easy, but adds up to a lot of classes that exist merely so public members can be accessed via a get method. bootlickingon I evaluated velocity as an alternative to JSP for use on my current project, and Velocity wins hands down, even given this inconvenience./bootlickingoff -- 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] Resolved: (VELOCITY-796) Velocity #parse not parsing content.
[ https://issues.apache.org/jira/browse/VELOCITY-796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Bubna resolved VELOCITY-796. --- Resolution: Duplicate It's definitely not #parse that's the problem, if some of the content is parsed. And since it's a spotty occurence and your screenshot shows that all the unparsed output is macro calls, Sergiu is right on. It's a race condition in the local macro namespace. See VELOCITY-776 for full explanation and the options available to you for working around it until we get a proper fix. 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-796) Velocity #parse not parsing content.
[ https://issues.apache.org/jira/browse/VELOCITY-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12988141#action_12988141 ] Nathan Bubna commented on VELOCITY-796: --- In case it isn't clear from my last comment on VELOCITY-776... Your options are: a) turn on caching for your templates (big performance boost anyway) b) stop using inline macros, make them global 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-795) Velocity.evaluate String - ParseErrorException: Encountered EOF
[ https://issues.apache.org/jira/browse/VELOCITY-795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12986470#action_12986470 ] Nathan Bubna commented on VELOCITY-795: --- I've been running it as a String this whole time, though with \n at the end of lines. I just tried it without the \n's (so it's all on one line, like your code would have it) and it still worked fine for me. Can you attach a zip of your little VelocityTest application, jars and all, to make sure one of us isn't just miscopying some of the text? Velocity.evaluate String - ParseErrorException: Encountered EOF Key: VELOCITY-795 URL: https://issues.apache.org/jira/browse/VELOCITY-795 Project: Velocity Issue Type: Bug Affects Versions: 1.7 Environment: Mac OSX, Java 1.5, Velocity 1.7 Reporter: Becky Cartine When I include an #if statement twice in a velocity template, I get a ParseErrorException. If I remove the first occurance of the #if statement below, there are no errors. html body some text here #if ($message) Message: #end some more text #if ($message) Message: #end /body /html -- 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] Closed: (VELOCITY-795) Velocity.evaluate String - ParseErrorException: Encountered EOF
[ https://issues.apache.org/jira/browse/VELOCITY-795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Bubna closed VELOCITY-795. - Velocity.evaluate String - ParseErrorException: Encountered EOF Key: VELOCITY-795 URL: https://issues.apache.org/jira/browse/VELOCITY-795 Project: Velocity Issue Type: Bug Affects Versions: 1.7 Environment: Mac OSX, Java 1.5, Velocity 1.7 Reporter: Becky Cartine Attachments: test-velocity.zip When I include an #if statement twice in a velocity template, I get a ParseErrorException. If I remove the first occurance of the #if statement below, there are no errors. html body some text here #if ($message) Message: #end some more text #if ($message) Message: #end /body /html -- 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] Closed: (VELOCITY-795) Multiple #if statements causes ParseErrorException: Encountered EOF
[ https://issues.apache.org/jira/browse/VELOCITY-795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Bubna closed VELOCITY-795. - Multiple #if statements causes ParseErrorException: Encountered EOF Key: VELOCITY-795 URL: https://issues.apache.org/jira/browse/VELOCITY-795 Project: Velocity Issue Type: Bug Environment: Mac OSX, Java 1.5, Velocity 1.4 Reporter: Becky Cartine When I include an #if statement twice in a velocity template, I get a ParseErrorException. If I remove the first occurance of the #if statement below, there are no errors. html body some text here #if ($message) Message: #end some more text #if ($message) Message: #end /body /html -- 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] Resolved: (VELOCITY-795) Multiple #if statements causes ParseErrorException: Encountered EOF
[ https://issues.apache.org/jira/browse/VELOCITY-795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Bubna resolved VELOCITY-795. --- Resolution: Invalid Velocity 1.4 is no longer receiving fixes. Please upgrade to a modern version. If you cannot upgrade, please consult the mailing list at u...@velocity.apache.org for help in figuring out the cause of the error and fixes/workarounds that you are able to use. Multiple #if statements causes ParseErrorException: Encountered EOF Key: VELOCITY-795 URL: https://issues.apache.org/jira/browse/VELOCITY-795 Project: Velocity Issue Type: Bug Environment: Mac OSX, Java 1.5, Velocity 1.4 Reporter: Becky Cartine When I include an #if statement twice in a velocity template, I get a ParseErrorException. If I remove the first occurance of the #if statement below, there are no errors. html body some text here #if ($message) Message: #end some more text #if ($message) Message: #end /body /html -- 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-795) Multiple #if statements causes ParseErrorException: Encountered EOF
[ https://issues.apache.org/jira/browse/VELOCITY-795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12986042#action_12986042 ] Nathan Bubna commented on VELOCITY-795: --- That template parses fine for me. If you are sure this is a bug and not a problem with your own use of Velocity, then can you submit a failing testcase or runnable example app to demonstrate it? That template alone was not sufficient for me to replicate the problem, since it works fine for me. If you think this may be a problem with your template(s) rather than Velocity itself, please take the question to the u...@velocity.apache.org list. Then we can help you there where the problem and solution will be more easily discoverable for future users with the same problem. If it helps you to decide which way to pursue, it is generally recommended that people take problems like this to the mailing list first, as that forum is larger. Then, if it is clear that the problem is a bug in Velocity itself, it can be moved to the issue tracker. Also, it is extremely unlikely that two #if statements is the cause of the problem, as that is an extremely common occurence, even in our own internal cases. Best to withhold conclusions about the root issue until it's confirmed by a 2nd party. Multiple #if statements causes ParseErrorException: Encountered EOF Key: VELOCITY-795 URL: https://issues.apache.org/jira/browse/VELOCITY-795 Project: Velocity Issue Type: Bug Environment: Mac OSX, Java 1.5, Velocity 1.4 Reporter: Becky Cartine When I include an #if statement twice in a velocity template, I get a ParseErrorException. If I remove the first occurance of the #if statement below, there are no errors. html body some text here #if ($message) Message: #end some more text #if ($message) Message: #end /body /html -- 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: (VELTOOLS-102) Add capabilities to simplify handling of complex HTML tables
[ https://issues.apache.org/jira/browse/VELTOOLS-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12980554#action_12980554 ] Nathan Bubna commented on VELTOOLS-102: --- This is one of those things that had potential, but no one (e.g. me) ever made time to clean it up and fit it in. Probably best living elsewhere at this point, as there also hasn't been much in the way of demand. And with DisplayTag support now... Add capabilities to simplify handling of complex HTML tables Key: VELTOOLS-102 URL: https://issues.apache.org/jira/browse/VELTOOLS-102 Project: Velocity Tools Issue Type: New Feature Components: GenericTools Environment: No specific requirements on the environment are known Reporter: Matthias Laux Fix For: 2.x Attachments: htmltable.zip Original Estimate: 0.02h Remaining Estimate: 0.02h This is a feature request for a tool that simplifies the handling of complex HTML using Velocity. The basic idea is to take the pain out of using complex hierarchies of Velocity macros to place HTML tags such as tr and td in the right places for tables with non-trivial structures (using e. g. colspan and rowspan). This is made possible by handling the logical table data structure in Java code and by using a dedicated Table class to communicate information in between the Java application and the Velocity context. A short discussion thread can be found in the forum using this link: http://velocity.markmail.org/search/?q=table+cell+laux#query:table%20cell%20laux+page:1+mid:du3pucnapp6ezbzp+state:results Based on that initial contact, follow-up discussions with Nathan Bubna took place over the last few months. Effectively, a 1.0 version of this tool was already built by Matthias Laux, the submitter of this reature request issue. The sources will be attached. Additional information on what the tool does and what the code actually looks like can also be found in this article: http://www.javaworld.com/javaworld/jw-01-2008/jw-01-htmltables.html Remaining work needs to be done for example on implementing unit tests. The effort estimate relates to these. -- 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-793) Change ResourceLoader.getResourceStream to getResourceReader
[ https://issues.apache.org/jira/browse/VELOCITY-793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12978900#action_12978900 ] Nathan Bubna commented on VELOCITY-793: --- I agree we should move to Readers in 2.0. It is, however, only a serious change to the API for advanced users, not template writers. Providing B.C. support would be nice, but is certainly not required nor even expected. Change ResourceLoader.getResourceStream to getResourceReader Key: VELOCITY-793 URL: https://issues.apache.org/jira/browse/VELOCITY-793 Project: Velocity Issue Type: Wish Components: Engine Reporter: Christopher Schultz Fix For: 2.x It would be nice to use Readers instead of InputStreams for templates. Velocity is all about text-based rendering, so the templates are certainly going to be text-based. Using a Reader allows individual readers to determine the character encoding if necessary (say, from a database) and not have another component second-guess them. Of course, this is a serious change to the API. We could possible re-implement getResourceStream to read a Reader and provide bytes as backward-compatibility with older client code, but since we're going to 2.0, this would be the time to make breaking changes to the API. -- 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=12975681#action_12975681 ] Nathan Bubna commented on VELOCITY-692: --- No, the order should be about frequency of types, not closeness in meaning to each other. And for that very reason, i've revamped the order (see below). As for 0, i've struggled with that because i know many people might expect 0 to be treated as it is in javascript. However, this is not a scripting language but a display language, and 0 is often a very important thing to display. My inclination is to leave it as non-empty for now. Besides, checking to see if a number is zero takes more processing than you'd think. Anyway, here's the order i am implementing for now... #if( $obj ) will be false if: $obj is null $obj is boolean false $obj returns false from getAsBoolean() $obj is empty string (CharSequence w/length 0) $obj returns true from isEmpty() $obj is array of length 0 $obj returns null from getAsString() $obj returns empty string from getAsString() $obj returns null from getAsNumber() $obj returns 0 from length() or size() $obj returns empty string from toString() Type-wise, this prioritizes those most likely to be used in #if( $obj) (by my completely subjective experience), as such: booleans, strings, maps/collections, and arrays. then it gives getAsString(), getAsNumber(), length() and size() all opportunities, falling back on toString() as the last resort. So, if you have a custom object likely to end up alone in an #if directive, you'll get the best performance by implementing a getAsBoolean() method, or at least, isEmpty(). Also, i might add that organizing things this way and considering the various types likely to end up in #if, the length()/size() testing feels a bit unnecessary. What do you guys think? 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] Resolved: (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:all-tabpanel ] Nathan Bubna resolved VELOCITY-692. --- Resolution: Fixed Fix Version/s: 2.0 Ok, the code is in. And i did drop support for length() and size(), since i really can't see that being used or even very useful. 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 Fix For: 2.0 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-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=12975337#action_12975337 ] Nathan Bubna commented on VELOCITY-692: --- So, i'm still of the opinion that having empty values be treated as false by #if( $foo ) is a good idea. so i thought i'd restart this conversation by reminding people that VTL is a display language; it is not meant to be a full scripting language. so, while an empty array or empty map may not be falsey to a script, the lack of anything in the array or map to display makes it quite falsey to a display language, no? So, to recap, i propose that we change #if in 2.0 to treat the following values as false: $obj that is null $obj that is boolean false $obj that returns false from a getAsBoolean method $obj that is empty string $obj that is empty array $obj that returns true from an isEmpty() method (i.e. Collection and Map implementations) $obj that returns null or empty string from a getAsString method $obj that returns 0 from a length() or size() method $obj that returns empty string from toString() method i also propose that the order above be the order in which things are checked. This means that while we will still check toString(), it will not ever be called on any maps or lists or any object that bothers to implement a getAsBoolean, getAsString or isEmpty() method. Again to be more clear, if the object has a getAsBoolean(), isEmpty(), getAsString(), length(), or size() method, then we don't keep looking further. Once we find one of these methods, we return false if the result is falsey or true otherwise. This makes it easy for users to avoid expensive calls to toString() or even getAsString(). For those who want to distinguish between false and falsey or null and empty, they will have to use #if( $obj == $null ) or #if( $obj == false ) to be explicit about what they want to know. So, there is no loss of functionality involved here. It is merely a change to make empty values be treated as false by #if( $foo ) calls and simultaneously make it easy to avoid expensive toString() calls when using #if to test references. Thoughts, tirades, minor objections? p.s. the getAsString and getAsBoolean support will probably be checked in this evening. 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] Updated: (VELOCITY-786) NullPointerException while evaluating template
[
https://issues.apache.org/jira/browse/VELOCITY-786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Bubna updated VELOCITY-786:
--
Fix Version/s: (was: 1.6.4)
2.0
1.7
In 1.6, LogManager wasn't catching UnsupportedOperationExceptions from trying
to use ServletLogChute when servlet classes were available but the
servletContext was not in the application attributes. This was fixed in 1.7
and following.
NullPointerException while evaluating template
--
Key: VELOCITY-786
URL: https://issues.apache.org/jira/browse/VELOCITY-786
Project: Velocity
Issue Type: Bug
Components: Engine
Affects Versions: 1.6.4
Environment: FreeBSD 8.0, Java(TM) SE Runtime Environment (build
1.6.0_03-p4-root_19_oct_2010_22_21-b00), Apache Tomcat/6.0.29, Spring 2.5
Reporter: Pawel Urban
Fix For: 1.7, 2.0
While evaluating template with Velocity I am affecting:
java.lang.NullPointerException
org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1103)
org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1086)
org.apache.velocity.runtime.RuntimeInstance.evaluate(RuntimeInstance.java:1199)
org.apache.velocity.runtime.RuntimeInstance.evaluate(RuntimeInstance.java:1165)
org.apache.velocity.app.Velocity.evaluate(Velocity.java:191)
pl.pollub.cafe.zeusx.modules.report.ReportController.generateWorkersSchedule(ReportController.java:300)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.springframework.web.bind.annotation.support.HandlerMethodInvoker.doInvokeMethod(HandlerMethodInvoker.java:421)
org.springframework.web.bind.annotation.support.HandlerMethodInvoker.invokeHandlerMethod(HandlerMethodInvoker.java:136)
org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.invokeHandlerMethod(AnnotationMethodHandlerAdapter.java:326)
org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.handle(AnnotationMethodHandlerAdapter.java:313)
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:875)
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:807)
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571)
org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:511)
javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
pl.pollub.cafe.zeusx.commons.spring.FlashScopeFilter.doFilterInternal(FlashScopeFilter.java:33)
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:96)
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
exception.
Code which is being executed:
try {
Velocity.init();
} catch (Exception e1) {
e1.printStackTrace();
}
then
try {
Velocity.evaluate( context, writer, string,
template.getSzablon());
} catch (ParseErrorException e) {
e.printStackTrace();
} catch (MethodInvocationException e) {
e.printStackTrace();
} catch (ResourceNotFoundException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}
This code does not on production server, but works on development machines. I
have tried using VelocityEngine instetad of Velocity Signleton but no luck.
I also tried initializing Velocity during servlet startup but nothing
changed. Any help appreciated :-)
--
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] Resolved: (VELOCITY-786) NullPointerException while evaluating template
[
https://issues.apache.org/jira/browse/VELOCITY-786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Bubna resolved VELOCITY-786.
---
Resolution: Fixed
Resolving since it was, indeed, fixed.
NullPointerException while evaluating template
--
Key: VELOCITY-786
URL: https://issues.apache.org/jira/browse/VELOCITY-786
Project: Velocity
Issue Type: Bug
Components: Engine
Affects Versions: 1.6.4
Environment: FreeBSD 8.0, Java(TM) SE Runtime Environment (build
1.6.0_03-p4-root_19_oct_2010_22_21-b00), Apache Tomcat/6.0.29, Spring 2.5
Reporter: Pawel Urban
Fix For: 1.7, 2.0
While evaluating template with Velocity I am affecting:
java.lang.NullPointerException
org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1103)
org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1086)
org.apache.velocity.runtime.RuntimeInstance.evaluate(RuntimeInstance.java:1199)
org.apache.velocity.runtime.RuntimeInstance.evaluate(RuntimeInstance.java:1165)
org.apache.velocity.app.Velocity.evaluate(Velocity.java:191)
pl.pollub.cafe.zeusx.modules.report.ReportController.generateWorkersSchedule(ReportController.java:300)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.springframework.web.bind.annotation.support.HandlerMethodInvoker.doInvokeMethod(HandlerMethodInvoker.java:421)
org.springframework.web.bind.annotation.support.HandlerMethodInvoker.invokeHandlerMethod(HandlerMethodInvoker.java:136)
org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.invokeHandlerMethod(AnnotationMethodHandlerAdapter.java:326)
org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.handle(AnnotationMethodHandlerAdapter.java:313)
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:875)
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:807)
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571)
org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:511)
javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
pl.pollub.cafe.zeusx.commons.spring.FlashScopeFilter.doFilterInternal(FlashScopeFilter.java:33)
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:96)
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
exception.
Code which is being executed:
try {
Velocity.init();
} catch (Exception e1) {
e1.printStackTrace();
}
then
try {
Velocity.evaluate( context, writer, string,
template.getSzablon());
} catch (ParseErrorException e) {
e.printStackTrace();
} catch (MethodInvocationException e) {
e.printStackTrace();
} catch (ResourceNotFoundException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}
This code does not on production server, but works on development machines. I
have tried using VelocityEngine instetad of Velocity Signleton but no luck.
I also tried initializing Velocity during servlet startup but nothing
changed. Any help appreciated :-)
--
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-790) Improve configuration facility
[ https://issues.apache.org/jira/browse/VELOCITY-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970314#action_12970314 ] Nathan Bubna commented on VELOCITY-790: --- Yeah, no null booleans in config, please. And the only type conversion in Velocity internals is toString(), i believe. Improve configuration facility -- Key: VELOCITY-790 URL: https://issues.apache.org/jira/browse/VELOCITY-790 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 2.0 Reporter: Antonio Petrelli Assignee: Adrian Tarau Fix For: 2.0 Currently the whole configuration of Velocity Engine is managed by ExtendedProperties, a class from Commons Collections. An interface that abstracts from this implementation, and an implementation that uses normal Properties should be used. -- 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-790) Improve configuration facility
[ https://issues.apache.org/jira/browse/VELOCITY-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12969199#action_12969199 ] Nathan Bubna commented on VELOCITY-790: --- What's the benefit of having all those converters? Improve configuration facility -- Key: VELOCITY-790 URL: https://issues.apache.org/jira/browse/VELOCITY-790 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 2.0 Reporter: Antonio Petrelli Assignee: Adrian Tarau Fix For: 2.0 Currently the whole configuration of Velocity Engine is managed by ExtendedProperties, a class from Commons Collections. An interface that abstracts from this implementation, and an implementation that uses normal Properties should be used. -- 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-789) Reorganize dependencies in Velocity Engine Core
[ https://issues.apache.org/jira/browse/VELOCITY-789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12966977#action_12966977 ] Nathan Bubna commented on VELOCITY-789: --- Why not shade? At least with shading we can get updates and pass off bug reports more easily, right? Reorganize dependencies in Velocity Engine Core --- Key: VELOCITY-789 URL: https://issues.apache.org/jira/browse/VELOCITY-789 Project: Velocity Issue Type: Bug Reporter: Antonio Petrelli Assignee: Antonio Petrelli Currently Velocity Engine core depends on: Commons Lang Commons Collections Avalon LogKit Apache Jakarta ORO LogKit and ORO should be removed, as they are obsolete. Commons Lang and Collections should be replaced or shaded. -- 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-790) Improve configuration facility
[ https://issues.apache.org/jira/browse/VELOCITY-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12966984#action_12966984 ] Nathan Bubna commented on VELOCITY-790: --- I prefer org.apache.velocity.configuration. I have to constantly fight the urge to abolish both the o.a.v.app and o.a.v.runtime packages. Too many of the packages under o.a.v. are unnecessary, IMO. Improve configuration facility -- Key: VELOCITY-790 URL: https://issues.apache.org/jira/browse/VELOCITY-790 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 2.0 Reporter: Antonio Petrelli Assignee: Adrian Tarau Fix For: 2.0 Currently the whole configuration of Velocity Engine is managed by ExtendedProperties, a class from Commons Collections. An interface that abstracts from this implementation, and an implementation that uses normal Properties should be used. -- 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-790) Improve configuration facility
[ https://issues.apache.org/jira/browse/VELOCITY-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12966990#action_12966990 ] Nathan Bubna commented on VELOCITY-790: --- Yeah, but is it worth it at this point? Improve configuration facility -- Key: VELOCITY-790 URL: https://issues.apache.org/jira/browse/VELOCITY-790 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 2.0 Reporter: Antonio Petrelli Assignee: Adrian Tarau Fix For: 2.0 Currently the whole configuration of Velocity Engine is managed by ExtendedProperties, a class from Commons Collections. An interface that abstracts from this implementation, and an implementation that uses normal Properties should be used. -- 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-790) Improve configuration facility
[ https://issues.apache.org/jira/browse/VELOCITY-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12967098#action_12967098 ] Nathan Bubna commented on VELOCITY-790: --- No need for them with regard to configuration. Improve configuration facility -- Key: VELOCITY-790 URL: https://issues.apache.org/jira/browse/VELOCITY-790 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 2.0 Reporter: Antonio Petrelli Assignee: Adrian Tarau Fix For: 2.0 Currently the whole configuration of Velocity Engine is managed by ExtendedProperties, a class from Commons Collections. An interface that abstracts from this implementation, and an implementation that uses normal Properties should be used. -- 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-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:all-tabpanel ] Nathan Bubna updated VELOCITY-553: -- Fix Version/s: (was: 1.7) 2.0 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.0 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 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-599) DataSourceResourceLoader doesn't support UTF8
[ https://issues.apache.org/jira/browse/VELOCITY-599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Bubna updated VELOCITY-599: -- Fix Version/s: (was: 1.7) 2.0 DataSourceResourceLoader doesn't support UTF8 - Key: VELOCITY-599 URL: https://issues.apache.org/jira/browse/VELOCITY-599 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.5 Environment: WindowsServer2003 R2, Oracle10g(10.2.0,UTF8characterSet), jdk1.5.0_12 Reporter: markchen Fix For: 2.0 If templates are stored in the database instead of files,the characters retrived becomes garbled. -- 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-678) Bad parsing of macro
[ https://issues.apache.org/jira/browse/VELOCITY-678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Bubna updated VELOCITY-678: -- Fix Version/s: (was: 1.7) 2.0 Bad parsing of macro Key: VELOCITY-678 URL: https://issues.apache.org/jira/browse/VELOCITY-678 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.6.1, 1.7 Reporter: Byron Foster Priority: Minor Fix For: 2.0 The following: #macro(foo)bar#end $#foo() results in: $#foo() but should be: $bar The problem is that the macro name is getting hosed.. strict mode reveals the following error: Macro '##foo' is not defined at /foo.vm[line 9, column 1] -- 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-679) Escaping #set(foo=bar)\\$$foo broken
[ https://issues.apache.org/jira/browse/VELOCITY-679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Bubna updated VELOCITY-679: -- Fix Version/s: (was: 1.7) 2.0 Escaping #set(foo=bar)\\$$foo broken -- Key: VELOCITY-679 URL: https://issues.apache.org/jira/browse/VELOCITY-679 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.6.1, 1.7 Reporter: Byron Foster Priority: Trivial Fix For: 2.0 The following VTL #set($foo=bar)\\$$foo results in: \$bar but should be: \\$bar -- 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-787) Write to multiple files, controlled by template directives
[
https://issues.apache.org/jira/browse/VELOCITY-787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12928617#action_12928617
]
Nathan Bubna commented on VELOCITY-787:
---
I think this is out of scope for the Engine project, and perhaps Velocity in
general. And i think you could support this now with a clever tool instead of
Directives, and with no need to modify Velocity.
public class WriterTool {
public void switchToWriter(String name)...
public void setFilename(String name)...
public void whateverMagicYouCanThinkUp()...
}
Then you give this tool the info it needs, drop that instance into your context
and viola! You have all the control you want from within the template.
Write to multiple files, controlled by template directives
--
Key: VELOCITY-787
URL: https://issues.apache.org/jira/browse/VELOCITY-787
Project: Velocity
Issue Type: New Feature
Components: Engine
Affects Versions: 2.0
Environment: All environments
Reporter: Don Mendelson
For some purposes, such as code generation, it would be very desirable to
output to multiple files from the same context. For example, to generate code
for a C++ class, two files must be generated - a header and implementation
file. Rendering could be driven by the same context in both cases, which
would desribe the class name, method signatures, etc. Currently this must be
done by running the engine twice - once with a header template and again with
an implementation file template.
Furthermore, it would desirable to determine the output file names during
rendering, based on a combination of template directives and data in the
context. To use the code generation example, the header and implementation
file names would be determined by the name of the class to be generated.
This is not possible with the current method signature of Directive:
public boolean render(InternalContextAdapter context, Writer writer, Node
node)
An output directive would want to change the writer to a different instance
of FileWriter, for instance. But since Java passes object references by
value, the writer object cannot be replaced.
The proposal is to provide a method to install a new instance of Writer
during rendering of a template. This would support both writing multiple
outputs in one run of the engine as well as controlling the file names of the
outputs.
--
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] Resolved: (VELTOOLS-130) ViewToolManager constructor ViewToolManager(servletContext) throws NPE always
[ https://issues.apache.org/jira/browse/VELTOOLS-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Bubna resolved VELTOOLS-130. --- Resolution: Fixed Fix Version/s: 2.x 2.0.x Nice catch. I'm sorry to admit, i've never tried ViewToolManager with autoconfig as true. I just committed a fix. You can build from the trunk or wait for the next release. And no, i don't know when that will be. :) ViewToolManager constructor ViewToolManager(servletContext) throws NPE always - Key: VELTOOLS-130 URL: https://issues.apache.org/jira/browse/VELTOOLS-130 Project: Velocity Tools Issue Type: Bug Components: VelocityView Affects Versions: 2.0 Environment: Ubuntu 10.10, JDK 1.6.21, Tomcat 6.0.20 Reporter: Robert Brandner Priority: Minor Fix For: 2.0.x, 2.x Invoking the constructor ViewToolManager(servletContext) always fails with an NPE. The reason for this is, that it invokes super(true, true) before setting the member variable servletContext with the provided servletContext. The parent class' constructor invokes autoConfigure(true) which invokes ServletUtils.getConfiguration(servletPath). At this moment servletPath can only be null as it is not set yet. And that finally leads to a NPE in the first line of the getConfiguration method: Object obj = application.getAttribute(CONFIGURATION_KEY); Workaround: Use a constructor without autoconfiguration and invoke autoConfigure(true) afterwards. ViewToolManager vm = new ViewToolmanager(servletContext, false, false); vm.autoConfigure(true); -- 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
]
Nathan Bubna updated VELOCITY-681:
--
Comment: was deleted
(was: [flights|http://getflightsto.com]
[baby names|http://childcareforums.com]
)
[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] Updated: (VELOCITY-701) migrating from 1.4 to 1.6.1 iteration over a List no longer works
[
https://issues.apache.org/jira/browse/VELOCITY-701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Bubna updated VELOCITY-701:
--
Comment: was deleted
(was: [flights|http://getflightsto.com]
[baby names|http://childcareforums.com]
)
migrating from 1.4 to 1.6.1 iteration over a List no longer works
-
Key: VELOCITY-701
URL: https://issues.apache.org/jira/browse/VELOCITY-701
Project: Velocity
Issue Type: Bug
Components: Engine
Affects Versions: 1.6.1
Environment: Linux, Sun Java 1.5
Reporter: chad davis
Fix For: 1.6.2, 1.7, 2.0
I have a template that references a List returned by a method on an Enum.
The method is defined as an abstract member of the enum. This used to work
on 1.4, but doesn't work on 1.6.1 I'm able to get it to work on 1.6.1 by
changing the abstract method to a regular method of the Enum, which is then
overridden by each instance of the enum. Here's the code that doesn't work.
Again, it seems to be the abstract modifier, becuase if I change that method
to something like
public List getMyList() { return new ArrayList(); }
And then just override it in my enum instances, everything works fine.
public enum Thing {
NUMBER_ONE( ){
public ListString getInnerThings() {
//initialize innerThings if this is first time
if ( this.innerThings == null ) {
innerThings = new ArrayListString();
innerThings.add( blah blah );
innerThings.add(blah blah );
}
return innerThings;
}
},
NUMBER_TWO( ){
public ListString getinnerThings() {
//initialize innerThings if this is first time
if ( this.innerThings == null ) {
innerThings = new ArrayListString();
innerThings.add( blah blah );
innerThings.add(blah blah );
}
return innerThings;
}
},
NUMBER_THREE( ){
public ListString getinnerThings() {
if ( this.innerThings == null ) {
innerThings = new ArrayListString();
innerThings.add( blah blah );
innerThings.add(blah blah );
}
return innerThings;
}
};
ListString innerThings;
//This was an abstract method, but Velocity 1.6 quite working with it.
public abstract ListString getinnerThings();
}
--
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] Closed: (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
]
Nathan Bubna closed VELOCITY-681.
-
[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] Closed: (VELOCITY-778) VelocityServlet.loadConfiguration(...) can not resolve propsFile, returns empty Properties
[ https://issues.apache.org/jira/browse/VELOCITY-778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Bubna closed VELOCITY-778. - Yes, suggesting improvements are best done directly through JIRA, otherwise they tend to get misplaced. Thanks. VelocityServlet.loadConfiguration(...) can not resolve propsFile, returns empty Properties -- Key: VELOCITY-778 URL: https://issues.apache.org/jira/browse/VELOCITY-778 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.6.4 Reporter: Rafał Miłecki My web.xml contains following code: context-param param-nameproperties/param-name param-valueWEB-INF/conf/velocity.properties/param-value /context-param I get following exception and backtrace: javax.servlet.ServletException: Error configuring the loader: java.io.FileNotFoundException: WEB-INF/conf/velocity.properties (No such file or directory) org.apache.velocity.servlet.VelocityServlet.init(VelocityServlet.java:213) pl.put.platon.common.PlatonServlet.init(PlatonServlet.java:173) org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859) org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588) org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489) java.lang.Thread.run(Thread.java:636) There is following comment in VelocityServlet code: /* * This will attempt to find the location of the properties * file from the relative path to the WAR archive (ie: * docroot). Since JServ returns null for getRealPath() * because it was never implemented correctly, then we know we * will not have an issue with using it this way. I don't know * if this will break other servlet engines, but it probably * shouldn't since WAR files are the future anyways. */ So the problem is that config.getInitParameter(INIT_PROPS_KEY) returns: WEB-INF/conf/velocity.properties which (path) doesn't work for Properties.load(...) -- 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] Resolved: (VELOCITY-778) VelocityServlet.loadConfiguration(...) can not resolve propsFile, returns empty Properties
[ https://issues.apache.org/jira/browse/VELOCITY-778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Bubna resolved VELOCITY-778. --- Resolution: Won't Fix Sorry, but the VelocityServlet has been officially deprecated for about 4 years now (since 1.5-beta1). It has been inferior to VelocityTools' VelocityViewServlet (it's replacement) for much longer than that. It has numerous shortcomings and none of them will be fixed. In fact, nothing will be done to support new development with it, and issues like this make me want to yank it out of the upcoming 1.7 too. Or at least add some large and annoying documentation and log warnings to make sure people don't miss that it is deprecated. Please do pull down VelocityViewServlet (preferrably from VelocityTools 2.0) and use that. It has no issues with /WEB-INF paths, as it gets the InputStream directly from the ServletContext. And next time, post questions on the user list before creating JIRA issues, otherwise i'm liable to continue earning a reputation as a grumpy developer. :) VelocityServlet.loadConfiguration(...) can not resolve propsFile, returns empty Properties -- Key: VELOCITY-778 URL: https://issues.apache.org/jira/browse/VELOCITY-778 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.6.4 Reporter: Rafał Miłecki My web.xml contains following code: context-param param-nameproperties/param-name param-valueWEB-INF/conf/velocity.properties/param-value /context-param I get following exception and backtrace: javax.servlet.ServletException: Error configuring the loader: java.io.FileNotFoundException: WEB-INF/conf/velocity.properties (No such file or directory) org.apache.velocity.servlet.VelocityServlet.init(VelocityServlet.java:213) pl.put.platon.common.PlatonServlet.init(PlatonServlet.java:173) org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859) org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588) org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489) java.lang.Thread.run(Thread.java:636) There is following comment in VelocityServlet code: /* * This will attempt to find the location of the properties * file from the relative path to the WAR archive (ie: * docroot). Since JServ returns null for getRealPath() * because it was never implemented correctly, then we know we * will not have an issue with using it this way. I don't know * if this will break other servlet engines, but it probably * shouldn't since WAR files are the future anyways. */ So the problem is that config.getInitParameter(INIT_PROPS_KEY) returns: WEB-INF/conf/velocity.properties which (path) doesn't work for Properties.load(...) -- 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-761) Can not reference a property declared in a super-interface and implemented in a non-public class
[
https://issues.apache.org/jira/browse/VELOCITY-761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12905558#action_12905558
]
Nathan Bubna commented on VELOCITY-761:
---
Wait, i missed something. What parts of a non-public class does Velocity make
accessible? It should not do that, as far as i can tell. The goal has always
been only public methods declared in public classes.
Can not reference a property declared in a super-interface and implemented in
a non-public class
Key: VELOCITY-761
URL: https://issues.apache.org/jira/browse/VELOCITY-761
Project: Velocity
Issue Type: Bug
Components: Engine
Affects Versions: 1.6.3
Reporter: Charles Miller
Consider the following:
public interface MyUser extends java.security.Principal {
String getEmailAddress();
}
class MyUserImpl implements MyUser {
public String getName() { ... }
public String getEmailAddress() { ... }
}
If I put a MyUserImpl in my Velocity context, $user.emailAddress will
resolve, but $user.name will not.
This is a problem with ClassMap#createMethodCache(). It ignores methods
declared on the MyUserImpl class because the class is non-public, and it only
looks up one level in the Interface hierarchy for methods defined on
interfaces: so it will go up as far as the MyUser interface but not as far as
the Principal interface.
--
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-768) Mark optional dependencies as optional in OSGi bundle manifest
[ https://issues.apache.org/jira/browse/VELOCITY-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Bubna updated VELOCITY-768: -- Affects Version/s: (was: 1.7) Mark optional dependencies as optional in OSGi bundle manifest -- Key: VELOCITY-768 URL: https://issues.apache.org/jira/browse/VELOCITY-768 Project: Velocity Issue Type: Improvement Components: Build Affects Versions: 2.0 Reporter: Matt Ryall Fix For: 1.7 Attachments: VELOCITY-768_mark_optional_deps_in_manifest_v1.patch Trying to use the Velocity 1.7-beta1 JAR in our OSGi container (Felix running in Atlassian Confluence), we ran into dependency problems because all the dependencies of Velocity are marked as mandatory. As you would know, Velocity has a logging abstraction which allows different logging frameworks to be used. Likewise, you don't need the servlet API to use Velocity. However, these dependencies are marked as required in the new OSGi manifest added in VELOCITY-694. This causes the bundle to fail to start because the dependencies are missing. From our testing, we could use Velocity in our application just fine with following imports changed to be optional: * com.werken.xpath * javax.servlet * javax.servlet.http * org.apache.commons.logging * org.apache.log * org.apache.log.format * org.apache.log.output.io * org.apache.log4j * org.apache.oro.text.perl * org.apache.tools.ant * org.apache.tools.ant.taskdefs * org.jdom * org.jdom.input * org.jdom.output That means changing the current Import-Package declaration from this: Import-Package: com.werken.xpath, javax.naming, javax.servlet, javax.servlet.http, javax.sql, org.apache.commons.collections, org.apache.commons.collections.map, org.apache.commons.lang, org.apache.commons.lang.builder, org.apache.commons.lang.text, org.apache.commons.logging, org.apache.log, org.apache.log.format, org.apache.log.output.io, org.apache.log4j, org.apache.oro.text.perl, org.apache.tools.ant, org.apache.tools.ant.taskdefs, org.jdom, org.jdom.input, org.jdom.output, org.xml.sax to this: Import-Package: com.werken.xpath;resolution:=optional, javax.naming, javax.servlet;resolution:=optional, javax.servlet.http;resolution:=optional, javax.sql, org.apache.commons.collections, org.apache.commons.collections.map, org.apache.commons.lang, org.apache.commons.lang.builder, org.apache.commons.lang.text, org.apache.commons.logging;resolution:=optional, org.apache.log;resolution:=optional, org.apache.log.format;resolution:=optional, org.apache.log.output.io;resolution:=optional, org.apache.log4j;resolution:=optional, org.apache.oro.text.perl;resolution:=optional, org.apache.tools.ant;resolution:=optional, org.apache.tools.ant.taskdefs;resolution:=optional, org.jdom;resolution:=optional, org.jdom.input;resolution:=optional, org.jdom.output;resolution:=optional, org.xml.sax I'll prepare a patch against trunk and attach it shortly. -- 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] Resolved: (VELOCITY-768) Mark optional dependencies as optional in OSGi bundle manifest
[ https://issues.apache.org/jira/browse/VELOCITY-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Bubna resolved VELOCITY-768. --- Resolution: Fixed Fixed in 1.7. 2.0 will probably use Maven to generate the manifest. Mark optional dependencies as optional in OSGi bundle manifest -- Key: VELOCITY-768 URL: https://issues.apache.org/jira/browse/VELOCITY-768 Project: Velocity Issue Type: Improvement Components: Build Affects Versions: 2.0 Reporter: Matt Ryall Fix For: 1.7 Attachments: VELOCITY-768_mark_optional_deps_in_manifest_v1.patch Trying to use the Velocity 1.7-beta1 JAR in our OSGi container (Felix running in Atlassian Confluence), we ran into dependency problems because all the dependencies of Velocity are marked as mandatory. As you would know, Velocity has a logging abstraction which allows different logging frameworks to be used. Likewise, you don't need the servlet API to use Velocity. However, these dependencies are marked as required in the new OSGi manifest added in VELOCITY-694. This causes the bundle to fail to start because the dependencies are missing. From our testing, we could use Velocity in our application just fine with following imports changed to be optional: * com.werken.xpath * javax.servlet * javax.servlet.http * org.apache.commons.logging * org.apache.log * org.apache.log.format * org.apache.log.output.io * org.apache.log4j * org.apache.oro.text.perl * org.apache.tools.ant * org.apache.tools.ant.taskdefs * org.jdom * org.jdom.input * org.jdom.output That means changing the current Import-Package declaration from this: Import-Package: com.werken.xpath, javax.naming, javax.servlet, javax.servlet.http, javax.sql, org.apache.commons.collections, org.apache.commons.collections.map, org.apache.commons.lang, org.apache.commons.lang.builder, org.apache.commons.lang.text, org.apache.commons.logging, org.apache.log, org.apache.log.format, org.apache.log.output.io, org.apache.log4j, org.apache.oro.text.perl, org.apache.tools.ant, org.apache.tools.ant.taskdefs, org.jdom, org.jdom.input, org.jdom.output, org.xml.sax to this: Import-Package: com.werken.xpath;resolution:=optional, javax.naming, javax.servlet;resolution:=optional, javax.servlet.http;resolution:=optional, javax.sql, org.apache.commons.collections, org.apache.commons.collections.map, org.apache.commons.lang, org.apache.commons.lang.builder, org.apache.commons.lang.text, org.apache.commons.logging;resolution:=optional, org.apache.log;resolution:=optional, org.apache.log.format;resolution:=optional, org.apache.log.output.io;resolution:=optional, org.apache.log4j;resolution:=optional, org.apache.oro.text.perl;resolution:=optional, org.apache.tools.ant;resolution:=optional, org.apache.tools.ant.taskdefs;resolution:=optional, org.jdom;resolution:=optional, org.jdom.input;resolution:=optional, org.jdom.output;resolution:=optional, org.xml.sax I'll prepare a patch against trunk and attach it shortly. -- 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] Resolved: (VELOCITY-554) Velocity sources and javadocs missing in the maven repository
[ https://issues.apache.org/jira/browse/VELOCITY-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Bubna resolved VELOCITY-554. --- Resolution: Fixed Appears fixed in 1.6.x, 1.7 and 2.x Velocity sources and javadocs missing in the maven repository - Key: VELOCITY-554 URL: https://issues.apache.org/jira/browse/VELOCITY-554 Project: Velocity Issue Type: New Feature Components: Build Affects Versions: 1.5 Reporter: Aliaksandr Radzivanovich Assignee: Nathan Bubna Fix For: 1.7 Attachments: VELOCITY-554-2.patch, VELOCITY-554-3.patch, VELOCITY-554_download.patch It is really annoying when popular projects like Apache Velocity do not provide their sources and javadocs to the Maven repository. -- 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] Resolved: (VELOCITY-751) CLONE -Remove Exception type throwing.
[ https://issues.apache.org/jira/browse/VELOCITY-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Bubna resolved VELOCITY-751. --- Resolution: Fixed Ok, i think this is about as fixed as we can reasonably make it for the 1.x family, due to backwards compatibility concerns. If you see other places, please correct me. And i've completely fixed this (i think) in 2.0, where we aren't concerned about backwards compatibility. CLONE -Remove Exception type throwing. Key: VELOCITY-751 URL: https://issues.apache.org/jira/browse/VELOCITY-751 Project: Velocity Issue Type: Improvement Components: Engine Affects Versions: 1.6.2 Environment: NA Reporter: Willi Schönborn Fix For: 1.7, 2.0 Attachments: velocity-751-exception-fixes.patch I have to use Checkstyle coding standards at my job. Some methos of Velocity throw exceptions using the raw Exception type. So Checkstyle points an error everywhere I use Velocity and, unfortunately, that's a fact I cannot override in my source code. So it would be nice if those throws Exception are replaced by some Velocity proper exception. -- 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-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-tabpanelfocusedCommentId=12905139#action_12905139 ] Nathan Bubna commented on VELOCITY-553: --- Where are we here? It sounds like Byron had ideas for fixing/using this in 2.0, but no one has stepped up to resolve this for 1.7 (much less 1.6). Since we have strict mode now, is this even worth fixing in 1.7? I'd like to push out a 1.7 final soon. Unless someone steps up soon, this won't happen in 1.7. 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: 1.7 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 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-679) Escaping #set(foo=bar)\\$$foo broken
[ https://issues.apache.org/jira/browse/VELOCITY-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12905145#action_12905145 ] Nathan Bubna commented on VELOCITY-679: --- This seems obscure and difficult to fix (to me ATM). Does anyone actually want to tackle this for 1.7 or shall i postpone it? Escaping #set(foo=bar)\\$$foo broken -- Key: VELOCITY-679 URL: https://issues.apache.org/jira/browse/VELOCITY-679 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.6.1, 1.7 Reporter: Byron Foster Priority: Trivial Fix For: 1.7 The following VTL #set($foo=bar)\\$$foo results in: \$bar but should be: \\$bar -- 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-678) Bad parsing of macro
[ https://issues.apache.org/jira/browse/VELOCITY-678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12905146#action_12905146 ] Nathan Bubna commented on VELOCITY-678: --- Again, this seems obscure and difficult to fix (to me ATM). Anyone want to step and fix this in 1.7 or shall i postpone? Bad parsing of macro Key: VELOCITY-678 URL: https://issues.apache.org/jira/browse/VELOCITY-678 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.6.1, 1.7 Reporter: Byron Foster Priority: Minor Fix For: 1.7 The following: #macro(foo)bar#end $#foo() results in: $#foo() but should be: $bar The problem is that the macro name is getting hosed.. strict mode reveals the following error: Macro '##foo' is not defined at /foo.vm[line 9, column 1] -- 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-599) DataSourceResourceLoader doesn't support UTF8
[ https://issues.apache.org/jira/browse/VELOCITY-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12905151#action_12905151 ] Nathan Bubna commented on VELOCITY-599: --- It appears the HSQLDB 2.0 supports getClob. Anyone want to turn Mark's solution into a patch with a test? Or even just contribute a test? It would be nice to get this into 1.7 But i want to push 1.7 out soon, and the DataSourceResourceLoader is foreign territory to me. DataSourceResourceLoader doesn't support UTF8 - Key: VELOCITY-599 URL: https://issues.apache.org/jira/browse/VELOCITY-599 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.5 Environment: WindowsServer2003 R2, Oracle10g(10.2.0,UTF8characterSet), jdk1.5.0_12 Reporter: markchen Fix For: 1.7 If templates are stored in the database instead of files,the characters retrived becomes garbled. -- 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] Resolved: (VELOCITY-760) DataSourceResourceLoader doesn't close PreparedStatements
[
https://issues.apache.org/jira/browse/VELOCITY-760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Bubna resolved VELOCITY-760.
---
Fix Version/s: 2.0
Resolution: Fixed
DataSourceResourceLoader doesn't close PreparedStatements
-
Key: VELOCITY-760
URL: https://issues.apache.org/jira/browse/VELOCITY-760
Project: Velocity
Issue Type: Bug
Components: Engine
Affects Versions: 1.6.2
Reporter: Jerome Waibel
Fix For: 1.7, 2.0
Attachments: velocity-760.patch
DataSourceResourceLoader.java contains this method:
private ResultSet readData(final Connection conn,
final String columnNames,
final String templateName) throws SQLException
{
PreparedStatement ps = conn.prepareStatement(SELECT + columnNames
+ FROM + tableName + WHERE + keyColumn + = ?);
ps.setString(1, templateName);
return ps.executeQuery();
}
PreparedStatements created in this method never get closed, only the
resultset returned may eventually be closed later which isn't sufficient for
releasing all bound resources. In my project this statement leak lead to the
oracle running out of open cursors (the infamous ORA-01000 error).
--
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-776) velocimacro.permissions.allow.inline.local.scope makes VelocityEngine not threadsafe
[ https://issues.apache.org/jira/browse/VELOCITY-776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12905315#action_12905315 ] Nathan Bubna commented on VELOCITY-776: --- Simon, does this only occur via Velocity.evaluate(...)? Or was this happening with standard template retrieval/rendering too? velocimacro.permissions.allow.inline.local.scope makes VelocityEngine not threadsafe -- Key: VELOCITY-776 URL: https://issues.apache.org/jira/browse/VELOCITY-776 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.6.4 Environment: Sun java jdk1.6.0_21, Ubuntu 10.04 Reporter: Simon Kitching Attachments: RenderVelocityTemplate.java, RenderVelocityTemplateTest.java The attached unit test shows that when velocimacro.permissions.allow.inline.local.scope is set to true, and multiple threads use the same VelocityEngine instance then macros sometimes don't get expanded and the #macroname call remains in the output text. Notes: * running test method testMultipleEvals (single threaded case) always succeeds * running test method testMultiThreadMultipleEvals always fails * commenting out the allow.inline.local.scope line makes the multithread test pass (but of course has other side-effects) Interestingly, for the multithread case it seems that 1 thread always succeeds and N-1 threads fail. -- 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-776) velocimacro.permissions.allow.inline.local.scope makes VelocityEngine not threadsafe
[ https://issues.apache.org/jira/browse/VELOCITY-776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12905321#action_12905321 ] Nathan Bubna commented on VELOCITY-776: --- I ask because the VelocimacroManager uses the log tag parameter given to evaluate(...) as the local namespace key. If i alter your test to iterate the log tag, then the namespace collisions disappear (of course), and your test passes. Granted, i don't yet understand exactly why the VelocimacroManager fails to properly handle multi-threaded addition of macros (the same macro, even) to the same namespace (i haven't had my nose deep in this code in a while). Still, that appears to be the catching point at the moment. velocimacro.permissions.allow.inline.local.scope makes VelocityEngine not threadsafe -- Key: VELOCITY-776 URL: https://issues.apache.org/jira/browse/VELOCITY-776 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.6.4 Environment: Sun java jdk1.6.0_21, Ubuntu 10.04 Reporter: Simon Kitching Attachments: RenderVelocityTemplate.java, RenderVelocityTemplateTest.java The attached unit test shows that when velocimacro.permissions.allow.inline.local.scope is set to true, and multiple threads use the same VelocityEngine instance then macros sometimes don't get expanded and the #macroname call remains in the output text. Notes: * running test method testMultipleEvals (single threaded case) always succeeds * running test method testMultiThreadMultipleEvals always fails * commenting out the allow.inline.local.scope line makes the multithread test pass (but of course has other side-effects) Interestingly, for the multithread case it seems that 1 thread always succeeds and N-1 threads fail. -- 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-776) velocimacro.permissions.allow.inline.local.scope makes VelocityEngine not threadsafe
[ https://issues.apache.org/jira/browse/VELOCITY-776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12905340#action_12905340 ] Nathan Bubna commented on VELOCITY-776: --- No solution yet, but i can replicate it via Velocity.mergeTemplate, by turning caching off on the resource loader (StringResourceLoader in this case). Of course, that's effectively the same as using evaluate(...). Using a resource loader and turning caching on fixes the problem. velocimacro.permissions.allow.inline.local.scope makes VelocityEngine not threadsafe -- Key: VELOCITY-776 URL: https://issues.apache.org/jira/browse/VELOCITY-776 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.6.4 Environment: Sun java jdk1.6.0_21, Ubuntu 10.04 Reporter: Simon Kitching Attachments: RenderVelocityTemplate.java, RenderVelocityTemplateTest.java The attached unit test shows that when velocimacro.permissions.allow.inline.local.scope is set to true, and multiple threads use the same VelocityEngine instance then macros sometimes don't get expanded and the #macroname call remains in the output text. Notes: * running test method testMultipleEvals (single threaded case) always succeeds * running test method testMultiThreadMultipleEvals always fails * commenting out the allow.inline.local.scope line makes the multithread test pass (but of course has other side-effects) Interestingly, for the multithread case it seems that 1 thread always succeeds and N-1 threads fail. -- 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-776) velocimacro.permissions.allow.inline.local.scope makes VelocityEngine not threadsafe
[ https://issues.apache.org/jira/browse/VELOCITY-776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12905371#action_12905371 ] Nathan Bubna commented on VELOCITY-776: --- Ok, RuntimeInstance dumps the vm namespace for a template before parsing it. It does this under the assumption that if you are reparsing the template, it must have changed. If it changed, we shouldn't keep local macros around, as they may no longer exist in the new version. This still seems to me that correct behavior. When rapidly (re)parsing the same template in multiple threads, this means that thread B may dump the namespace newly created and not yet used in rendering by thread A. This unfortunate event can be avoided by permanently caching templates, or greatly reduced in likelihood by caching them with an infrequent modificationCheckInterval. Though, even there it is possible, i think. So, here's the choices i've thought of thus far: 1) leave it and add disclaimers about inline macros when templates aren't permanently cached 2) we can flip the bit and risk memory leakage (and potential interference) from stale macros 3) add another config switch to let users choose between #1 and #2 4) synchronize creatively to prevent simultaneous parsing and/or rendering in the same namespace 5) try to find a way to refactor so inline macros are kept with the template, not managed centrally #5 is more than i can take on right now, and probably won't work for the 1.x branch. maybe in 2.x #4 would probably both wreck performance and never quite work right #3 is tiresome, but probably the best current option #2 would probably only be terrible for people with users creating templates, but could be quite the memory leak for them #1is arguably acceptable for 1.7, but is not a long-term solution thoughts? velocimacro.permissions.allow.inline.local.scope makes VelocityEngine not threadsafe -- Key: VELOCITY-776 URL: https://issues.apache.org/jira/browse/VELOCITY-776 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.6.4 Environment: Sun java jdk1.6.0_21, Ubuntu 10.04 Reporter: Simon Kitching Attachments: RenderVelocityTemplate.java, RenderVelocityTemplateTest.java The attached unit test shows that when velocimacro.permissions.allow.inline.local.scope is set to true, and multiple threads use the same VelocityEngine instance then macros sometimes don't get expanded and the #macroname call remains in the output text. Notes: * running test method testMultipleEvals (single threaded case) always succeeds * running test method testMultiThreadMultipleEvals always fails * commenting out the allow.inline.local.scope line makes the multithread test pass (but of course has other side-effects) Interestingly, for the multithread case it seems that 1 thread always succeeds and N-1 threads fail. -- 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] Resolved: (VELOCITY-771) Error when creation jar-J2EE with ant build.
[ https://issues.apache.org/jira/browse/VELOCITY-771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Bubna resolved VELOCITY-771. --- Resolution: Invalid That book is seven years old, referencing Velocity 1.3. Our build has improved much since. Now you just neeed a JDBC-including jar on the classpath when you build with the ant jar or ant jar-dep targets. Also, you can always try ant -projecthelp to see what targets are available. Next time, just ask on the u...@velocity.apache.org list before filing a bug report. You'll usually get a quicker answer that way. Error when creation jar-J2EE with ant build. Key: VELOCITY-771 URL: https://issues.apache.org/jira/browse/VELOCITY-771 Project: Velocity Issue Type: Bug Affects Versions: 1.6.4 Reporter: Ilia Prizker Can't build J2EE jar for loading templates from database, with command: ant jar-J2EE this is the error: BUILD FAILED Target jar-J2EE does not exist in the project Velocity. == from https://www.hasustorm.com/books/English/John.Wiley.And.Sons.Mastering.Apache.Velocity.eBook-KB.pdf The DataSource resource loader, implemented by Velocity's DataSourceResourceLoader class, obtains its resources via physical data source connections obtained through a Java DataSource object. An obvious example is a case where Velocity templates and related resources are obtained from a relational database. This resource loader uses all of the resource loader properties, except for resource.loader.path. It also supports several other properties that are unique to this type of loader. For more information regarding these properties, see the Velocity's API documentation for its DataSourceResourceLoader class. This resource loader requires J2EE and is not included in the standard Velocity build. jar-J2EE—This build target compiles a complete Velocity JAR just as in the case of the jar build target, but it also includes the J2EE JAR file. The build target requires a copy of j2ee.jar in the /build/lib directory or a link. The command line is: ant jar-J2EE == -- 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-773) Provide locally scoped #set variables
[ https://issues.apache.org/jira/browse/VELOCITY-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12903444#action_12903444 ] Nathan Bubna commented on VELOCITY-773: --- You're right, $foreach is always on, as it (and its special properties) are heavily used. Provide locally scoped #set variables - Key: VELOCITY-773 URL: https://issues.apache.org/jira/browse/VELOCITY-773 Project: Velocity Issue Type: Improvement Components: Engine Affects Versions: 1.7-beta1 Reporter: Michael Osipov Consider this snippet: !-- Generated pushbutton groups -- #foreach ($group in $form.pushbuttonGroups) div class=die-button-group style=#coordinates($group) #**##foreach ($groupChild in $group.children) #**##if (!$velocityHasNext)#set($turnPaddingOff = 'style=padding-bottom: 0px;')#end #**##if ($groupChild.class.simpleName == Pushbutton) #* *#div $!turnPaddingOff #* *#button type=submit name=$groupChild.name value=$groupChild.value onclick=loadSubsequent()#label($groupChild.label)/button #* *#/div #**##end #**##end /div #end There is an inherent bug. After the first run of the outer foreach, the var turnPaddingOff is still available and will always set in the div tag. There is only one workaround. At the end of the outer foreach you have to set it to ''. #set should be available as a locally scoped thing in #foreach or other constructs. -- 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-775) Hanging in jj_scan_token
[ https://issues.apache.org/jira/browse/VELOCITY-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12903448#action_12903448 ] Nathan Bubna commented on VELOCITY-775: --- This seems likely to be a bug in JavaCC, though i can't be sure right now. Considering the difficulty of reproducing this (3 hours under load), please provide as much info as possible about the environment (OS, JVM, servlet engine, etc) and also your velocity.properties, if you change any from the defaults. It would be good to know parser pool size, resource loader, etc. Hanging in jj_scan_token Key: VELOCITY-775 URL: https://issues.apache.org/jira/browse/VELOCITY-775 Project: Velocity Issue Type: Bug Components: Engine Environment: Velocity 1.6.3 Reporter: Dominik Stadler I have the same issue as reported in VELOCITY-562, velocity hangs in method Parser.jj_scan_token(). I can reproduce it by running heavy load on my application for a few hours. Currently running 1.6.3, I looked at the issues fixed in 1.6.4, VELOCITY-718 seems not related, but I will now upgrade to 1.6.4 and see if the same happens again. The application is using velocity in up to 3 threads simultaneously, nothing is shared between threads, relevant stack traces from a thread dump are as follows, one thread is currently not inside velocity at all: 1334671...@qtp-2060763463-85 prio=6 tid=0x181c5800 nid=0x6004 runnable [0x110dd000] java.lang.Thread.State: RUNNABLE at org.apache.velocity.runtime.parser.Parser.jj_scan_token(Parser.java:3340) at org.apache.velocity.runtime.parser.Parser.jj_3R_56(Parser.java:2768) at org.apache.velocity.runtime.parser.Parser.jj_3R_29(Parser.java:3000) at org.apache.velocity.runtime.parser.Parser.jj_3_8(Parser.java:2834) at org.apache.velocity.runtime.parser.Parser.jj_3_7(Parser.java:2878) at org.apache.velocity.runtime.parser.Parser.jj_2_7(Parser.java:2560) at org.apache.velocity.runtime.parser.Parser.Reference(Parser.java:1317) at org.apache.velocity.runtime.parser.Parser.Statement(Parser.java:354) at org.apache.velocity.runtime.parser.Parser.IfStatement(Parser.java:1530) at org.apache.velocity.runtime.parser.Parser.Statement(Parser.java:346) at org.apache.velocity.runtime.parser.Parser.Directive(Parser.java:888) at org.apache.velocity.runtime.parser.Parser.Statement(Parser.java:373) at org.apache.velocity.runtime.parser.Parser.process(Parser.java:311) at org.apache.velocity.runtime.parser.Parser.parse(Parser.java:105) at org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1131) at org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1086) at org.apache.velocity.Template.process(Template.java:124) at org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:446) at org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:354) at org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1400) at org.apache.velocity.runtime.directive.Parse.render(Parse.java:198) at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:175) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:336) at org.apache.velocity.Template.merge(Template.java:328) at org.apache.velocity.Template.merge(Template.java:235) 1946923...@qtp-2060763463-4 prio=6 tid=0x0c6dc000 nid=0x48a4 runnable [0x13bcd000] java.lang.Thread.State: RUNNABLE at org.apache.velocity.runtime.parser.Parser.jj_scan_token(Parser.java:3340) at org.apache.velocity.runtime.parser.Parser.jj_3R_56(Parser.java:2768) at org.apache.velocity.runtime.parser.Parser.jj_3R_29(Parser.java:3000) at org.apache.velocity.runtime.parser.Parser.jj_3_8(Parser.java:2834) at org.apache.velocity.runtime.parser.Parser.jj_3_7(Parser.java:2878) at org.apache.velocity.runtime.parser.Parser.jj_2_7(Parser.java:2560) at org.apache.velocity.runtime.parser.Parser.Reference(Parser.java:1317) at org.apache.velocity.runtime.parser.Parser.Statement(Parser.java:354) at org.apache.velocity.runtime.parser.Parser.Directive(Parser.java:888) at org.apache.velocity.runtime.parser.Parser.Statement(Parser.java:373) at org.apache.velocity.runtime.parser.Parser.process(Parser.java:311) at org.apache.velocity.runtime.parser.Parser.parse(Parser.java:105) at org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1131) at org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:1086) at
[jira] Resolved: (VELOCITY-774) Provide #unset directive
[ https://issues.apache.org/jira/browse/VELOCITY-774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Bubna resolved VELOCITY-774. --- Resolution: Won't Fix #set( $foo = $null ) or put your context into itself and do: #set( $ignore = $!context.remove($foo) ) or in 1.7+ enable the particular explicit scope that you need: macro.provide.scope.control = true and then do: $macro.foo = 'whatever' and when the macro is gone, $macro.foo will be gone too. Provide #unset directive Key: VELOCITY-774 URL: https://issues.apache.org/jira/browse/VELOCITY-774 Project: Velocity Issue Type: New Feature Components: Engine Affects Versions: 1.7-beta1 Reporter: Michael Osipov Sometimes one wants to use a variable in a certain scope because the further existence might lead to errors. I declared var with #set should be unsettable. See VELOCITY-773 for a iuse case. -- 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] Resolved: (VELOCITY-773) Provide locally scoped #set variables
[ https://issues.apache.org/jira/browse/VELOCITY-773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Bubna resolved VELOCITY-773. --- Resolution: Not A Problem No.This is by design. There are no more implicit scopes in Velocity 1.7+ All variables are now global scoped by default. Scoping is now done explicitly. You can turn on the explicit scopes you want/need as listed here: http://velocity.apache.org/engine/devel/developer-guide.html#Velocity_Configuration_Keys_and_Values Then use them explicitly: #set( $macro.foo = 'bar' )## will vanish when macro is done rendering Provide locally scoped #set variables - Key: VELOCITY-773 URL: https://issues.apache.org/jira/browse/VELOCITY-773 Project: Velocity Issue Type: Improvement Components: Engine Affects Versions: 1.7-beta1 Reporter: Michael Osipov Consider this snippet: !-- Generated pushbutton groups -- #foreach ($group in $form.pushbuttonGroups) div class=die-button-group style=#coordinates($group) #**##foreach ($groupChild in $group.children) #**##if (!$velocityHasNext)#set($turnPaddingOff = 'style=padding-bottom: 0px;')#end #**##if ($groupChild.class.simpleName == Pushbutton) #* *#div $!turnPaddingOff #* *#button type=submit name=$groupChild.name value=$groupChild.value onclick=loadSubsequent()#label($groupChild.label)/button #* *#/div #**##end #**##end /div #end There is an inherent bug. After the first run of the outer foreach, the var turnPaddingOff is still available and will always set in the div tag. There is only one workaround. At the end of the outer foreach you have to set it to ''. #set should be available as a locally scoped thing in #foreach or other constructs. -- 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: (VELTOOLS-101) Use Maven Ant tasks (particularly for deploying releases to the main repo)
[ https://issues.apache.org/jira/browse/VELTOOLS-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Bubna updated VELTOOLS-101: -- Fix Version/s: 2.x (was: 2.0) Use Maven Ant tasks (particularly for deploying releases to the main repo) -- Key: VELTOOLS-101 URL: https://issues.apache.org/jira/browse/VELTOOLS-101 Project: Velocity Tools Issue Type: Improvement Components: Build Affects Versions: 2.0 Reporter: Nathan Bubna Fix For: 2.x Since we're not likely to make a complete move to Maven2 (VELTOOLS-65) anytime soon. We should at least use some of Maven's Ant tasks to smooth out some of the issues we've had with making velocity tools (and the other Velocity libs) available via the Maven repos. http://maven.apache.org/ant-tasks.html -- 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: (VELTOOLS-93) Missing infos on tools creation
[ https://issues.apache.org/jira/browse/VELTOOLS-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Bubna updated VELTOOLS-93: - Fix Version/s: 2.x (was: 2.0) Missing infos on tools creation --- Key: VELTOOLS-93 URL: https://issues.apache.org/jira/browse/VELTOOLS-93 Project: Velocity Tools Issue Type: Improvement Components: Documentation Affects Versions: 2.0 Environment: all Reporter: Claude Brisson Priority: Minor Fix For: 2.x (this is a reminder for Nathan or myself...) The documentation is lacking some infos on tools properties : 1) the Creating Tools page should explain the configure/setXXX mechanism 2) the Web Framework Integration (which should maybe be named J2EE Integration to avoid the ambiguous framework word) should list all standard properties that are set for every scope (setRequest,setVelocityContext...). (...and grep TODO docs/* ...) -- 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: (VELTOOLS-126) XSS Vulnerability when using struts/ErrorsTool.getMsgs
[
https://issues.apache.org/jira/browse/VELTOOLS-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12896323#action_12896323
]
Nathan Bubna commented on VELTOOLS-126:
---
Highlighting this in the docs sounds good. And perhaps a configuration switch
in the code to make fixing easy for those who don't care to preserve markup?
XSS Vulnerability when using struts/ErrorsTool.getMsgs
--
Key: VELTOOLS-126
URL: https://issues.apache.org/jira/browse/VELTOOLS-126
Project: Velocity Tools
Issue Type: Bug
Components: VelocityStruts
Affects Versions: 1.4, 2.x
Environment: Identified in velocity-tools 1.4, verified by reading
code in trunk.
Reporter: Christopher Schultz
The code for ErrorsTool.getMsgs goes roughly like this:
String message = message(errors.header);
foreach(error) {
message += message(errors.prefix) + error + message(errors.suffix)
message += message(errors.footer)
return message;
This is easily open to an XSS attack when an error message contains user
input.
Honestly, I'm not entirely sure if we should even do anything about this,
because the ErrorsTool is not strictly for use in an HTML context, so
escaping the error message itself may not be appropriate. Also, the message
itself may contain markup which the developer wants to remain, while the user
input should be escaped.
It's possible that the solution to this problem is to put a big warning on
the tool that XSS attacks are very easy using this tool.
I've been running with it for years, and didn't notice until today. I
replaced my use of errors.getMsgs with this:
$!msg.errors.header
#foreach($error in $errors.get($fieldName))
$!msg.errors.prefix#htmlEscape($error)$!msg.errors.suffix
#end
$!msg.errors.header
...which is appropriate for my uses, but might not work for everyone.
--
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-768) Mark optional dependencies as optional in OSGi bundle manifest
[ https://issues.apache.org/jira/browse/VELOCITY-768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12880409#action_12880409 ] Nathan Bubna commented on VELOCITY-768: --- Thanks, i've applied the patch. I'm still a newbie when it comes to OSGi, so help is welcome. As for generating from the POM, can the POM express required-for-compilation-but-optional-for-users? I didn't think it could... Mark optional dependencies as optional in OSGi bundle manifest -- Key: VELOCITY-768 URL: https://issues.apache.org/jira/browse/VELOCITY-768 Project: Velocity Issue Type: Improvement Components: Build Affects Versions: 1.7-beta1 Reporter: Matt Ryall Attachments: VELOCITY-768_mark_optional_deps_in_manifest_v1.patch Trying to use the Velocity 1.7-beta1 JAR in our OSGi container (Felix running in Atlassian Confluence), we ran into dependency problems because all the dependencies of Velocity are marked as mandatory. As you would know, Velocity has a logging abstraction which allows different logging frameworks to be used. Likewise, you don't need the servlet API to use Velocity. However, these dependencies are marked as required in the new OSGi manifest added in VELOCITY-694. This causes the bundle to fail to start because the dependencies are missing. From our testing, we could use Velocity in our application just fine with following imports changed to be optional: * com.werken.xpath * javax.servlet * javax.servlet.http * org.apache.commons.logging * org.apache.log * org.apache.log.format * org.apache.log.output.io * org.apache.log4j * org.apache.oro.text.perl * org.apache.tools.ant * org.apache.tools.ant.taskdefs * org.jdom * org.jdom.input * org.jdom.output That means changing the current Import-Package declaration from this: Import-Package: com.werken.xpath, javax.naming, javax.servlet, javax.servlet.http, javax.sql, org.apache.commons.collections, org.apache.commons.collections.map, org.apache.commons.lang, org.apache.commons.lang.builder, org.apache.commons.lang.text, org.apache.commons.logging, org.apache.log, org.apache.log.format, org.apache.log.output.io, org.apache.log4j, org.apache.oro.text.perl, org.apache.tools.ant, org.apache.tools.ant.taskdefs, org.jdom, org.jdom.input, org.jdom.output, org.xml.sax to this: Import-Package: com.werken.xpath;resolution:=optional, javax.naming, javax.servlet;resolution:=optional, javax.servlet.http;resolution:=optional, javax.sql, org.apache.commons.collections, org.apache.commons.collections.map, org.apache.commons.lang, org.apache.commons.lang.builder, org.apache.commons.lang.text, org.apache.commons.logging;resolution:=optional, org.apache.log;resolution:=optional, org.apache.log.format;resolution:=optional, org.apache.log.output.io;resolution:=optional, org.apache.log4j;resolution:=optional, org.apache.oro.text.perl;resolution:=optional, org.apache.tools.ant;resolution:=optional, org.apache.tools.ant.taskdefs;resolution:=optional, org.jdom;resolution:=optional, org.jdom.input;resolution:=optional, org.jdom.output;resolution:=optional, org.xml.sax I'll prepare a patch against trunk and attach it shortly. -- 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-768) Mark optional dependencies as optional in OSGi bundle manifest
[ https://issues.apache.org/jira/browse/VELOCITY-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Bubna updated VELOCITY-768: -- Fix Version/s: 1.7 Only fixed in 1.7, for the time being. Mark optional dependencies as optional in OSGi bundle manifest -- Key: VELOCITY-768 URL: https://issues.apache.org/jira/browse/VELOCITY-768 Project: Velocity Issue Type: Improvement Components: Build Affects Versions: 1.7-beta1 Reporter: Matt Ryall Fix For: 1.7 Attachments: VELOCITY-768_mark_optional_deps_in_manifest_v1.patch Trying to use the Velocity 1.7-beta1 JAR in our OSGi container (Felix running in Atlassian Confluence), we ran into dependency problems because all the dependencies of Velocity are marked as mandatory. As you would know, Velocity has a logging abstraction which allows different logging frameworks to be used. Likewise, you don't need the servlet API to use Velocity. However, these dependencies are marked as required in the new OSGi manifest added in VELOCITY-694. This causes the bundle to fail to start because the dependencies are missing. From our testing, we could use Velocity in our application just fine with following imports changed to be optional: * com.werken.xpath * javax.servlet * javax.servlet.http * org.apache.commons.logging * org.apache.log * org.apache.log.format * org.apache.log.output.io * org.apache.log4j * org.apache.oro.text.perl * org.apache.tools.ant * org.apache.tools.ant.taskdefs * org.jdom * org.jdom.input * org.jdom.output That means changing the current Import-Package declaration from this: Import-Package: com.werken.xpath, javax.naming, javax.servlet, javax.servlet.http, javax.sql, org.apache.commons.collections, org.apache.commons.collections.map, org.apache.commons.lang, org.apache.commons.lang.builder, org.apache.commons.lang.text, org.apache.commons.logging, org.apache.log, org.apache.log.format, org.apache.log.output.io, org.apache.log4j, org.apache.oro.text.perl, org.apache.tools.ant, org.apache.tools.ant.taskdefs, org.jdom, org.jdom.input, org.jdom.output, org.xml.sax to this: Import-Package: com.werken.xpath;resolution:=optional, javax.naming, javax.servlet;resolution:=optional, javax.servlet.http;resolution:=optional, javax.sql, org.apache.commons.collections, org.apache.commons.collections.map, org.apache.commons.lang, org.apache.commons.lang.builder, org.apache.commons.lang.text, org.apache.commons.logging;resolution:=optional, org.apache.log;resolution:=optional, org.apache.log.format;resolution:=optional, org.apache.log.output.io;resolution:=optional, org.apache.log4j;resolution:=optional, org.apache.oro.text.perl;resolution:=optional, org.apache.tools.ant;resolution:=optional, org.apache.tools.ant.taskdefs;resolution:=optional, org.jdom;resolution:=optional, org.jdom.input;resolution:=optional, org.jdom.output;resolution:=optional, org.xml.sax I'll prepare a patch against trunk and attach it shortly. -- 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-768) Mark optional dependencies as optional in OSGi bundle manifest
[ https://issues.apache.org/jira/browse/VELOCITY-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Bubna updated VELOCITY-768: -- Affects Version/s: 1.7 2.0 (was: 1.7-beta1) Mark optional dependencies as optional in OSGi bundle manifest -- Key: VELOCITY-768 URL: https://issues.apache.org/jira/browse/VELOCITY-768 Project: Velocity Issue Type: Improvement Components: Build Affects Versions: 1.7, 2.0 Reporter: Matt Ryall Fix For: 1.7 Attachments: VELOCITY-768_mark_optional_deps_in_manifest_v1.patch Trying to use the Velocity 1.7-beta1 JAR in our OSGi container (Felix running in Atlassian Confluence), we ran into dependency problems because all the dependencies of Velocity are marked as mandatory. As you would know, Velocity has a logging abstraction which allows different logging frameworks to be used. Likewise, you don't need the servlet API to use Velocity. However, these dependencies are marked as required in the new OSGi manifest added in VELOCITY-694. This causes the bundle to fail to start because the dependencies are missing. From our testing, we could use Velocity in our application just fine with following imports changed to be optional: * com.werken.xpath * javax.servlet * javax.servlet.http * org.apache.commons.logging * org.apache.log * org.apache.log.format * org.apache.log.output.io * org.apache.log4j * org.apache.oro.text.perl * org.apache.tools.ant * org.apache.tools.ant.taskdefs * org.jdom * org.jdom.input * org.jdom.output That means changing the current Import-Package declaration from this: Import-Package: com.werken.xpath, javax.naming, javax.servlet, javax.servlet.http, javax.sql, org.apache.commons.collections, org.apache.commons.collections.map, org.apache.commons.lang, org.apache.commons.lang.builder, org.apache.commons.lang.text, org.apache.commons.logging, org.apache.log, org.apache.log.format, org.apache.log.output.io, org.apache.log4j, org.apache.oro.text.perl, org.apache.tools.ant, org.apache.tools.ant.taskdefs, org.jdom, org.jdom.input, org.jdom.output, org.xml.sax to this: Import-Package: com.werken.xpath;resolution:=optional, javax.naming, javax.servlet;resolution:=optional, javax.servlet.http;resolution:=optional, javax.sql, org.apache.commons.collections, org.apache.commons.collections.map, org.apache.commons.lang, org.apache.commons.lang.builder, org.apache.commons.lang.text, org.apache.commons.logging;resolution:=optional, org.apache.log;resolution:=optional, org.apache.log.format;resolution:=optional, org.apache.log.output.io;resolution:=optional, org.apache.log4j;resolution:=optional, org.apache.oro.text.perl;resolution:=optional, org.apache.tools.ant;resolution:=optional, org.apache.tools.ant.taskdefs;resolution:=optional, org.jdom;resolution:=optional, org.jdom.input;resolution:=optional, org.jdom.output;resolution:=optional, org.xml.sax I'll prepare a patch against trunk and attach it shortly. -- 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-766) Failed to initialize an instance of org.apache.velocity.runtime.log.ServletLogChute with the current runtime configuration.
[ https://issues.apache.org/jira/browse/VELOCITY-766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12872251#action_12872251 ] Nathan Bubna commented on VELOCITY-766: --- [sarcasm]Please can we do what??? No, we like broken frameworks! It was intentional, so we need more persuasion than that before we try and fix things.[/sarcasm] And no, the SystemLogChute is present and works fine. The actual problem is that the ServletLogChute tries to initialize because you are running a webapp (making the needed classes available), but then throws an UnsupportedOperationException because a ServletContext is not available to it in Velocity's application attributes. And the LogManager incorrectly assumes that is user-error and throws the exception onward instead of logging and trying the next LogChute. And despite your apparent doubts about our intentions, the problem will be fixed. :) In the meantime, you can do one of two things. Either put the ServletContext in your app attributes: VelocityEngine engine = new VelocityEngine(); engine.setApplicationAttribute(ServletContext.class.getName(), servletContext); engine.init(); or just set the runtime.log.logsystem.class property to a different logging class (i'd recommend JdkLogChute or NullLogChute), unless you prefer commons-logging or log4j for some reason. Failed to initialize an instance of org.apache.velocity.runtime.log.ServletLogChute with the current runtime configuration. --- Key: VELOCITY-766 URL: https://issues.apache.org/jira/browse/VELOCITY-766 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.6.4 Environment: java version 1.6.0_17 Java(TM) SE Runtime Environment (build 1.6.0_17-b04) Java HotSpot(TM) 64-Bit Server VM (build 14.3-b01, mixed mode) Reporter: Graham Leggett After upgrading a web application that uses velocity from java 5 to java 6, the web application has suddenly randomly stopped working, failing suddenly when run with the following exception: Failed to initialize an instance of org.apache.velocity.runtime.log.ServletLogChute with the current runtime configuration. Google shows that this error has something to do with logging being broken out the box: http://stackoverflow.com/questions/1586133/apache-velocity-can-not-initialize Referring specifically to this comment in the code: /* If the above failed, that means either the user specified a * logging class that we can't find, there weren't the necessary * dependencies in the classpath for it, or there were the same * problems for the default loggers, log4j and Java1.4+. * Since we really don't know and we want to be sure the user knows * that something went wrong with the logging, let's fall back to the * surefire SystemLogChute. No panicking or failing to log!! */ It seems despite the code's best efforts, SystemLogChute is either broken or missing, and this breaks Velocity. Please can you use a logging framework that isn't broken out the box (I do realise that most logging frameworks have been broken out the box for years, surely there is one that isn't completely useless, I live in hope). -- 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] Resolved: (VELOCITY-764) Download page http://velocity.apache.org/download.html is empty
[ https://issues.apache.org/jira/browse/VELOCITY-764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Bubna resolved VELOCITY-764. --- Resolution: Fixed all better now. sorry! Download page http://velocity.apache.org/download.html is empty --- Key: VELOCITY-764 URL: https://issues.apache.org/jira/browse/VELOCITY-764 Project: Velocity Issue Type: Bug Components: Website Environment: http://velocity.apache.org/download.html Reporter: Sebb Priority: Blocker Download page http://velocity.apache.org/download.html is empty. Looks as though a recent change may have occurred. -- 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] Resolved: (VELOCITY-763) $foreach.isLast() is always false
[ https://issues.apache.org/jira/browse/VELOCITY-763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Bubna resolved VELOCITY-763. --- Fix Version/s: 1.7 2.0 Resolution: Fixed Technically, it was already fixed in 2.0, but i added a test to keep an eye on it. $foreach.isLast() is always false - Key: VELOCITY-763 URL: https://issues.apache.org/jira/browse/VELOCITY-763 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.7-beta1 Reporter: Sergiy Kovalchuk Fix For: 1.7, 2.0 $foreach.isLast() is not detecting last element. Test case: #foreach($i in [1..3]) $foreach.isLast()br/ #end Result: false false 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-761) Can not reference a property declared in a super-interface and implemented in a non-public class
[
https://issues.apache.org/jira/browse/VELOCITY-761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12866583#action_12866583
]
Nathan Bubna commented on VELOCITY-761:
---
createMethodCache gets the interfaces of the class and calls
populateMethodCacheWithInterface(...), which most certainly gets the super
interfaces and recurses up the tree that way too. We even test this out in the
Velocity689TestCase as part of our build process. See VELOCITY-689.
Can not reference a property declared in a super-interface and implemented in
a non-public class
Key: VELOCITY-761
URL: https://issues.apache.org/jira/browse/VELOCITY-761
Project: Velocity
Issue Type: Bug
Components: Engine
Affects Versions: 1.6.3
Reporter: Charles Miller
Consider the following:
public interface MyUser extends java.security.Principal {
String getEmailAddress();
}
class MyUserImpl implements MyUser {
public String getName() { ... }
public String getEmailAddress() { ... }
}
If I put a MyUserImpl in my Velocity context, $user.emailAddress will
resolve, but $user.name will not.
This is a problem with ClassMap#createMethodCache(). It ignores methods
declared on the MyUserImpl class because the class is non-public, and it only
looks up one level in the Interface hierarchy for methods defined on
interfaces: so it will go up as far as the MyUser interface but not as far as
the Principal interface.
--
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-760) DataSourceResourceLoader doesn't close PreparedStatements
[
https://issues.apache.org/jira/browse/VELOCITY-760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Bubna updated VELOCITY-760:
--
Fix Version/s: 1.7
DataSourceResourceLoader doesn't close PreparedStatements
-
Key: VELOCITY-760
URL: https://issues.apache.org/jira/browse/VELOCITY-760
Project: Velocity
Issue Type: Bug
Components: Engine
Affects Versions: 1.6.2
Reporter: Jerome Waibel
Fix For: 1.7
Attachments: velocity-760.patch
DataSourceResourceLoader.java contains this method:
private ResultSet readData(final Connection conn,
final String columnNames,
final String templateName) throws SQLException
{
PreparedStatement ps = conn.prepareStatement(SELECT + columnNames
+ FROM + tableName + WHERE + keyColumn + = ?);
ps.setString(1, templateName);
return ps.executeQuery();
}
PreparedStatements created in this method never get closed, only the
resultset returned may eventually be closed later which isn't sufficient for
releasing all bound resources. In my project this statement leak lead to the
oracle running out of open cursors (the infamous ORA-01000 error).
--
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] Resolved: (VELOCITY-717) Engine throws an NPE using custom macro libs if the IncludeEventHandler returns null
[ https://issues.apache.org/jira/browse/VELOCITY-717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Bubna resolved VELOCITY-717. --- Assignee: (was: Will Glass-Husain) Fix Version/s: 1.6.x Resolution: Fixed Fixed. Thanks, Jarkko. Engine throws an NPE using custom macro libs if the IncludeEventHandler returns null Key: VELOCITY-717 URL: https://issues.apache.org/jira/browse/VELOCITY-717 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.6.2 Environment: Suse Linux Reporter: Johann Weber Priority: Critical Fix For: 1.6.x, 1.7 Attachments: macros2.vm, test8.vm, Velocity717TestCase.java The Engine throws an NPE if the IncludeEventHandler returns null. (using merge method with a list of macro libs) java.lang.NullPointerException at java.util.Hashtable.get(Hashtable.java:333) at org.apache.velocity.runtime.VelocimacroManager.getNamespace(VelocimacroManager.java:318) at org.apache.velocity.runtime.VelocimacroManager.get(VelocimacroManager.java:215) at org.apache.velocity.runtime.VelocimacroFactory.getVelocimacro(VelocimacroFactory.java:563) at org.apache.velocity.runtime.RuntimeInstance.getVelocimacro(RuntimeInstance.java:1563) at org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:218) at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:175) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:336) at org.apache.velocity.runtime.directive.Parse.render(Parse.java:260) at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:175) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:336) at org.apache.velocity.Template.merge(Template.java:328) -- 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-554) Velocity sources and javadocs missing in the maven repository
[ https://issues.apache.org/jira/browse/VELOCITY-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Bubna updated VELOCITY-554: -- Fix Version/s: (was: 1.7) Velocity sources and javadocs missing in the maven repository - Key: VELOCITY-554 URL: https://issues.apache.org/jira/browse/VELOCITY-554 Project: Velocity Issue Type: New Feature Components: Build Affects Versions: 1.5 Reporter: Aliaksandr Radzivanovich Assignee: Nathan Bubna Fix For: 1.7 Attachments: VELOCITY-554-2.patch, VELOCITY-554-3.patch, VELOCITY-554_download.patch It is really annoying when popular projects like Apache Velocity do not provide their sources and javadocs to the Maven repository. -- 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-717) Engine throws an NPE using custom macro libs if the IncludeEventHandler returns null
[ https://issues.apache.org/jira/browse/VELOCITY-717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12859363#action_12859363 ] Nathan Bubna commented on VELOCITY-717: --- Well, we have other unreleased fixes in the 1.6 branch, might as well fix this too. Perhaps we can muster the votes and effort for a 1.6.4 release. Engine throws an NPE using custom macro libs if the IncludeEventHandler returns null Key: VELOCITY-717 URL: https://issues.apache.org/jira/browse/VELOCITY-717 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.6.2 Environment: Suse Linux Reporter: Johann Weber Assignee: Will Glass-Husain Priority: Critical Fix For: 1.7 Attachments: macros2.vm, test8.vm, Velocity717TestCase.java The Engine throws an NPE if the IncludeEventHandler returns null. (using merge method with a list of macro libs) java.lang.NullPointerException at java.util.Hashtable.get(Hashtable.java:333) at org.apache.velocity.runtime.VelocimacroManager.getNamespace(VelocimacroManager.java:318) at org.apache.velocity.runtime.VelocimacroManager.get(VelocimacroManager.java:215) at org.apache.velocity.runtime.VelocimacroFactory.getVelocimacro(VelocimacroFactory.java:563) at org.apache.velocity.runtime.RuntimeInstance.getVelocimacro(RuntimeInstance.java:1563) at org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:218) at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:175) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:336) at org.apache.velocity.runtime.directive.Parse.render(Parse.java:260) at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:175) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:336) at org.apache.velocity.Template.merge(Template.java:328) -- 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] Resolved: (VELTOOLS-97) MarkupTool
[
https://issues.apache.org/jira/browse/VELTOOLS-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Bubna resolved VELTOOLS-97.
--
Fix Version/s: 2.0
(was: 2.x)
Resolution: Fixed
MarkupTool
--
Key: VELTOOLS-97
URL: https://issues.apache.org/jira/browse/VELTOOLS-97
Project: Velocity Tools
Issue Type: New Feature
Components: GenericTools
Affects Versions: 2.x
Reporter: Nathan Bubna
Priority: Minor
Fix For: 2.0
As i grow continually more fond of tools and less fond of macros (though
things are finally starting to look up for macros in 1.6 and the possibility
of Raghu implementing blockmacros), i find myself starting to wish for tools
that aid with markup (mostly html or xml). The idea has occurred to me that
i might find a general MarkupTool for manipulating markup in flexible,
repeatable ways. The API i have in mind might be used something like this:
#set( $foo = $markup.foo.attr('bar', 0) )
$foo
#if( $foo.bar == 0 )
$foo.body($text.danger).attr({'black' : 'white', 'zebras' : $crossing})
#end
which would output
foo bar=0/
foo bar=0 black=white zebras=crossingDanger!/foo
It's also not hard to imagine ways to allow default attributes/values for
various tags in the configuration for the tool, like
tool class=org.apache.velocity.tools.generic.MarkupTool
img=border:0,class:thumb/
So that doing just
$markup.img.attr('src',$imglink)
would produce something like
img border=0 class=thumb src=http://foo.com/bar.jpg/
Granted, i don't have that many situations where this would be useful, but
there have been a few. Also, i wonder if it might serve as a base class for
a JSPTaglibTool (see
http://velocity.markmail.org/search/?q=jsp+tag#query:jsp%20tag%20from%3A%22Nathan%20Bubna%22+page:2+mid:ebotko7hanut3uhx+state:results
for more on this)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
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] Resolved: (VELTOOLS-124) LoopTool fails to retrieve $loop.index, $loop.first etc for the last element in a collection.
[
https://issues.apache.org/jira/browse/VELTOOLS-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Bubna resolved VELTOOLS-124.
---
Resolution: Fixed
Fix Version/s: 2.0
Unfortunately, there is no alternative time to pop the last iterator from the
stack. There is no way to have the #foreach directive notify the LoopTool
that #end was reached. It's just not possible without hacking Velocity Engine
itself.
However, Velocity 1.7 will soon have a beta release and hopefully a final
release shortly thereafter. With that release is the advent of the $foreach
control object. That will provide $foreach.count $foreach.index
$foreach.last $foreach.first and $foreach.hasNext to all #foreach loops. It
will also provide access to $foreach.parent and $foreach.parent.parent and so
on up to $foreach.topmost to provide access to all those properties in nested
situations. Oh, and the #break directive is upgraded to accept a #break(
$foreach.parent ) argument and so on.
All that is to say that the LoopTool will soon be only useful for the sync,
skip and stop condition features, which are not affected by this bug.
Still, in the short term, i've got a solution for those wishing to always have
accurate index, count, etc properties. I've provided access to the underlying
ManagedIterator wrapper:
#foreach( $i in $loop.watch([1..3]) )
#set( $this = $loop.this )
i[$this.index]=$i;
#end
The $loop.this reference will always provide the ManagedIterator from the most
recent $loop.watch() call. Along with this, i have actually fixed this
specific bug in some situations by using that last iterator reference. So,
in simple situations like the example you gave, things should work fine.
However, in nested loop situations, things get messy once you start getting
beyond the first #end on the final iteration(s) of the nested #foreach calls.
Your only reliable bet in that situation is to grab the $loop.this reference at
the top of each #foreach and use those to get what you need or to otherwise not
reference $loop properties directly after the first #end.
Though, again, for index/count/first/last/hasNext properties, the only proper
solution is the upcoming $foreach reference in Velocity 1.7. Once $foreach is
well established, those properties of $loop should probably just be removed.
LoopTool fails to retrieve $loop.index, $loop.first etc for the last element
in a collection.
-
Key: VELTOOLS-124
URL: https://issues.apache.org/jira/browse/VELTOOLS-124
Project: Velocity Tools
Issue Type: Bug
Components: GenericTools
Affects Versions: 2.x
Environment: velocity-tools-2.0-beta4 with velocity-1.6.2
Reporter: Sergiy Kovalchuk
Fix For: 2.0, 2.x
$loop.index, $loop.first and other LoopTool methods (that depend on iterator)
return null for the last element in a collection.
Try to run:
#set( $list = [1..3] )
#foreach($i in $loop.watch($list))
i[${loop.index}]=$i;
#end
The result is:
i[0]=1; i[1]=2; i[${loop.index}]=3;
I tried to investigate it a little, and seems like the problem is inside
cacheNext(boolean popWhenDone).
First it checks if (!iterator.hasNext()) and if not then removes this
iterator from the stack. But later in this method it retrieves next element
from a collection this.next = iterator.next();. Seems like it causes
removing iterator too early, when calling ${loop.index} on the last element
the iterator is already removed.
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: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] Commented: (VELOCITY-694) Make Velocity OSGi-ready
[ https://issues.apache.org/jira/browse/VELOCITY-694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12852861#action_12852861 ] Nathan Bubna commented on VELOCITY-694: --- How exactly is that different than option #2? There is only one build process sanctioned for doing releases. Make Velocity OSGi-ready Key: VELOCITY-694 URL: https://issues.apache.org/jira/browse/VELOCITY-694 Project: Velocity Issue Type: Wish Affects Versions: 1.6.1 Reporter: Stevo Slavic Fix For: 1.7, 2.0 Attachments: velocity-dep.jar Velocity jar should be OSGi-ready with all necessary headers in MANIFEST.MF -- 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-694) Make Velocity OSGi-ready
[ https://issues.apache.org/jira/browse/VELOCITY-694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12852598#action_12852598 ] Nathan Bubna commented on VELOCITY-694: --- Shame on me. Didn't actually test release task, for which we still require JDK1.4, while Bundlor requires 1.5. Here's the options i see: - Build non-OSGi-ready release for 1.7 and leave people to build their own manifests. - Bump the target JDK to 1.5 (No, building with 1.5 target 1.4 is not an option due to StringBuffer.append mess) - Manually build an OSGi-ready manifest with the jar tasks manifest sub-task. This means sticking a massive property like the one above into build.properties. But that would only be for 1.7. In 2.0, we'll be back to the Bundlor manifest. I'm inclined to go with option 3. Make Velocity OSGi-ready Key: VELOCITY-694 URL: https://issues.apache.org/jira/browse/VELOCITY-694 Project: Velocity Issue Type: Wish Affects Versions: 1.6.1 Reporter: Stevo Slavic Fix For: 1.7, 2.0 Attachments: velocity-dep.jar Velocity jar should be OSGi-ready with all necessary headers in MANIFEST.MF -- 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] Resolved: (VELOCITY-694) Make Velocity OSGi-ready
[ https://issues.apache.org/jira/browse/VELOCITY-694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Bubna resolved VELOCITY-694. --- Resolution: Fixed Fix Version/s: 2.0 1.7 Ok, the build.xml now support Bundlor-enhanced manifests for the jars (turned on by default in release task). Make Velocity OSGi-ready Key: VELOCITY-694 URL: https://issues.apache.org/jira/browse/VELOCITY-694 Project: Velocity Issue Type: Wish Affects Versions: 1.6.1 Reporter: Stevo Slavic Fix For: 1.7, 2.0 Attachments: velocity-dep.jar Velocity jar should be OSGi-ready with all necessary headers in MANIFEST.MF -- 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: (TEXEN-17) Default properties of Generator are processed differently than the propertie file(s) given in the Ant-task
[ https://issues.apache.org/jira/browse/TEXEN-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12851457#action_12851457 ] Nathan Bubna commented on TEXEN-17: --- Fedor, thanks for the patch, though it is hard to see what the actual changes are amidst all of the style changes. Would you be able to resubmit the patch without all the extraneous changes? Default properties of Generator are processed differently than the propertie file(s) given in the Ant-task -- Key: TEXEN-17 URL: https://issues.apache.org/jira/browse/TEXEN-17 Project: Texen Issue Type: Bug Affects Versions: 1.1 Reporter: Fedor Jutte Fix For: 1.1 Attachments: texen17-patch.txt Original Estimate: 24h Remaining Estimate: 24h The TexenTask uses TexenUtils.populateContext() to populate the context. Instead of reusing TexenUtils.populateContext(), Generator.fillContextProperties() uses it's own, slightly different, algorithm to fill the context with it's default properties. Difference: TexenUtils.populateContext() provides additional support for entries like license.file.contents = license.txt, but Generator.fillContextProperties() doesn't. Generator.fillContextProperties() provides additional supports for entries like context.objects.strings=org.apache.velocity.util.StringUtils, but TexenUtils.populateContext() doesn't. SOLUTION: Instead of giving Generator.fillContextProperties() it's own algorithm, it should use TexenUtils.populateContext(). And the additional support for objects in Generator.fillContextProperties() should be added to TexenUtils.populateContext(). -- 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-666) Blockmacro support (allows any AST as macro body argument)
[ https://issues.apache.org/jira/browse/VELOCITY-666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12851044#action_12851044 ] Nathan Bubna commented on VELOCITY-666: --- Using #blockmacro to define a macro with a body has two major drawbacks for me: - it divides macros into two classes, which is not at all an insignificant complication for users, particularly those using macro libraries created by others. #@ allows the macro writer to make macros with the $bodyContent optional and gives template readers/users clear indication of how the macro is being used. - more significantly, it introduces implementation headaches when parsing a not-yet-defined macro. See Raghu's 4 options for dealing with this in VELOCITY-583, of which the favored required a new prefix character for using the block macro also. It's a new feature. A little forgetfulness can be forgiven. :) Blockmacro support (allows any AST as macro body argument) -- Key: VELOCITY-666 URL: https://issues.apache.org/jira/browse/VELOCITY-666 Project: Velocity Issue Type: Improvement Affects Versions: 1.6.2, 1.7 Reporter: Jarkko Viinamäki Fix For: 1.7 Attachments: velocity-blockmacro.patch, velocity-call-directive.patch Inspired by VELOCITY-583 (BlockMacro support) I implemented the same functionality in a slightly different way. The new syntax is: #...@yourmacroname($arg1 $arg2) any valid velocity AST here #end so basically the syntax is exactly the same as for normal macros except you put that @ prefix to the macro name. That tells Velocity that there's a macro AST body that should be passed to the actual macro. And in the macro you can refer to the passed body 0-N times. Like: #macro(yourMacroName $foo $bar) $bodyContent #end -- 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-753) IntrospectionUtils.isMethodInvocationConvertible() returns true for NumberFormat.format(double) method with a Float.class argument
[
https://issues.apache.org/jira/browse/VELOCITY-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12851252#action_12851252
]
Nathan Bubna commented on VELOCITY-753:
---
Ok, the key problem here is that $numberFormatter.format($aFloat) should work.
The catch is that in reflection-land (where Velocity lives), actual arguments
are always objects. In other words, in Java, if you call
numberFormat.format(aFloat), it will call the object method, because aFloat
doesn't convert to a double. But, in reflection-land, Float is
indistinguishable from float. So, format(double) and format(Object) are both
applicable. Right now, it considers the preference between those ambiguous,
with some abstract validity but ultimately wrongly in practice.
The good news is that i can fix that. The quasi-bad news is that resolving
the ambiguity means identifying the most-specific of the two: format(double).
The end result is that numberFormat.format(aFloat) in Java will call a
different method than $numberFormat.format($aFloat) in Velocity. In this
particular case, that shouldn't matter. However, it certainly could matter in
some other corner cases. Still, it would not make sense to call
format(Object) more specific than format(double) or even equivalently specific,
so i'm pretty sure this is the right thing to do.
For those interested in the details, when comparing two parameter types in
different applicable methods, i am now always considering Object.class
parameters to be less specific than anything else, which i think is pretty much
the case in reflection-land where things are always Objects. Please yell at
me if that is a terrible idea. :)
IntrospectionUtils.isMethodInvocationConvertible() returns true for
NumberFormat.format(double) method with a Float.class argument
--
Key: VELOCITY-753
URL: https://issues.apache.org/jira/browse/VELOCITY-753
Project: Velocity
Issue Type: Bug
Components: Engine
Affects Versions: 1.6.2
Reporter: Tim Kuntz
NumberFormat has both a format(double) and format(Object) method. When
evaluated against a Float, IntrospectionUtils is returning true. This causes
Method.getBestMatch() to throw an AmbigouusException.
I have included a failing test case below to show this issue.
Thanks,
Tim
import java.io.StringReader;
import java.io.StringWriter;
import java.text.NumberFormat;
import junit.framework.TestCase;
import org.apache.velocity.VelocityContext;
import org.apache.velocity.app.Velocity;
public class VelocityFormatTest extends TestCase {
public void test_format_of_float() throws Exception {
// verify format() outside of Velocity
NumberFormat numberFormat = NumberFormat.getInstance();
Float aFloat = new Float(5.23);
assertEquals(5.23, numberFormat.format(aFloat));
Velocity.init();
VelocityContext context = new VelocityContext();
context.put(numberFormatter, numberFormat);
context.put(aFloat, aFloat);
StringWriter sw = new StringWriter();
StringReader sr = new StringReader(
float value is
${numberFormatter.format($aFloat)});
Velocity.evaluate(context, sw, name, sr);
String expectedValue = float value is 5.23;
assertEquals(expectedValue, sw.toString());
}
}
--
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] Resolved: (VELOCITY-753) IntrospectionUtils.isMethodInvocationConvertible() returns true for NumberFormat.format(double) method with a Float.class argument
[
https://issues.apache.org/jira/browse/VELOCITY-753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Bubna resolved VELOCITY-753.
---
Resolution: Fixed
Fix Version/s: 2.0
1.7
IntrospectionUtils.isMethodInvocationConvertible() returns true for
NumberFormat.format(double) method with a Float.class argument
--
Key: VELOCITY-753
URL: https://issues.apache.org/jira/browse/VELOCITY-753
Project: Velocity
Issue Type: Bug
Components: Engine
Affects Versions: 1.6.2
Reporter: Tim Kuntz
Fix For: 1.7, 2.0
NumberFormat has both a format(double) and format(Object) method. When
evaluated against a Float, IntrospectionUtils is returning true. This causes
Method.getBestMatch() to throw an AmbigouusException.
I have included a failing test case below to show this issue.
Thanks,
Tim
import java.io.StringReader;
import java.io.StringWriter;
import java.text.NumberFormat;
import junit.framework.TestCase;
import org.apache.velocity.VelocityContext;
import org.apache.velocity.app.Velocity;
public class VelocityFormatTest extends TestCase {
public void test_format_of_float() throws Exception {
// verify format() outside of Velocity
NumberFormat numberFormat = NumberFormat.getInstance();
Float aFloat = new Float(5.23);
assertEquals(5.23, numberFormat.format(aFloat));
Velocity.init();
VelocityContext context = new VelocityContext();
context.put(numberFormatter, numberFormat);
context.put(aFloat, aFloat);
StringWriter sw = new StringWriter();
StringReader sr = new StringReader(
float value is
${numberFormatter.format($aFloat)});
Velocity.evaluate(context, sw, name, sr);
String expectedValue = float value is 5.23;
assertEquals(expectedValue, sw.toString());
}
}
--
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] Resolved: (VELOCITY-709) String literal \\ parses incorrectly
[
https://issues.apache.org/jira/browse/VELOCITY-709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Bubna resolved VELOCITY-709.
---
Resolution: Fixed
Fix Version/s: 2.0
Thanks, Jarkko!
String literal \\ parses incorrectly
--
Key: VELOCITY-709
URL: https://issues.apache.org/jira/browse/VELOCITY-709
Project: Velocity
Issue Type: Bug
Components: Engine
Affects Versions: 1.7
Reporter: Byron Foster
Fix For: 1.7, 2.0
Given the following VTL:
#set($var = \\ )
#set($var2 = ${var})
results in the following parse error:
Encountered ${ at test.vm[line 2, column 15]
Was expecting one of:
RPAREN ...
...
the problem is that when parsing the string literal \\ the second double
quote is escaped. This was actually a bug that was introduced in 1.6.x, but
I don't think we necessarily need to fix it in that branch.
--
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] Resolved: (VELOCITY-555) Escape quotes in interpolated strings (both ' and ) by doubling them ('' and )
[
https://issues.apache.org/jira/browse/VELOCITY-555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Bubna resolved VELOCITY-555.
---
Resolution: Fixed
Fix Version/s: 2.0
1.7
Thanks, Jarkko!
Escape quotes in interpolated strings (both ' and ) by doubling them ('' and
)
-
Key: VELOCITY-555
URL: https://issues.apache.org/jira/browse/VELOCITY-555
Project: Velocity
Issue Type: New Feature
Affects Versions: 1.5
Reporter: Nathan Bubna
Fix For: 1.7, 2.0
Attachments: velocity-555.patch
More than a few years, the issue of escaping quotes in interpolated strings
was discussed at some length. Eventually, the list came to a consensus that
we should escape them by doubling them, since this would be (or at least very
nearly be) backwards compatible and provide a simple solution for this
much-wanted feature.
Geir had working code for this and even posted a test jar, IIRC. So, many of
us thought that this had made it into the 1.5 codebase. But the code never
got checked in and may have been lost. Assuming Geir can't find the old code
or the time to duplicate the effort, we should still try to implement this.
This issue is open to remind us of that. If i get around to digging up links
to the relevant threads, i will post those in the comments of this issue.
--
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-756) New notation for replacing null values with a specified string
[ https://issues.apache.org/jira/browse/VELOCITY-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12850724#action_12850724 ] Nathan Bubna commented on VELOCITY-756: --- As an alternate to #if #else, there is also: http://velocity.apache.org/tools/devel/javadoc/org/apache/velocity/tools/generic/DisplayTool.html which provides $display.alt($foo) and $display.alt($foo, 'n/a') and many other such display control methods. This is ideally where extra features like this go. The tool approach has several advantages: - keeps VTL syntax simple and contained (feature creep has its costs) - provides API that is easy to extend and enhance - typically provides much more clear and user-friendly API Unless the $?foo syntax were to become something frequently requested (which it has never been), i don't see us working to adopt it anytime soon, for the reason of keeping things simple. New notation for replacing null values with a specified string -- Key: VELOCITY-756 URL: https://issues.apache.org/jira/browse/VELOCITY-756 Project: Velocity Issue Type: New Feature Components: Engine Reporter: Ludwig Magnusson Priority: Minor If I have a variable $foo and it is null, I have the option of using the silent notation $!foo for not writing it. But often when genrating HTML pages I want to express that the values is missing, e.g. by a -. That means that I have to write my code like this: #if($foo) $foo #else - #end Wouldn't it be great if there were a new option like $?foo (or whatever chararter would be suitable instead of ?) that would print the variable $foo if it was not null and otherwise print a predefined character like -. /Ludwig -- 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] Resolved: (VELOCITY-759) NullPointerException in Foreach.java - PatchAvailable
[ https://issues.apache.org/jira/browse/VELOCITY-759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Bubna resolved VELOCITY-759. --- Resolution: Fixed Fix Version/s: 1.7 Sure. Might as well... NullPointerException in Foreach.java - PatchAvailable - Key: VELOCITY-759 URL: https://issues.apache.org/jira/browse/VELOCITY-759 Project: Velocity Issue Type: Bug Components: Engine Reporter: Rachid Priority: Trivial Fix For: 1.7 Attachments: NullPointer-Foreach.patch I checked out the code from http://svn.apache.org/repos/asf/velocity/engine/trunk/ I think this is version 1.6.x because it is listed on http://velocity.apache.org/download.cgi But I'm not sure. When I was playing with the Velocity Template Engine I got a NullPointerException. Maybe it is because of my unusual configuration that this exception didn't occured before to others. But in my opinion this kind of Exceptions may never occur. To be specific, the Exception is thrown on line 225 in Foreach.java if (!hasNextName.equals(velocityHasNext)) When the variable hasNextName equals null hasNextName is a deprecated config setting. It is assigned on line 210: hasNextName = rsvc.getString(RuntimeConstants.HAS_NEXT_NAME); The included patch makes it NullPointer save: if (!velocityHasNext.equals(hasNextName)) -- 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
