[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_12475835
]
Christoph Reck commented on VELOCITY-519:
-
If inserting automatic translation of unicode characters work, the template
writer might predefine and use $tab, $CR, $LF constants instead of \t, \r \n
thus keeping BC.
#set( $tab = \u0009 )
...
#if( $samplestring.contains($tab) )
P.S. in the past I used the UrlDecoder to achieve this.
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
Fix For: 1.6
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] 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_12475897
]
Nathan Bubna commented on VELOCITY-519:
---
The only consensus here is that we should fix the lexer error when \u
appears in a string definition. This would be Stepan's second attached patch.
And yes, this will allow you to insert tabs, carriage returns and line feeds by
typing *six* characters for each instead of just typing the one tab, CR or LF
character. why do:
#set( $tab = \u0009 )
which doesn't even work yet, when
#set( $tab =)
already works?
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
Fix For: 1.6
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]
Re: [Tools] Some proposals for Tools 2.0
On 2/25/07, Claude Brisson [EMAIL PROTECTED] wrote:
Hi there!
Here are some structural evolutions I'd like to discuss before any
coding. I'm pretty sure that the first one is a good option - the second
one is more prospective.
1. On-demand tools loading: instead of a standard HashMap, the idea here
is to have a ToolMap, inheriting HashMap, which will instanciate a tool
from its toolinfo only when the generic getter is called. This should be
a quite interesting performance gain in some situations. We maybe need
some attribute to have tools instanciated at toolbox initialization
('instanciate-on-load' ?).
I really like the idea! Though, i think i might prefer to call it a
Toolbox instead of ToolMap. just to stick with the metaphor... :)
2. View tools: other objects in my webapp are often jealous of the view
servlet. They also would like to use some of the tools. Session scoped
tools can be reached via the session, but it's not the case for
application or request scoped tools. To achieve this, there would be two
things to do:
- the application tools map should be stored as a ServletContext
attribute and the request tools map as a Request attribute.
- the constitution of the three scoped maps should be decorrelated from
the remaining of the processing so that it could potentially take place
in a servlet filter.
i agree we should find a way to solve this, though i'm not sure i
fully understand the second part of your proposed implementation. i
would think we would simply want to create a Toolbox (as in idea #1)
for each scope, place the proper Toolbox in the attributes of the
request/session/servletcontext and then just make our ChainedContext
smart enough to search in all of those for tools that are requested.
i don't see why we need a filter or to constitute the three toolboxes
at all.
oh, and with this, we may want to re-organize the layout of a
toolbox.xml file to lump the tools from the three scopes together in
their toolboxes. but that's a separate issue...
i predict there are going to be some interesting complications/side
effects, but we'll be able to see those better once we start coding.
i'll try and get a 2.x branch set up today (or soon, if i don't get to
it). Then we can start hacking away. i have some other ideas and
major changes in mind and already have some code for them too. i'm
excited about the possibilities...
Thanks for your remarks,
Claude
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Velocity Wiki] Trivial Update of Velocity15ReleaseNotes by NathanBubna
Dear Wiki user, You have subscribed to a wiki page or wiki category on Velocity Wiki for change notification. The following page has been changed by NathanBubna: http://wiki.apache.org/velocity/Velocity15ReleaseNotes -- === Other Notes === - * The documentation has been significantly improved. Please note that many but not all new beta features are written up. + * The documentation has been significantly improved. Please note that many but not all new features are written up. * !VelocityServlet is now officially deprecated. Please use [http://jakarta.apache.org/velocity/tools/view/ VelocityViewServlet] from the VelocityTools subproject instead. * !VelocityFormatter is also deprecated. Please use the various formatting tools in the VelocityTools subproject. * An optional Maven build is now available. However, ant remains the primary build tool. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-223) VMs that use a large number of directives and macros use excessive amounts of memory - over 4-6MB RAM per form
[ https://issues.apache.org/jira/browse/VELOCITY-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475913 ] Ryan Smith commented on VELOCITY-223: - 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. 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 VMs that use a large number of directives and macros use excessive amounts of memory - over 4-6MB RAM per form -- Key: VELOCITY-223 URL: https://issues.apache.org/jira/browse/VELOCITY-223 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.3.1 Environment: Operating System: All Platform: All Reporter: Christian Nichols Fix For: 1.6 Attachments: VelocityMemory.JPG Our application FinanceCenter is based on Velocity as the template engine. We have a library of about 200 macros and about 400 VM files. Because the velocity parser copies the macro body into the VM during parsing, macros that are frequently used (even though identical and using local contexts) use up large amounts of memory. On our Linux server (running Redhat 7.2 with Sun JDK 1.4.1_04) we can easily use up over 1GB of RAM simply by opening up many forms (about 150) - the server starts out using 60MB after startup. This memory times out after 5 minutes and is returned which tells me that it is screen memory. Our problem is that the NT JVM and Linux JVM (32 bit) are currently limited to about 1.6 - 2.0 GB of ram for heap space. Thus, using a fair number of forms in the application leaves little space for user session data. We have implemented a caching mechanism for compiled templates and integrated it into Velocity so that cached objects are timed out of the cache but the server is still using large amounts of memory. We finally had to rewrite many of our macros into Java so that memory usage would be reduced (note that these macros were doing complex screen formatting not business logic). Doing this has reduced our memory by about 30%. This is currently our biggest issue with Velocity and is causing us to review our decision to stay with Velocity going forward. This is because we will likely end up with close to 1,000 forms by the end of next year and need to know that Velocity can deal with this. Is there any work underway to share compiled macro AST's? This would greatly reduce the amount of memory used. I have reviewed the parser code that is doing this but it seems that this is an embedded part of the design and not easily changed. -- 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]
[Velocity Wiki] Update of VelocityTools2Planning by NathanBubna
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Velocity Wiki for
change notification.
The following page has been changed by NathanBubna:
http://wiki.apache.org/velocity/VelocityTools2Planning
The comment on the change is:
put example toolbox in code box
--
3. SimplifiedToolboxXML: In line with the ideas above, we could cut out some
repetition in toolbox.xml by better organizing it and using XML more
appropriately. For instance, the
[http://svn.apache.org/viewvc/velocity/tools/trunk/examples/simple/WEB-INF/toolbox.xml?revision=487337view=markup
toolbox.xml for the simple example] could be simplified further to something
like:
- tools
+ {{{tools
toolbox scope=request xhtml=true
tool key=toytool class=ToyTool valid-path=index.vm/
/toolbox
-
toolbox scope=session create-session=true
tool key=map class=java.util.HashMap/
/toolbox
-
toolbox scope=application
tool key=date class=org.apache.velocity.tools.generic.DateTool/
data type=number key=version value=1.1/
@@ -28, +26 @@
data key=barthis is bar./data
/toolbox
/tools
+ }}}
4. FactorOutBasicVelocityViewStuff: This would create a better basis for
bring the [http://velocity.apache.org/engine/devel/veltag.html Veltag] into the
project as a sibling of the VelocityViewServlet.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Velocity Wiki] Update of VelocityTools2Planning by NathanBubna
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Velocity Wiki for
change notification.
The following page has been changed by NathanBubna:
http://wiki.apache.org/velocity/VelocityTools2Planning
The comment on the change is:
create page to track and organize ideas for tools 2.x
New page:
== Ideas For VelocityTools 2.x ==
1. TransparentOnDemandToolsLoading: Instead of a standard HashMap, the idea
here is to have a Toolbox, perhaps inheriting HashMap, which will instantiate a
tool from its tool-info only when the generic getter is called. This should be
a quite interesting performance gain in some situations. We maybe need some
attribute to have tools instantiated at toolbox initialization
('instantiate-on-load' ?). The Toolboxes may then pool or at least hold on to
instantiated tools for subsequent requests from the template or from other
parts of the webapp (see idea 2 below).
2. EasierToolAccessOutsideTemplates: Other objects in my webapp are often
jealous of the VelocityViewServlet. They also would like to use some of the
tools. Session scoped tools can be reached via the session, but it's not the
case for application or request scoped tools. To achieve this, there would be
two things to do:
- create a separate Toolbox for each scope and store it in the attributes of
the corresponding servlet API object (request-!ServletRequest,
session-!HttpSession, application-!ServletContext).
- the ChainedContext would know to search the attributes for these Toolboxes
and pass requests for the tools on to them. (NOTE: depending on the
implementation of idea 1 (above) it may be advantageous to have the
ChainedContext hold on to requested tools as templates often use them multiple
times
- We could create a simple utility to help other classes retrieve tools, so
they needn't all duplicate the code for finding the toolbox in the attributes
and then requesting the tool from the toolbox...
3. SimplifiedToolboxXML: In line with the ideas above, we could cut out some
repetition in toolbox.xml by better organizing it and using XML more
appropriately. For instance, the
[http://svn.apache.org/viewvc/velocity/tools/trunk/examples/simple/WEB-INF/toolbox.xml?revision=487337view=markup
toolbox.xml for the simple example] could be simplified further to something
like:
tools
toolbox scope=request xhtml=true
tool key=toytool class=ToyTool valid-path=index.vm/
/toolbox
toolbox scope=session create-session=true
tool key=map class=java.util.HashMap/
/toolbox
toolbox scope=application
tool key=date class=org.apache.velocity.tools.generic.DateTool/
data type=number key=version value=1.1/
data type=boolean key=isSimple value=true/
data key=foo value=this is foo./
data key=barthis is bar./data
/toolbox
/tools
4. FactorOutBasicVelocityViewStuff: This would create a better basis for bring
the [http://velocity.apache.org/engine/devel/veltag.html Veltag] into the
project as a sibling of the VelocityViewServlet.
5. SupportAlternateToolboxConfiguration: Not everyone likes XML. I'd like us
to make Toolbox management pluggable with provided support for configuration
via properties file as well as XML, and i want it to be easier to configure and
manage in Java as well.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory Footprint Help
Ryan, To my knowledge we have not done significant work on memory profiling with Velocity, this effort could be a big help. Some possible questions to investigate: * What classes are the memory hogs? The VM related files? Some of the particular AST files? * Which factors seem to tie up the most memory? Includes? Macros? * Does the size of the context matter? * Does the memory usage go up over time with continued compiling (e.g. is there a growing leak) WILL On 2/26/07, Ryan Smith [EMAIL PROTECTED] wrote: I have posted the picture and attached it to bug (http://issues.apache.org/jira/browse/VELOCITY-223). The picture was there to simply illustrate the size of the velocity library file. I've done the same tests with the 1.5beta2 and the results are the same although there is a noticeable difference in performance from a speed perspective. From a memory footprint perspective 1.5 is about 1% larger than 1.4. The pages were continuously being compiled because they were not in the cache since the cache size needed to be small to keep the memory footprint down. It wasn't the fault of any of the velocity code. At this time I am not that familiar with the Velocity code base but any assistance in where to start looking would be greatly appreciated. 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? I will do some more analysis of the memory, tokens, and directives and post the results to the JIRA bug. Thanks for your help. Ryan Smith -Original Message- From: Will Glass-Husain [mailto:[EMAIL PROTECTED] Sent: Saturday, February 24, 2007 7:47 PM To: Velocity Developers List Subject: Re: Memory Footprint Help Ryan, Unfortunately your picture was removed by the mail list software-- perhaps you can raise a JIRA issue on this and attach the image and data? To answer your question, we would welcome assistance on this issue. If you have time and motivation, please dig into this. We'd be happy to help answer any questions on the code and/or offer ideas if not more direct help. If performance increases and the regression tests continue to pass we will almost certainly commit relevant changes. One note though -- there were several bug fixes related to caching, synchronization, introspection, and other subtle issues for Velocity 1.5. This version will be released in the next few days, but if you work with Velocity 1.5beta2 it is almost the same thing. Have you checked results from Velocity 1.5beta2? If the pages are continuously compiled that means the cache is not working, correct? How are you determining this? WILL On 2/24/07, Ryan Smith [EMAIL PROTECTED] wrote: 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
