[jira] Created: (VELOCITY-521) please do not force to use JDK 1.4 for running the package target in build.xml
please do not force to use JDK 1.4 for running the package target in build.xml -- Key: VELOCITY-521 URL: https://issues.apache.org/jira/browse/VELOCITY-521 Project: Velocity Issue Type: Bug Components: Build Affects Versions: 1.6 Environment: all Reporter: Antoine Levy-Lambert Priority: Minor build.xml target package forces to use exactly JDK 1.4. Would it not be better to build with target=1.4, source=1.4 and to simply check that the JDK version is = 1.4 I will attach a patch to this effect. Regards, Antoine -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-521) please do not force to use JDK 1.4 for running the package target in build.xml
[ https://issues.apache.org/jira/browse/VELOCITY-521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Levy-Lambert updated VELOCITY-521: -- Attachment: patch.txt I create this issue because velocity-engine stopped building in gump due to the strict JDK=1.4 restriction. I found a workaround for gump by setting correct-java-version=true in the gump descriptor. The solution proposed here is similar to the build of ant, where we build with source and target 1.2. please do not force to use JDK 1.4 for running the package target in build.xml -- Key: VELOCITY-521 URL: https://issues.apache.org/jira/browse/VELOCITY-521 Project: Velocity Issue Type: Bug Components: Build Affects Versions: 1.6 Environment: all Reporter: Antoine Levy-Lambert Priority: Minor Attachments: patch.txt build.xml target package forces to use exactly JDK 1.4. Would it not be better to build with target=1.4, source=1.4 and to simply check that the JDK version is = 1.4 I will attach a patch to this effect. Regards, Antoine -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-519) Java escape sequences should work in Velocity macros
[
https://issues.apache.org/jira/browse/VELOCITY-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475618
]
Will Glass-Husain commented on VELOCITY-519:
That's a good point. If the \u00b1 format didn't work at all before, there's
no harm in adding it in. And it adds new capability. (inserting characters
into the body that you might not have been able to before).
But if \t, \r, \n were were just passed through (and possibly this was desired
by someone generating Java code) we shouldn't intercept it. So I withdraw my
suggestion for \t, \r, \n parsing.
Java escape sequences should work in Velocity macros
Key: VELOCITY-519
URL: https://issues.apache.org/jira/browse/VELOCITY-519
Project: Velocity
Issue Type: New Feature
Affects Versions: 1.5 beta2
Reporter: Stepan Koltsov
Attachments: velocity-unescape-2007-02-24-stepancheg.diff,
velocity-unescape-only-u-2007-02-24-stepancheg.diff
Following test should work:
===
public void testJavaEscape() throws Exception {
VelocityEngine ve = new VelocityEngine();
ve.init();
Context context = new VelocityContext();
StringWriter writer = new StringWriter();
ve.evaluate(context, writer, test,#set($v = \\\u0061\)$v);
assertEquals(a, writer.toString());
writer = new StringWriter();
ve.evaluate(context, writer, test,#set($v = \\\n\)$v);
assertEquals(\n, writer.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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-521) please do not force to use JDK 1.4 for running the package target in build.xml
[ https://issues.apache.org/jira/browse/VELOCITY-521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Levy-Lambert updated VELOCITY-521: -- Hello Will, As an indication, Ant 1.7.0 has been built under JDK 1.5 with source and target 1.2. It runs perfectly under JDK 1.4. I am not sure whether we have had to change our code for 1.3 to make method calls go to the right JDK method. Ant does not run under 1.2 any more, but this is due to our implementation, not to compilation. See these postings concerning the risks of compiling under 1.5 http://article.gmane.org/gmane.comp.jakarta.ant.devel/44616/ http://article.gmane.org/gmane.comp.jakarta.ant.devel/44751/ please do not force to use JDK 1.4 for running the package target in build.xml -- Key: VELOCITY-521 URL: https://issues.apache.org/jira/browse/VELOCITY-521 Project: Velocity Issue Type: Bug Components: Build Affects Versions: 1.6 Environment: all Reporter: Antoine Levy-Lambert Priority: Minor Attachments: patch.txt build.xml target package forces to use exactly JDK 1.4. Would it not be better to build with target=1.4, source=1.4 and to simply check that the JDK version is = 1.4 I will attach a patch to this effect. Regards, Antoine -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Memory Footprint Help
We have a web site where we use velocity to generate our HTML pages. Recently I was asked to help troubleshoot some performance issues and the root cause of our problem was that the velocity cache had grown to well over 1GB in size causing the JVM to continuously GC to try to free up memory. As a short term fix I have grabbed the 1.5 beta ResourceCacheImpl class so that a maximum cache size can be set and enforced. Unfortunately when this was done the performance of the site degraded significantly as the pages were continuously compiled. I used the YourKit memory profiler and found the following information about the individual velocity cache entries (see attached picture): Name Cache Size File Size --- VM_framework_library.vm 9,596,472 130,500 VM_buttons_library.vm 1,195,680 39,113 VM_layout_library.vm 1,683,256 54,371 admin/AdminHome.vm 32,505,168 979 poNewGrid.vm 14,399,648 753 poTemplateGrid.vm14,369,000 774 po/details.vm11,140,9528,368 sub.vm 10,115,096 24,576 At this time we have made a very heavy investment in velocity as our presentation layer framework and love it. In order to meet our performance goals, we need to keep as many of the velocity pages in cache as we can but if we do that, we can only fit 2 web applications per Tomcat deployment in a 32 bit environment. In searching through the JIRA issues, I found ( http://issues.apache.org/jira/browse/VELOCITY-450 ) and ( http://issues.apache.org/jira/browse/VELOCITY-223 ) that reference this exact issue as well as the wiki entry talking about how to reduce the memory footprint. I am sending email to the developers list offering up my time to assist with this issue. I was hoping that there would be someone who would be able to point me in a direction to get me started and that there would potentially be some big wins that we could take advantage of. Are there any places where velocity is hanging on to strings, tokens, or processing instructions where we could potentially free them up? Are there other ways of factoring macros, files, or #parses that will help in reducing the footprint? Is there potentially extra data in any of the AST classes that isn't necessary after parsing or is potentially duplicate? Thank you, Ryan Smith VelocityMemory.JPG - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (VELOCITY-521) please do not force to use JDK 1.4 for running the package target in build.xml
[ https://issues.apache.org/jira/browse/VELOCITY-521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Glass-Husain reassigned VELOCITY-521: -- Assignee: Will Glass-Husain please do not force to use JDK 1.4 for running the package target in build.xml -- Key: VELOCITY-521 URL: https://issues.apache.org/jira/browse/VELOCITY-521 Project: Velocity Issue Type: Bug Components: Build Affects Versions: 1.6 Environment: all Reporter: Antoine Levy-Lambert Assigned To: Will Glass-Husain Priority: Minor Attachments: patch.txt build.xml target package forces to use exactly JDK 1.4. Would it not be better to build with target=1.4, source=1.4 and to simply check that the JDK version is = 1.4 I will attach a patch to this effect. Regards, Antoine -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-464) Finish the user guide
[ https://issues.apache.org/jira/browse/VELOCITY-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Glass-Husain updated VELOCITY-464: --- Fix Version/s: (was: 1.5) 1.6 Finish the user guide - Key: VELOCITY-464 URL: https://issues.apache.org/jira/browse/VELOCITY-464 Project: Velocity Issue Type: Sub-task Components: Documentation Affects Versions: 1.5 Reporter: Henning Schmiedehausen Assigned To: Henning Schmiedehausen Fix For: 1.6 Docbook based user guide. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-520) \u0061 causes lexer exception
[
https://issues.apache.org/jira/browse/VELOCITY-520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Glass-Husain updated VELOCITY-520:
---
Fix Version/s: 1.6
\u0061 causes lexer exception
---
Key: VELOCITY-520
URL: https://issues.apache.org/jira/browse/VELOCITY-520
Project: Velocity
Issue Type: Bug
Affects Versions: 1.5 beta2
Reporter: Stepan Koltsov
Priority: Minor
Fix For: 1.6
The test:
===
public void testU() throws Exception {
VelocityEngine ve = new VelocityEngine();
ve.init();
Context context = new VelocityContext();
StringWriter writer;
writer = new StringWriter();
ve.evaluate(context, writer, test,#set($v = \\\u0061\)$v);
//assertEquals(a, writer.toString());
}
===
I think \u0061 shoud produce a, see VELOCITY-519. But if not, this should
produce string \u0061, literally, but not exception, as now.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-447) add documentation to explain precedence for resolving property
[ https://issues.apache.org/jira/browse/VELOCITY-447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Glass-Husain updated VELOCITY-447: --- Fix Version/s: 1.6 marking for version 1.6 so we can track this add documentation to explain precedence for resolving property -- Key: VELOCITY-447 URL: https://issues.apache.org/jira/browse/VELOCITY-447 Project: Velocity Issue Type: Improvement Components: Documentation Environment: document Reporter: Jian Chen Assigned To: Henning Schmiedehausen Priority: Minor Fix For: 1.6 The Velocity user guide is not clear about the precedence for resolving the property of a variable. As in the UberspectImpl.java code, the precedence to resolve a property should be something like in this order: getbar() getBar() get(bar) isBar() This information will be very useful to the user. I suggest that this is added to the user guide under the Properties section. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (VELOCITY-522) Remove Anakia and Texen from Engine distribution
Remove Anakia and Texen from Engine distribution Key: VELOCITY-522 URL: https://issues.apache.org/jira/browse/VELOCITY-522 Project: Velocity Issue Type: New Feature Components: Anakia, Build, Texen Reporter: Will Glass-Husain Priority: Minor Fix For: 1.6 I'd like to see us create separate builds and release cycles for Texen and Anakia now that we are TLP. ((I thought an issue already existed for this, but couldn't find it) In particular, Texen seems to have a minimal user base at this point. Be nice to have a separate release that is stable and mature, take it out of the Velocity upgrade cycle. If the user community gets excited about it again in the future, it'll be easy to add features and issue a new release. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
