[jira] Resolved: (VELOCITY-383) Non thread-safe Template object can cause NPE under heavy concurrent load
[ http://issues.apache.org/jira/browse/VELOCITY-383?page=all ] Henning Schmiedehausen resolved VELOCITY-383. - Resolution: Fixed Looking at the stack trace and the source code makes me pretty confident, that this is the same problem as per VELOCITY-24 in (thinly veiled) disguise. So I'd say that it is fixed (and load testing with 20 templates running nested loops and five to fifty parallel requests do not report any problems). Non thread-safe Template object can cause NPE under heavy concurrent load - Key: VELOCITY-383 URL: http://issues.apache.org/jira/browse/VELOCITY-383 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.4 Environment: Operating System: Windows XP Platform: PC Reporter: Hans Assigned To: Henning Schmiedehausen Priority: Blocker Fix For: 1.5 Attachments: Example.java During load testing the server, with 50 concurrent users, the VelocityViewServlet would throw a null pointer exception about 3% of the time. 97% of the time, the page would serve normally. Below is the trace: java.lang.NullPointerException at org.apache.velocity.runtime.parser.node.ASTDirective.init (ASTDirective.java:94) at org.apache.velocity.runtime.parser.node.SimpleNode.init (SimpleNode.java:201) at org.apache.velocity.Template.initDocument(Template.java:199) at org.apache.velocity.Template.process(Template.java:124) at org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource (ResourceManagerImpl.java:423) at org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource (ResourceManagerImpl.java:341) at org.apache.velocity.runtime.RuntimeInstance.getTemplate (RuntimeInstance.java:831) at org.apache.velocity.runtime.RuntimeInstance.getTemplate (RuntimeInstance.java:813) at org.apache.velocity.runtime.RuntimeSingleton.getTemplate (RuntimeSingleton.java:285) at org.apache.velocity.tools.view.servlet.VelocityViewServlet.getTemplate (VelocityViewServlet.java:540) at org.apache.velocity.tools.view.servlet.VelocityViewServlet.handleRequest (VelocityViewServlet.java:475) at org.apache.velocity.tools.view.servlet.VelocityViewServlet.doRequest (VelocityViewServlet.java:407) at org.apache.velocity.tools.view.servlet.VelocityViewServlet.doPost (VelocityViewServlet.java:383) at javax.servlet.http.HttpServlet.service(HttpServlet.java:709) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:157) at org.apache.catalina.core.ApplicationDispatcher.invoke (ApplicationDispatcher.java:674) at org.apache.catalina.core.ApplicationDispatcher.doInclude (ApplicationDispatcher.java:576) at org.apache.catalina.core.ApplicationDispatcher.include (ApplicationDispatcher.java:501) at org.apache.velocity.tools.view.ImportSupport.acquireString (ImportSupport.java:140) at org.apache.velocity.tools.struts.TilesTool.doInsert (TilesTool.java:476) at org.apache.velocity.tools.struts.TilesTool.doInsert (TilesTool.java:419) at org.apache.velocity.tools.struts.TilesTool.processUrl (TilesTool.java:398) at org.apache.velocity.tools.struts.TilesTool.processAsDefinitionOrURL (TilesTool.java:357) at org.apache.velocity.tools.struts.TilesTool.processObjectValue (TilesTool.java:305) at org.apache.velocity.tools.struts.TilesTool.get(TilesTool.java:135) at sun.reflect.GeneratedMethodAccessor136.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.velocity.runtime.parser.node.GetExecutor.execute (GetExecutor.java:65) at org.apache.velocity.util.introspection.UberspectImpl$VelGetterImpl.invoke (UberspectImpl.java:302) at org.apache.velocity.runtime.parser.node.ASTIdentifier.execute (ASTIdentifier.java:157) at org.apache.velocity.runtime.parser.node.ASTReference.execute (ASTReference.java:175) at org.apache.velocity.runtime.parser.node.ASTReference.render (ASTReference.java:220) at org.apache.velocity.runtime.parser.node.SimpleNode.render (SimpleNode.java:230) at org.apache.velocity.Template.merge(Template.java:256) at org.apache.velocity.tools.view.servlet.VelocityViewServlet.mergeTemplate (VelocityViewServlet.java:592) at org.apache.velocity.tools.view.servlet.VelocityViewServlet.doRequest (VelocityViewServlet.java:417) at
[jira] Assigned: (VELOCITY-366) Need verification of velocity templates to assure that non-UTF-8 characters are flagged for repair
[ http://issues.apache.org/jira/browse/VELOCITY-366?page=all ] Henning Schmiedehausen reassigned VELOCITY-366: --- Assignee: Henning Schmiedehausen Need verification of velocity templates to assure that non-UTF-8 characters are flagged for repair -- Key: VELOCITY-366 URL: http://issues.apache.org/jira/browse/VELOCITY-366 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.4 Environment: Operating System: Linux Platform: All Reporter: Ilango Assigned To: Henning Schmiedehausen Fix For: 1.5 There seem to be problem in interpolating the template when we add non-UTF characters in the velocity templates. A typical synario where we faced this issue was that a welcome message e-mail (velocity template) was missing the content portion as it contained the charecter . We could reproduce the problem consistently by adding this charecter in the velocity template. It would be great if we get velocity to handle these type of data as there is a possibility of making the contents look weird otherwise. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VELOCITY-366) Need verification of velocity templates to assure that non-UTF-8 characters are flagged for repair
[ http://issues.apache.org/jira/browse/VELOCITY-366?page=all ] Henning Schmiedehausen resolved VELOCITY-366. - Resolution: Cannot Reproduce Ok, so this is what I did: I prepared two files, both contain umlauts, one in ISO, one in UTF-8 encoding. I verified that both files really contain characters in that encoding (ah, the joys of emacs). I iterated through all combinations of input.encoding and output encoding in velocity properties for a VelocityViewServlet with the following results: - When the input.encoding is set correctly, the corresponding file is read correctly. - When the output.encoding is set, the resulting page will have that encoding, no matter what the input encoding was. As long as input.encoding and the actual charset match, the result will be correctly encoded. If you set the input and output encoding to e.g. ISO-8859 and then try to process an UTF-8 template, then the result will contain UTF-8 characters. This is not Velocity's fault but a configuration error. If you set input.encoding to UTF-8, then the umlauts will be correctly converted to iso. So, for me, the conversion of chars does work. It might be possible that this was broken in earlier versions (actually doubt it) or that you simply mixed up file encodings and input and output encodings. Yes, multi-charset support is not really strong in Velocity, so I would recommend using UTF-8 everywhere (unfortunately then you do have to add the encoding to the properties file, because the default is iso-8859-1 Need verification of velocity templates to assure that non-UTF-8 characters are flagged for repair -- Key: VELOCITY-366 URL: http://issues.apache.org/jira/browse/VELOCITY-366 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.4 Environment: Operating System: Linux Platform: All Reporter: Ilango Assigned To: Henning Schmiedehausen Fix For: 1.5 There seem to be problem in interpolating the template when we add non-UTF characters in the velocity templates. A typical synario where we faced this issue was that a welcome message e-mail (velocity template) was missing the content portion as it contained the charecter . We could reproduce the problem consistently by adding this charecter in the velocity template. It would be great if we get velocity to handle these type of data as there is a possibility of making the contents look weird otherwise. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VELOCITY-219) Velocity list operator should return a Java List reference rather than ArrayList reference
[ http://issues.apache.org/jira/browse/VELOCITY-219?page=all ] Henning Schmiedehausen resolved VELOCITY-219. - Resolution: Invalid Ok, after some debugging and code browsing, I'm a bit confused. The ArrayList object comes out of ASTObjectArray#value() (for the normal array case) or ASTIntegerRange#value() for the range ([1..10]) case. They both create an ArrayList object. However, the actual API *is* Object value(InternalContextAdapter context), so there is no guarantee that this will be any assumed type anyway. We do have not a single method (at least none that I could find) that returns an explicit ArrayList anywhere. We have a very very small number of explicit ArrayList variable declarations that I will change to List. But aside from that I see nothing that we could/must change for API 2.0. If you have more information, please reopen that issue. Thanks. Velocity list operator should return a Java List reference rather than ArrayList reference -- Key: VELOCITY-219 URL: http://issues.apache.org/jira/browse/VELOCITY-219 Project: Velocity Issue Type: Improvement Components: Engine Affects Versions: 1.4 Environment: Operating System: All Platform: All Reporter: Daniel Rall Priority: Minor Fix For: 1.5 In the 1.x releases of Velocity, the list operator [] returns an ArrayList reference instead of a List reference. In the future (2.x), a cleaner API would be to return a List reference. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (VELOCITY-262) #set not parsed in #macro
[ http://issues.apache.org/jira/browse/VELOCITY-262?page=all ] Henning Schmiedehausen reassigned VELOCITY-262: --- Assignee: Henning Schmiedehausen #set not parsed in #macro - Key: VELOCITY-262 URL: http://issues.apache.org/jira/browse/VELOCITY-262 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.4 Environment: Operating System: All Platform: PC Reporter: Mike Kienenberger Assigned To: Henning Schmiedehausen Priority: Minor Fix For: 1.5 Attachments: output.htm, scheduledPaymentsTable.macro.txt #set statements are not being parsed in #macros in VM_global_library. Worked in 1.3.1, doesn't in 1.4. I'm going to attach the #macro and the diff'd 1.3.1 vs 1.4 output. -Mike -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-262) #set not parsed in #macro
[ http://issues.apache.org/jira/browse/VELOCITY-262?page=comments#action_12447540 ] Henning Schmiedehausen commented on VELOCITY-262: - I built a small test bed using --- cut --- #macro(issue262 $baz) #set ($bar = $baz) #set ($foo = inside macro!) #end --- cut --- in the global macros file and --- cut --- pre $foo #issue262(from macro) $foo $bar #set ($foo = foo) #set ($bar = empty) $foo $bar #issue262(from macro2) $foo $bar /pre --- cut --- as template. This rendered as: --- cut --- $foo inside macro! from macro foo empty inside macro! from macro2 --- cut --- So 1) $foo was unset (the macro definition in the global macros file did not change this value in any way) 2) $foo and $bar were set (changed) inside the macro. This is visible on the outside as $foo and $bar changed values. 3) $foo and $bar could be changed on the template to other values. 4) running the macro again (with another value for the parameter resulted in another value for $bar. So re-evaluating the macro does change the value of the reference. Works as expected, if you ask me. Any comments / could you try your case with Velocity 1.5? I tend to close the case as cannot reproduce. #set not parsed in #macro - Key: VELOCITY-262 URL: http://issues.apache.org/jira/browse/VELOCITY-262 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.4 Environment: Operating System: All Platform: PC Reporter: Mike Kienenberger Assigned To: Henning Schmiedehausen Priority: Minor Fix For: 1.5 Attachments: output.htm, scheduledPaymentsTable.macro.txt #set statements are not being parsed in #macros in VM_global_library. Worked in 1.3.1, doesn't in 1.4. I'm going to attach the #macro and the diff'd 1.3.1 vs 1.4 output. -Mike -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (VELOCITY-285) reference within macro and foreach is incorrect
[ http://issues.apache.org/jira/browse/VELOCITY-285?page=all ] Henning Schmiedehausen reassigned VELOCITY-285: --- Assignee: Henning Schmiedehausen reference within macro and foreach is incorrect --- Key: VELOCITY-285 URL: http://issues.apache.org/jira/browse/VELOCITY-285 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.4 Environment: Operating System: other Platform: Other Reporter: Gilles Scokart Assigned To: Henning Schmiedehausen Priority: Minor Fix For: 1.5 It seems that there is a bug when we have loop into a recursive macro. Here is the test I run : #macro (test_loop $p) call to test_loop ($p) #foreach($child in $p) in the loop the param should not be changed : ($p) #test_loop($child) #end return #end #set($l1=[a]) #set($l = [$l1]) #test_loop($l) It produce: call to test_loop ([[a]]) in the loop the param should not be changed : ([[a]]) call to test_loop ([a]) in the loop the param should not be changed : (a) call to test_loop (a) return return return IMHO, it should be call to test_loop ([[a]]) in the loop the param should not be changed : ([[a]]) call to test_loop ([a]) in the loop the param should not be changed : ([a]) call to test_loop (a) return return return The difference is in the second recusive call. I don't know why, but it seems that the instruction #foreach($child in $p) has modified $p that contains the value of $child. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VELOCITY-285) reference within macro and foreach is incorrect
[ http://issues.apache.org/jira/browse/VELOCITY-285?page=all ] Henning Schmiedehausen resolved VELOCITY-285. - Resolution: Fixed Hm, that actually is a scary problem. I wonder why loops nested like this ever worked at all. Anyway, I did a minor change to the InternalWrapperContext that allows foreach to force its loop variable to be a part of the local (VM) context. That fixes this problem. Thanks a lot for reporting, sorry that it took us so long to fix it. reference within macro and foreach is incorrect --- Key: VELOCITY-285 URL: http://issues.apache.org/jira/browse/VELOCITY-285 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.4 Environment: Operating System: other Platform: Other Reporter: Gilles Scokart Assigned To: Henning Schmiedehausen Priority: Minor Fix For: 1.5 It seems that there is a bug when we have loop into a recursive macro. Here is the test I run : #macro (test_loop $p) call to test_loop ($p) #foreach($child in $p) in the loop the param should not be changed : ($p) #test_loop($child) #end return #end #set($l1=[a]) #set($l = [$l1]) #test_loop($l) It produce: call to test_loop ([[a]]) in the loop the param should not be changed : ([[a]]) call to test_loop ([a]) in the loop the param should not be changed : (a) call to test_loop (a) return return return IMHO, it should be call to test_loop ([[a]]) in the loop the param should not be changed : ([[a]]) call to test_loop ([a]) in the loop the param should not be changed : ([a]) call to test_loop (a) return return return The difference is in the second recusive call. I don't know why, but it seems that the instruction #foreach($child in $p) has modified $p that contains the value of $child. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-168) RFE: switch to commons-logging
[ http://issues.apache.org/jira/browse/VELOCITY-168?page=all ]
Henning Schmiedehausen updated VELOCITY-168:
Bugzilla Id: (was: 19140)
Component/s: Engine
(was: Source)
RFE: switch to commons-logging
--
Key: VELOCITY-168
URL: http://issues.apache.org/jira/browse/VELOCITY-168
Project: Velocity
Issue Type: Improvement
Components: Engine
Affects Versions: 1.4
Environment: Operating System: All
Platform: All
Reporter: Jens Elkner
Fix For: 2.0
Actually having a quick look at the logging capabilities/usage of velocity,
I feel, that this one makes the package quite unstable and even defeats or
complicates the usage of most wanted features of several logging system,
no matter whether jdk, log4j or Avalon/logkit (e.g. source location, since
everything is tunneled through a very limitted LogSystem, logging
stacktraces).
No matter, how one winds the velocity log wrapper, only in some cases, one
gets
the behavior, he expects from his logging system.
IMHO, velocity developers should not have to cope with a new LogSystem over
another one, since there is no need to do that and the new one is only
a limitted wrapper [for a wrapper for a wrapper ...] for another LogSystem.
As seen (BUGs 19131,19133,19335,19336,19337), this introduces incompleteness,
is cumbersum, halfhearted and another point of unstability/failure/bugs.
So, I suggest to make a transition to one ultra-thin and easy to use wrapper:
the Jakarta Commons Logging package (JCL).
Advantages are clear: Everyone can still plugin the Log system of its choice,
no matter whether jdk1.4, log4j, logkit or any other. Furthermore,
velocity developers can use log.{trace|...|fatal} by just inserting 3 Lines
into their classes and do not need to care about setting up and configuring
the LogSystem, which is actually wrapped. So they can focus on the real
job (velocity) and do not have to take care of the dozen of log systems
flying around.
Also this reduces dependencies and thus point of failures on certain
log sys, since even if the user/developer is not required to configure
anything, since JCL sets up the wrapper in that case: Log4J or JDK1.4
or as fallback a SimpleLog, which just System.err.print()s all messages.
So there is always one available and no-one should have to use System.err
or system.out to print out stack traces and/or error messages!
So, what do you think?
If you want me to do that, no problem - just drop me a note.
For more information wrt. JCL, see
http://jakarta.apache.org/commons/logging.html .
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-223) VMs that use a large number of directives and macros use excessive amounts of memory - over 4-6MB RAM per form
[ http://issues.apache.org/jira/browse/VELOCITY-223?page=all ] Henning Schmiedehausen updated VELOCITY-223: Bugzilla Id: (was: 24375) Component/s: Engine (was: Source) Fix Version/s: 1.6 Assignee: (was: Velocity-Dev List) 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: http://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 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. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-253) Enhance whitespace gobbling
[ http://issues.apache.org/jira/browse/VELOCITY-253?page=all ] Henning Schmiedehausen updated VELOCITY-253: Bugzilla Id: (was: 27413) Component/s: Engine (was: Source) Enhance whitespace gobbling --- Key: VELOCITY-253 URL: http://issues.apache.org/jira/browse/VELOCITY-253 Project: Velocity Issue Type: Wish Components: Engine Affects Versions: 1.0-Release Environment: Operating System: other Platform: Other Reporter: Christoph Reck Fix For: 2.0 I expect that when adding velocity markup to an existing text file to not affect the spacing in the output. This includes indented #foreach directives and inner indented #if/#set/#macro directives. So the rule I proposed was to allow adding velocity markup, one per line, and still have the same output - e.g. add an #if statement around existing text to conditionally mask it out. Or add an #foreach around a table row and be able to repeat the body with dynamic data, etc. As sonn as a directive is placed wihtin other text in the same line, any whitespace around it should remain untouched. If a line is looks like this: DirectiveLine ::= LineEnd TabsAndSpaces? Directive TabsAndSpaces? LineEnd TabsAndSpaces ::= (#x20 | #x09)+ LineEnd ::= StartOfStream | ((#x0D #x0A) | #x0D | #x0A) | EndOfStream then the first TabsAndSpaces? and the closing TabsAndSpaces? LineEnd should be gobbled. (Note that it supports multiline directives, that is why DirectiveLine is not simply Line.) If you whant the first LineEnd to be gobbled prepend a ## before it (makes the EOL part of the previous line!). This has been an isse since velocity birth and discussed in many user and developer threads. Some users agree with my proposals, some say that velocity sould not touch any whitespaces and a code formatter should be run after the template rendering. The proposal is not 100% BC, but a switch could allow the classic style (by default), or to pass all whitespaces. A new directive could be created to control the gobbling for the enclosed parts within a template. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-340) removal of o.a.v.runtime.configuration.Configuration?
[ http://issues.apache.org/jira/browse/VELOCITY-340?page=all ] Henning Schmiedehausen updated VELOCITY-340: Bugzilla Id: (was: 33194) Component/s: Engine (was: Source) removal of o.a.v.runtime.configuration.Configuration? - Key: VELOCITY-340 URL: http://issues.apache.org/jira/browse/VELOCITY-340 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.5 Environment: Operating System: Windows XP Platform: PC Reporter: Shinobu Kawai Fix For: 2.0 This class has been deprecated since 1.1. Any plans for removal? Mark this bug WONTFIX if none. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-355) lost '#'s inside #literal()/#end
[ http://issues.apache.org/jira/browse/VELOCITY-355?page=all ]
Henning Schmiedehausen updated VELOCITY-355:
Bugzilla Id: (was: 33590)
Component/s: Engine
(was: Source)
Fix Version/s: 2.0
(was: 1.6)
This is one of the quirks in the current parser. Yes, it sucks. However, I'm
not sure that we can amend that behaviour short of a complete parser rewrite.
For that I postpone it to 2.0.
lost '#'s inside #literal()/#end
Key: VELOCITY-355
URL: http://issues.apache.org/jira/browse/VELOCITY-355
Project: Velocity
Issue Type: Bug
Components: Engine
Affects Versions: 1.4
Environment: Operating System: All
Platform: All
Reporter: Geoffrey Lowney
Fix For: 2.0
I am using VTL (with VPP) to customize a portion of a Perl script. Since Perl
code has a lot of dollar signs, I am using #literal()/#end to prevent Velocity
from processing most of the file. What I find is that single '#' characters
that are not followed by alpha text are removed (inside #literal()/#end).
For example:
#literal()
#!/usr/bin/perl
#end
becomes:
!/usr/bin/perl
I've tried things like escaping the '#' ('\#') but that leaves the backslash
('\#!/usr/bin/perl' becomes '\!/usr/bin/perl'). Nothing seems to work.
I can use a #set to define a variable with the value '#!/usr/bin/perl', but I
was hoping I would not have to. It also doesn't help with other single #'s in
the file (like Perl comments). For those I have had to double up the hashes.
I'd be happy to try patching the Velocity source, but I had trouble making
heads
or tails of the parser engine?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VELOCITY-379) foreach should generalise for Iterable, not just Collection
[ http://issues.apache.org/jira/browse/VELOCITY-379?page=all ] Henning Schmiedehausen resolved VELOCITY-379. - Fix Version/s: 1.5 (was: 2.0) Resolution: Fixed Assignee: Henning Schmiedehausen For Velocity 1.5 you can use a custome Uberspector to be able to iterate on Iterable. There is example code on how to do this in whiteboard/henning/jdk15 and an actual implementation in whiteboard/henning/jdk15/src/java/org/apache/velocity/util/introspection/JDK15UberspectImpl.java foreach should generalise for Iterable, not just Collection --- Key: VELOCITY-379 URL: http://issues.apache.org/jira/browse/VELOCITY-379 Project: Velocity Issue Type: Bug Components: Source Affects Versions: 1.5 Environment: Operating System: All Platform: All Reporter: David Blaikie Assigned To: Henning Schmiedehausen Fix For: 1.5 As of Java 1.5 the java.lang.Iterable interface is the general contract that should be used when looking for things that provide Iterators. This allows for user defined non collection types to be generally usable by things that just need iteration such as the Java Language's for(X x : y) looping construct and seems perfectly applicable to the velocity Foreach directive. I'm not sure of the versioning policy (which java version) of Velocity so if you are deliberately not creating a 1.5 dependency then this is not a bug. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-450) Reduce memory usage for Velocity templates
[ http://issues.apache.org/jira/browse/VELOCITY-450?page=all ] Henning Schmiedehausen updated VELOCITY-450: Component/s: Engine (was: Source) Fix Version/s: 1.6 Memory usage is an issue that moves higher and higher on the prio list for 1.6. Retargetting the bug report there. Reduce memory usage for Velocity templates -- Key: VELOCITY-450 URL: http://issues.apache.org/jira/browse/VELOCITY-450 Project: Velocity Issue Type: Wish Components: Engine Affects Versions: 1.4 Environment: Windows 2000, Jdk1.4.2, Tomcat4.1.29 Reporter: coumaravel Fix For: 1.6 Hi, We are using the velocity templates extensively to generate HTML reports. Normally our templates size on the Disk is around 20-50kb, when it gets loaded into Application(Tomcat) memory it turns to 3-5MB. As of now we have 500 templates, in near future we are planning to increase this to 1500. Any Idea why this is happening. Any help in this is much appreciated, as this is becoming a bottleneck for the scalability of our application. Thanks in advance. Regards, Coumar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-454) clean up escaping to always escape \$ and \#
[ http://issues.apache.org/jira/browse/VELOCITY-454?page=all ]
Henning Schmiedehausen updated VELOCITY-454:
Component/s: Engine
(was: Source)
clean up escaping to always escape \$ and \#
Key: VELOCITY-454
URL: http://issues.apache.org/jira/browse/VELOCITY-454
Project: Velocity
Issue Type: Improvement
Components: Engine
Affects Versions: 1.4, 1.5
Reporter: Bjoern Guenzel
Fix For: 1.6, 2.0
Attachments: testVelocity.vm
I want to use Velocity to generate a template for UJAC, which uses a very
similiar templating language to Velocity. Therefore escaping is a primary
concern.
I am surprised that there seems to be no way to just escape $ and # in
general.
Suppose we have the line \$name
If name is in the context, this will evaluate to $name, otherwise it will
evaluate to \$name
The real problem starts if there is something to escaped like
${something == 3} (this is something that might occur in a UJAC template)
This gives an error in both cases: ${something == 3} and \${something == 3}
both give an error (} expected or something like that).
My guess is that Velocity get's confused when trying to evaluate something
== 3 to see if it is something that is known and should be escaped or
something that is unknown and should not be escaped.
In my opinion the proper behaviour for escaping characters would be to ALWAYS
escape, independent of the context.
Even if the current way of escaping would work in all cases, there would be a
major problem with it. I can't give the velocity template to the Designer,
because only the developer knows all the variables that exist in the context.
So the designer is unable to properly escape all the variables. I think it
would be important to have a way to simply escape everything.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-465) Finish the developers guide
[ http://issues.apache.org/jira/browse/VELOCITY-465?page=all ] Henning Schmiedehausen updated VELOCITY-465: Component/s: Documentation Finish the developers guide --- Key: VELOCITY-465 URL: http://issues.apache.org/jira/browse/VELOCITY-465 Project: Velocity Issue Type: Sub-task Components: Documentation Reporter: Henning Schmiedehausen Docbook based developers guide. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-464) Finish the user guide
[ http://issues.apache.org/jira/browse/VELOCITY-464?page=all ] Henning Schmiedehausen updated VELOCITY-464: Component/s: Documentation Finish the user guide - Key: VELOCITY-464 URL: http://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.5 Docbook based user guide. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-437) Intercept output of objects
[ http://issues.apache.org/jira/browse/VELOCITY-437?page=all ] Henning Schmiedehausen updated VELOCITY-437: Component/s: Engine Intercept output of objects --- Key: VELOCITY-437 URL: http://issues.apache.org/jira/browse/VELOCITY-437 Project: Velocity Issue Type: New Feature Components: Engine Affects Versions: 1.4 Reporter: Ståle Undheim Priority: Minor Fix For: 1.6 Attachments: valuewriter.patch Currently, all reference objects in a Velocity template file are put out using the objects toString method, with no means to control this mechanism. I propose to change this by having interceptors that can pick up variables before they are run .toString on, and write them using their own means instead. If I figure out how to attach files to this after posting, I will add a patch with all the code necessary to implement this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-62) Macro scope nesting
[ http://issues.apache.org/jira/browse/VELOCITY-62?page=all ] Henning Schmiedehausen updated VELOCITY-62: --- Bugzilla Id: (was: 7899) Component/s: Engine (was: Source) Macro scope nesting --- Key: VELOCITY-62 URL: http://issues.apache.org/jira/browse/VELOCITY-62 Project: Velocity Issue Type: Improvement Components: Engine Affects Versions: 1.2 Environment: Operating System: other Platform: All Reporter: Steven Hugg Priority: Minor Fix For: 1.6 A problem with recursing macros is that scopes are not nested when velocimacro.context.localscope is set to true. That is, a get() on a context does not percolate to a parent context if the get() returns null. This prevents accessing global variables in the context. The desired behavior (IMHO) would be for set()s to be local to the macro, and get()s to percolate up to the parent if not found. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-102) Add Support for Static Utility Classes
[ http://issues.apache.org/jira/browse/VELOCITY-102?page=all ]
Henning Schmiedehausen updated VELOCITY-102:
Bugzilla Id: (was: 11924)
Component/s: Engine
(was: Source)
Fix Version/s: 1.6
Assignee: (was: Velocity-Dev List)
Shouldn't be too hard to implement. I like the StaticWrapper idea. Schedule it
for 1.6
Add Support for Static Utility Classes
--
Key: VELOCITY-102
URL: http://issues.apache.org/jira/browse/VELOCITY-102
Project: Velocity
Issue Type: Improvement
Components: Engine
Affects Versions: 1.3-rc1
Environment: Operating System: All
Platform: All
Reporter: Juozas Baliuka
Priority: Minor
Fix For: 1.6
Support for Static Utility Classes is:
1) define namespaces
context.defineNamespace(Math).add( java.lang.Math.class ) ;
used as $Math.sin(0)
2) Add / Replace / remove methods in namespace :
context.getNamespace(Math).add(MyRandom.class.getMethod(randomString,new
Class[]{int.class}))
used as $Math.randomString(12)
3) union on namespaces
context.defineNamespace(Utils)
.add(context.getNamespace(Math))
.add(context.defineNamespace(Collections,Collections.class ) );
used as:
$Utils.sin(0)
$Utils.sort($list)
4) Global namespace
context.getGlobalNamespace().add( Math.class );
used as $sin(0)
5) inline namespaces:
#use java.lang.Math as Math
$Math.sin(0)
#end
#with Math
$sin(0)
#end
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-146) Macros not evaluated on the first attempt with #parse
[ http://issues.apache.org/jira/browse/VELOCITY-146?page=all ] Henning Schmiedehausen updated VELOCITY-146: Bugzilla Id: (was: 17669) Component/s: Engine (was: Source) Macros not evaluated on the first attempt with #parse - Key: VELOCITY-146 URL: http://issues.apache.org/jira/browse/VELOCITY-146 Project: Velocity Issue Type: Improvement Components: Engine Affects Versions: 1.5 Environment: Operating System: All Platform: PC Reporter: Sami Leino Priority: Minor Fix For: 1.6 Attachments: wml_templates.zip I have noticed that sometimes macros do not get evaluated after Velocity has just been started. A subsequent request for the same resource produces a valid document, where macros are now correctly evaluated. Here's an example: I have a WAP-Mail webapp, which runs on Tomcat 3.3a. It uses Velocity to render the content, and the Velocity versions I have used are 1.2- dep, 1.3-dep and 1.3.1-dep. This problem occurs with all of these versions. The first request should produce a message list (there's an autologin feature, so the message list page is the first one being accessed). Here's the most relevant part of the content: -- pFolder: INBOXbr//p p br/bDate: 05.03 11:16/b br/Sender: John Doe br/Subject: a href=/wapmail/message/show/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-149) allow for deeply nested macro calls
[ http://issues.apache.org/jira/browse/VELOCITY-149?page=all ] Henning Schmiedehausen updated VELOCITY-149: Bugzilla Id: (was: 17804) Component/s: Engine (was: Source) Fix Version/s: 1.5 Look into this for 1.5, either postpone or resolve it before releasing 1.5 allow for deeply nested macro calls --- Key: VELOCITY-149 URL: http://issues.apache.org/jira/browse/VELOCITY-149 Project: Velocity Issue Type: Improvement Components: Engine Affects Versions: 1.3-rc1 Environment: Operating System: All Platform: All Reporter: Ralf Hauser Priority: Minor Fix For: 1.5 currently, it appears that more than two levels get almost unfeasible. see also http://sourceforge.net/mailarchive/message.php?msg_id=4015929 Being able to do multi-line string literals or macro arguments is probably a related idea (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17803) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-174) For consideration: #define()...#end directive to define a block of VTL as a reference
[ http://issues.apache.org/jira/browse/VELOCITY-174?page=all ] Henning Schmiedehausen updated VELOCITY-174: Bugzilla Id: (was: 19409) Component/s: Engine (was: Source) Fix Version/s: 1.6 Assignee: (was: Velocity-Dev List) Nice idea, definitely too late for 1.5. Scheduling for 1.6 For consideration: #define()...#end directive to define a block of VTL as a reference - Key: VELOCITY-174 URL: http://issues.apache.org/jira/browse/VELOCITY-174 Project: Velocity Issue Type: Improvement Components: Engine Affects Versions: 1.3.1 Environment: Operating System: All Platform: All Reporter: Andrew Tetlaw Priority: Minor Fix For: 1.6 Attachments: Define.java * Proposal: #define( $block_ref ) ## any VTL / text content here ... #end then you can use it like a reference: htmlbody $!block_ref /body/html / #if( $block_ref ).. #end / and so on * Justification: 1. Allows template designer to use a more efficient inside - out approach (similar to Nathan's VelocityLayoutServlet) 2. Keeps macro framework separate (the app developer can still disallow inline macros) 3. #macros to return blocks of VTL cannot be used like silent references or in other directives (like #if) 4. The multi-line #set proposal requires a quoted value. A #define() block can contain anything (without the need to escape quotes for example). 5. #define() blocks are proxied (like #macros) and thus change according to the context after they are defined, something a normal $reference or #set can't do. 7. Can improve template management by reducing number of unique template components 8. Can improve template security/errors by reducing the need for bottom tier template makers to worry about generic layout code and visa-versa. 9. Merges the strengths of #macros and $references = best of both worlds * Usage Example: Custom HTML forms: template 1. : document_type_1_custom_form_body.vm #define( $custom_form_body ) ## unique form fields here #end #parse(main_form_layout.vm) template 2 : main_form_layout.vm #define( $custom_page_body ) form ## common form fields here $!custom_form_body input type=submit value=submit /form #end #parse(main_page_layout.vm) template 2 : main_page_layout.vm htmlbody ## common page layout html here $!custom_page_body /body/html If the #define() directive was not available a template designer would need to do this: template 1. : document_type_1_custom_form_body.vm #parse(main_page_layout_header.vm) #parse(main_form_layout_header.vm) ## unique form fields here #parse(main_form_layout_header.vm) #parse(main_page_layout_header.vm) Not only is the same output achieved with fewer #parse() directives (3 v 5), the unique templates are fewer and easier to manage. Template designers can make many document_type_X templates and need only to define the reference $custom_form_body and not worry about the overall page layout. Custom parts of the page are also only optionally required now; the main template can test for a reference and display a default block if it isn't defined. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-183) StringResourceLoader
[ http://issues.apache.org/jira/browse/VELOCITY-183?page=all ]
Henning Schmiedehausen updated VELOCITY-183:
Bugzilla Id: (was: 20677)
Component/s: Engine
(was: Source)
Fix Version/s: 1.5
Assignee: (was: Velocity-Dev List)
Either this will be a real late-comer to 1.5 (I can see a number of nice use
cases from tests to dynamic webapps) or contrib or really early in 1.6.
Schedule it for 1.5 revisiting.
StringResourceLoader
Key: VELOCITY-183
URL: http://issues.apache.org/jira/browse/VELOCITY-183
Project: Velocity
Issue Type: Improvement
Components: Engine
Affects Versions: 1.3.1
Environment: Operating System: other
Platform: Other
Reporter: Eelco Hillenius
Priority: Minor
Fix For: 1.5
Attachments: StringResource.java, StringResourceException.java,
StringResourceLoader.java, StringResourceRepository.java,
StringResourceRepositoryFactory.java, StringResourceRepositoryImpl.java
Resource loader that works with Strings. Users should manualy add
resources to the repository that is know by the factory of this package.
Below is an example configuration for this loader.
Note that 'repositoryimpl' is not mandatory;
if not provided, the factory will fall back on using the default
implementation of this package.
stringres.resource.loader.description = Velocity StringResource loader
stringres.resource.loader.class =
org.apache.velocity.tools.stringresources.StringResourceLoader
stringres.resource.loader.repositoryimpl =
org.apache.velocity.tools.stringresources.StringResourceRepositoryImpl
Resources can be added to the repository like this:
StringResourceRepositoryFactory vsRepository = null;
vsRepository = StringResourceRepositoryFactory.getRepository();
String myTemplateName = /somewhere/intherepo/name;
String myTemplateBody = Hi, ${username}... this is a some template!;
vsRepository.putStringResource(myTemplateName, myTemplateBody);
After this, the templates can be retrieved as usual
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-206) The Velocity Plugins for eclipse throw an npe when trying to access a template.
[ http://issues.apache.org/jira/browse/VELOCITY-206?page=all ] Henning Schmiedehausen updated VELOCITY-206: Bugzilla Id: (was: 23114) Component/s: Engine (was: Source) The Velocity Plugins for eclipse throw an npe when trying to access a template. --- Key: VELOCITY-206 URL: http://issues.apache.org/jira/browse/VELOCITY-206 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.3 Environment: Operating System: Windows XP Platform: PC Reporter: Sachin Patel Priority: Minor The Velocity Plugins for eclipse throw an npe when trying to access a template. I am an IBM developer working on a eclipsed based project that uses velocity. I have eclipse installed with a my project plugins along with the velocity plugins. When I startup up eclipse and my plugins are invoked, I get an NPE whenever I try to access a template. However if I start up eclipse, then use the runtime workbench to startup another instance of eclipse then when i invoke my plugins I do not get any errors. My code is correct and I am initlizing the velocity engine correctly as well as it pointing to my template correctly. However velocity only seems to work when eclipse is started from within a runtie workbench. Here is the exception I am getting: java.lang.NullPointerException at java.lang.Throwable.init(Throwable.java) at java.lang.Throwable.init(Throwable.java) at java.lang.NullPointerException.init(NullPointerException.java:63) at org.apache.velocity.runtime.RuntimeInstance.getTemplate (RuntimeInstance.java:814) at org.apache.velocity.runtime.RuntimeInstance.getTemplate (RuntimeInstance.java:796) at org.apache.velocity.runtime.RuntimeSingleton.getTemplate (RuntimeSingleton.java:337) at org.apache.velocity.app.Velocity.getTemplate(Velocity.java:512) at com.ibm.ws.rd.taghandlers.EJBSourceHandler.endResource (EJBSourceHandler.java:121) at com.ibm.ws.rd.builders.AnnotationProcessor.visit (AnnotationProcessor.java:149) at com.ibm.ws.rd.builders.AnnotationProcessor.visit (AnnotationProcessor.java:118) at org.eclipse.core.internal.events.ResourceDelta.accept (ResourceDelta.java) at org.eclipse.core.internal.events.ResourceDelta.accept (ResourceDelta.java) at org.eclipse.core.internal.events.ResourceDelta.accept (ResourceDelta.java) at org.eclipse.core.internal.events.ResourceDelta.accept (ResourceDelta.java) at org.eclipse.core.internal.events.ResourceDelta.accept (ResourceDelta.java) at org.eclipse.core.internal.events.ResourceDelta.accept (ResourceDelta.java) at org.eclipse.core.internal.events.ResourceDelta.accept (ResourceDelta.java:52) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VELOCITY-206) The Velocity Plugins for eclipse throw an npe when trying to access a template.
[ http://issues.apache.org/jira/browse/VELOCITY-206?page=all ] Henning Schmiedehausen resolved VELOCITY-206. - Resolution: Cannot Reproduce Assignee: Henning Schmiedehausen Hm, there are now a number of plugins using Velocity for Eclipse and I cannot reproduce that without some demo plugin code. Might actually be only an Eclipse 2.x problem as Eclipse 3.x really changed lots of the internal architecture. Please reopen if you can give us more infos / this still happens with 1.4 or the 1.5 betas. Until then I resolve as not reproducable. The Velocity Plugins for eclipse throw an npe when trying to access a template. --- Key: VELOCITY-206 URL: http://issues.apache.org/jira/browse/VELOCITY-206 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.3 Environment: Operating System: Windows XP Platform: PC Reporter: Sachin Patel Assigned To: Henning Schmiedehausen Priority: Minor The Velocity Plugins for eclipse throw an npe when trying to access a template. I am an IBM developer working on a eclipsed based project that uses velocity. I have eclipse installed with a my project plugins along with the velocity plugins. When I startup up eclipse and my plugins are invoked, I get an NPE whenever I try to access a template. However if I start up eclipse, then use the runtime workbench to startup another instance of eclipse then when i invoke my plugins I do not get any errors. My code is correct and I am initlizing the velocity engine correctly as well as it pointing to my template correctly. However velocity only seems to work when eclipse is started from within a runtie workbench. Here is the exception I am getting: java.lang.NullPointerException at java.lang.Throwable.init(Throwable.java) at java.lang.Throwable.init(Throwable.java) at java.lang.NullPointerException.init(NullPointerException.java:63) at org.apache.velocity.runtime.RuntimeInstance.getTemplate (RuntimeInstance.java:814) at org.apache.velocity.runtime.RuntimeInstance.getTemplate (RuntimeInstance.java:796) at org.apache.velocity.runtime.RuntimeSingleton.getTemplate (RuntimeSingleton.java:337) at org.apache.velocity.app.Velocity.getTemplate(Velocity.java:512) at com.ibm.ws.rd.taghandlers.EJBSourceHandler.endResource (EJBSourceHandler.java:121) at com.ibm.ws.rd.builders.AnnotationProcessor.visit (AnnotationProcessor.java:149) at com.ibm.ws.rd.builders.AnnotationProcessor.visit (AnnotationProcessor.java:118) at org.eclipse.core.internal.events.ResourceDelta.accept (ResourceDelta.java) at org.eclipse.core.internal.events.ResourceDelta.accept (ResourceDelta.java) at org.eclipse.core.internal.events.ResourceDelta.accept (ResourceDelta.java) at org.eclipse.core.internal.events.ResourceDelta.accept (ResourceDelta.java) at org.eclipse.core.internal.events.ResourceDelta.accept (ResourceDelta.java) at org.eclipse.core.internal.events.ResourceDelta.accept (ResourceDelta.java) at org.eclipse.core.internal.events.ResourceDelta.accept (ResourceDelta.java:52) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-227) ResourceFactory not extensible
[ http://issues.apache.org/jira/browse/VELOCITY-227?page=all ] Henning Schmiedehausen updated VELOCITY-227: Bugzilla Id: (was: 24758) Component/s: Engine (was: Source) Affects Version/s: 1.5 (was: 1.6) Should be easily doable even for 1.5. Moving it forward, will look into it unless Will beats me to it. ResourceFactory not extensible -- Key: VELOCITY-227 URL: http://issues.apache.org/jira/browse/VELOCITY-227 Project: Velocity Issue Type: Improvement Components: Engine Affects Versions: 1.5 Environment: Operating System: All Platform: All Reporter: Charles Morehead Priority: Minor The class org.apache.velocity.runtime.resource.ResourceFactory provides no mechanism for allowing sub-classes of Template or ContentResources to be returned. Since ResourceManagerImpl makes a call to ResourceFactory.getResource(), the only way to override the behavior is to subclass ResourceManagerImpl and cut-paste-then-modify the code for loadResource(). At the very least, moving the ResourceFactory.getResource() call into a separate, protected method in ResourceManagerImpl would greatly simplify sub-classing Templates and/or ContentResources. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-229) Velocity templates should be able to specify their own encoding
[ http://issues.apache.org/jira/browse/VELOCITY-229?page=all ] Henning Schmiedehausen updated VELOCITY-229: Bugzilla Id: (was: 24796) Component/s: Engine (was: Source) Fix Version/s: 1.6 Assignee: (was: Velocity-Dev List) Yep, it's old but seems to be trivially doable (we can treat the internal encoding of the Engine as default). However, we would introduce a new directive for that, but I see no reason why this should not be possible. Biggest show stopper however would be that we either need a CLA from Charles (if you are reading this, please speak up!) or re-uploading of the patches with the I contribute that code to the ASF radio button selected. Until then, we actually have a legal problem, not a code problem. :-/ Unless there is quick reaction, this will probably miss the boat for 1.5 and surface early in 1.6. Setting Target to 1.6 Velocity templates should be able to specify their own encoding --- Key: VELOCITY-229 URL: http://issues.apache.org/jira/browse/VELOCITY-229 Project: Velocity Issue Type: Improvement Components: Engine Affects Versions: 1.5 Environment: Operating System: All Platform: All Reporter: Charles Morehead Priority: Minor Fix For: 1.6 Attachments: encoding-support.jar, Template.diff Velocity templates should be able to specify their own encoding without requiring external knowledge of the encoding before parsing (as least for all ASCII-compatible encodings). Many other scripting/templating systems (like JSP and python, for example) provide such a mechanism, and find it helpful to users when creating multi-language (and encoding) sites. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-262) #set not parsed in #macro
[ http://issues.apache.org/jira/browse/VELOCITY-262?page=all ] Henning Schmiedehausen updated VELOCITY-262: Bugzilla Id: (was: 28418) Component/s: Engine (was: Source) #set not parsed in #macro - Key: VELOCITY-262 URL: http://issues.apache.org/jira/browse/VELOCITY-262 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.4 Environment: Operating System: All Platform: PC Reporter: Mike Kienenberger Priority: Minor Fix For: 1.5 Attachments: output.htm, scheduledPaymentsTable.macro.txt #set statements are not being parsed in #macros in VM_global_library. Worked in 1.3.1, doesn't in 1.4. I'm going to attach the #macro and the diff'd 1.3.1 vs 1.4 output. -Mike -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-281) passing local variables and velocimacros with #parse()
[ http://issues.apache.org/jira/browse/VELOCITY-281?page=all ] Henning Schmiedehausen updated VELOCITY-281: Bugzilla Id: (was: 30107) Component/s: Engine (was: Source) passing local variables and velocimacros with #parse() -- Key: VELOCITY-281 URL: http://issues.apache.org/jira/browse/VELOCITY-281 Project: Velocity Issue Type: Improvement Components: Engine Affects Versions: 1.4 Environment: Operating System: other Platform: Other Reporter: Marcus Sundman Priority: Minor Fix For: 1.6 Let's say I have velocimacro.permissions.allow.inline.local.scope = true. It would still be nice to be able to pass variables and velocitymacros to a template imported by #parse(). E.g., #parse(foo.vm $myvar #mymacro) could make $myvar and #mymacro accessible to foo.vm when it's parsed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-285) reference within macro and foreach is incorrect
[ http://issues.apache.org/jira/browse/VELOCITY-285?page=all ] Henning Schmiedehausen updated VELOCITY-285: Bugzilla Id: (was: 30343) Component/s: Engine (was: Source) reference within macro and foreach is incorrect --- Key: VELOCITY-285 URL: http://issues.apache.org/jira/browse/VELOCITY-285 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.4 Environment: Operating System: other Platform: Other Reporter: Gilles Scokart Priority: Minor Fix For: 1.5 It seems that there is a bug when we have loop into a recursive macro. Here is the test I run : #macro (test_loop $p) call to test_loop ($p) #foreach($child in $p) in the loop the param should not be changed : ($p) #test_loop($child) #end return #end #set($l1=[a]) #set($l = [$l1]) #test_loop($l) It produce: call to test_loop ([[a]]) in the loop the param should not be changed : ([[a]]) call to test_loop ([a]) in the loop the param should not be changed : (a) call to test_loop (a) return return return IMHO, it should be call to test_loop ([[a]]) in the loop the param should not be changed : ([[a]]) call to test_loop ([a]) in the loop the param should not be changed : ([a]) call to test_loop (a) return return return The difference is in the second recusive call. I don't know why, but it seems that the instruction #foreach($child in $p) has modified $p that contains the value of $child. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-297) Maximum recursion depth for macro calls
[ http://issues.apache.org/jira/browse/VELOCITY-297?page=all ] Henning Schmiedehausen updated VELOCITY-297: Bugzilla Id: (was: 31563) Component/s: Engine (was: Source) No news on the patch front. 1.6 it is, then. Maximum recursion depth for macro calls --- Key: VELOCITY-297 URL: http://issues.apache.org/jira/browse/VELOCITY-297 Project: Velocity Issue Type: Improvement Components: Engine Affects Versions: 1.4 Environment: Operating System: All Platform: All Reporter: Jochen Toppe Priority: Minor Fix For: 1.6 Similar to the option directive.parse.maxdepth I would love to see a parameter to limit the depth of macro call recursion. In my scenario I let simple users write macros to create html pages. Using recursive macros, they could get the application to misbehave. The following piece of code illustrates the problem: #macro ( showInfo $p ) Info: $p #showInfo($p) #end #showInfo(Test) Which simply leads to: java.lang.StackOverflowError at org.apache.velocity.runtime.parser.node.ASTStringLiteral.value(ASTStringLiteral.java:136) at org.apache.velocity.runtime.directive.VMProxyArg.getObject(VMProxyArg.java:294) at org.apache.velocity.context.VMContext.get(VMContext.java:181) Current workaround: Disable inline macros. Have responsible Script-Developers. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-341) removal of o.a.v.servlet.VelocityServlet and o.a.v.app.tools.VelocityFormatter
[ http://issues.apache.org/jira/browse/VELOCITY-341?page=all ] Henning Schmiedehausen updated VELOCITY-341: Bugzilla Id: (was: 33195) Component/s: Engine (was: Source) removal of o.a.v.servlet.VelocityServlet and o.a.v.app.tools.VelocityFormatter -- Key: VELOCITY-341 URL: http://issues.apache.org/jira/browse/VELOCITY-341 Project: Velocity Issue Type: Improvement Components: Engine Affects Versions: 1.5 Environment: Operating System: Windows XP Platform: PC Reporter: Shinobu Kawai Priority: Minor Fix For: 2.0 A reminder bug to remove the class when it's time to do so. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-362) can't load macros in file loaded with #parse
[ http://issues.apache.org/jira/browse/VELOCITY-362?page=all ] Henning Schmiedehausen updated VELOCITY-362: Bugzilla Id: (was: 33750) Component/s: Engine (was: Source) can't load macros in file loaded with #parse Key: VELOCITY-362 URL: http://issues.apache.org/jira/browse/VELOCITY-362 Project: Velocity Issue Type: Improvement Components: Engine Affects Versions: 1.4 Environment: Operating System: All Platform: All Reporter: whxbb Priority: Minor Fix For: 1.6 I think this is a big bug. I've used velocity in my projects, erveything is ok but this. i want to know it's this problem will be resolved in next version? if it's not, i have to abandon velocity. the bug is : from doc: This is important to remember if you try to #parse() a template containing inline #macro() directives. Because the #parse() happens at runtime, and the parser decides if a VM-looking element in the template is a VM at parsetime, #parse()-ing a set of VM declarations won't work as expected. To get around this, simply use the velocimacro.library facility to have Velocity load your VMs at startup. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VELOCITY-362) can't load macros in file loaded with #parse
[ http://issues.apache.org/jira/browse/VELOCITY-362?page=all ] Henning Schmiedehausen resolved VELOCITY-362. - Fix Version/s: (was: 1.6) Resolution: Won't Fix As we already have discussed that issue in length; as it is on our Macro wishlist, there is no need to keep the report open. The reported bug is the documented behaviour; yes it is not really nice but sometimes there is no pony. Sorry 'bout that. can't load macros in file loaded with #parse Key: VELOCITY-362 URL: http://issues.apache.org/jira/browse/VELOCITY-362 Project: Velocity Issue Type: Improvement Components: Engine Affects Versions: 1.4 Environment: Operating System: All Platform: All Reporter: whxbb Priority: Minor I think this is a big bug. I've used velocity in my projects, erveything is ok but this. i want to know it's this problem will be resolved in next version? if it's not, i have to abandon velocity. the bug is : from doc: This is important to remember if you try to #parse() a template containing inline #macro() directives. Because the #parse() happens at runtime, and the parser decides if a VM-looking element in the template is a VM at parsetime, #parse()-ing a set of VM declarations won't work as expected. To get around this, simply use the velocimacro.library facility to have Velocity load your VMs at startup. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VELOCITY-277) macros in #parsed files are not refreshed when including page is refreshed
[ http://issues.apache.org/jira/browse/VELOCITY-277?page=all ] Henning Schmiedehausen resolved VELOCITY-277. - Resolution: Duplicate The issue is a known problem and already documented on the wiki. Closing the issue report. macros in #parsed files are not refreshed when including page is refreshed -- Key: VELOCITY-277 URL: http://issues.apache.org/jira/browse/VELOCITY-277 Project: Velocity Issue Type: Improvement Components: Engine Affects Versions: 1.4 Environment: Operating System: other Platform: Other Reporter: Tim White Priority: Critical Fix For: 1.6 If a template #parses a file containing velocimacros, changes those macros do not make it into the including template. This is true whether the file is included via the library property or via #parse. Although there is the velocimacro.library.autoreload property, it is not for use in production according to the documentation - and cannot be used with template caching. Also, often, macros included via #parse do not pick up their macros the first time they are compiiled. And with template caching they are only ever called once, this leads to situations where changes in templates that include macros and are cached do not function in production. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-365) handle Lists arrays similarly
[ http://issues.apache.org/jira/browse/VELOCITY-365?page=all ] Henning Schmiedehausen updated VELOCITY-365: Bugzilla Id: (was: 33833) Component/s: Engine (was: Source) Also a custom Uberspect using ArrayIterator might already solve that problem. See whiteboard/henning/jdk15 on how to write your own Uberspect. handle Lists arrays similarly --- Key: VELOCITY-365 URL: http://issues.apache.org/jira/browse/VELOCITY-365 Project: Velocity Issue Type: Improvement Components: Engine Affects Versions: 1.6 Environment: Operating System: All Platform: All Reporter: Nathan Bubna Priority: Minor ok, the motive of this feature request is that we shouldn't have to distinguish between an $array and a $list when writing templates. this is already handled to a degree in the #foreach() directive which transparently handles both arrays and Lists (among other things), and it seems logically consistent with the way VTL already hides the difference between primitives and their wrappers (int vs. Integer). so, in this same spirit, i propose that we should enable template authors to access items by index, determine the size of, and manipulate (to a point) Lists and arrays identically. here's an example that demonstrates how i think this should work: Access Item at Index 2: $list.get(2) ##works already $array.get(2) ##doesn't work right now Determine size: $list.size() ##works already $array.size() ##wish this would work you get the idea, right? basically, i would like to have all operations that make sense for an array supported (which i believe means most List methods except the add(), remove(), and clear() ones). IMHO, this would simplify things for users noticeably and eliminate the need for such things as an ArrayTool in the VelocityTools library. at this point, i'm not sure what the best approach for implementing this is. it may simply be the automatic, transparent wrapping of arrays inserted into the context with some sort of ArrayList wrapper class. or i suppose it could involve some crazy Uberspect trickery. now all we need is someone with the time to whip up a patch... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-383) Non thread-safe Template object can cause NPE under heavy concurrent load
[ http://issues.apache.org/jira/browse/VELOCITY-383?page=all ] Henning Schmiedehausen updated VELOCITY-383: Bugzilla Id: (was: 35331) Component/s: Engine (was: Source) Fix Version/s: 1.5 Assignee: Henning Schmiedehausen Priority: Blocker (was: Minor) The fix for VELOCITY-24 might also fix this issue. This will be resolved before 1.5 release. Non thread-safe Template object can cause NPE under heavy concurrent load - Key: VELOCITY-383 URL: http://issues.apache.org/jira/browse/VELOCITY-383 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.4 Environment: Operating System: Windows XP Platform: PC Reporter: Hans Assigned To: Henning Schmiedehausen Priority: Blocker Fix For: 1.5 Attachments: Example.java During load testing the server, with 50 concurrent users, the VelocityViewServlet would throw a null pointer exception about 3% of the time. 97% of the time, the page would serve normally. Below is the trace: java.lang.NullPointerException at org.apache.velocity.runtime.parser.node.ASTDirective.init (ASTDirective.java:94) at org.apache.velocity.runtime.parser.node.SimpleNode.init (SimpleNode.java:201) at org.apache.velocity.Template.initDocument(Template.java:199) at org.apache.velocity.Template.process(Template.java:124) at org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource (ResourceManagerImpl.java:423) at org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource (ResourceManagerImpl.java:341) at org.apache.velocity.runtime.RuntimeInstance.getTemplate (RuntimeInstance.java:831) at org.apache.velocity.runtime.RuntimeInstance.getTemplate (RuntimeInstance.java:813) at org.apache.velocity.runtime.RuntimeSingleton.getTemplate (RuntimeSingleton.java:285) at org.apache.velocity.tools.view.servlet.VelocityViewServlet.getTemplate (VelocityViewServlet.java:540) at org.apache.velocity.tools.view.servlet.VelocityViewServlet.handleRequest (VelocityViewServlet.java:475) at org.apache.velocity.tools.view.servlet.VelocityViewServlet.doRequest (VelocityViewServlet.java:407) at org.apache.velocity.tools.view.servlet.VelocityViewServlet.doPost (VelocityViewServlet.java:383) at javax.servlet.http.HttpServlet.service(HttpServlet.java:709) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:157) at org.apache.catalina.core.ApplicationDispatcher.invoke (ApplicationDispatcher.java:674) at org.apache.catalina.core.ApplicationDispatcher.doInclude (ApplicationDispatcher.java:576) at org.apache.catalina.core.ApplicationDispatcher.include (ApplicationDispatcher.java:501) at org.apache.velocity.tools.view.ImportSupport.acquireString (ImportSupport.java:140) at org.apache.velocity.tools.struts.TilesTool.doInsert (TilesTool.java:476) at org.apache.velocity.tools.struts.TilesTool.doInsert (TilesTool.java:419) at org.apache.velocity.tools.struts.TilesTool.processUrl (TilesTool.java:398) at org.apache.velocity.tools.struts.TilesTool.processAsDefinitionOrURL (TilesTool.java:357) at org.apache.velocity.tools.struts.TilesTool.processObjectValue (TilesTool.java:305) at org.apache.velocity.tools.struts.TilesTool.get(TilesTool.java:135) at sun.reflect.GeneratedMethodAccessor136.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.velocity.runtime.parser.node.GetExecutor.execute (GetExecutor.java:65) at org.apache.velocity.util.introspection.UberspectImpl$VelGetterImpl.invoke (UberspectImpl.java:302) at org.apache.velocity.runtime.parser.node.ASTIdentifier.execute (ASTIdentifier.java:157) at org.apache.velocity.runtime.parser.node.ASTReference.execute (ASTReference.java:175) at org.apache.velocity.runtime.parser.node.ASTReference.render (ASTReference.java:220) at org.apache.velocity.runtime.parser.node.SimpleNode.render (SimpleNode.java:230) at org.apache.velocity.Template.merge(Template.java:256) at org.apache.velocity.tools.view.servlet.VelocityViewServlet.mergeTemplate (VelocityViewServlet.java:592) at org.apache.velocity.tools.view.servlet.VelocityViewServlet.doRequest (VelocityViewServlet.java:417) at
[jira] Updated: (VELOCITY-391) Provide better syntax for converting XML entities
[ http://issues.apache.org/jira/browse/VELOCITY-391?page=all ] Henning Schmiedehausen updated VELOCITY-391: Bugzilla Id: (was: 35658) Component/s: Engine (was: Source) Provide better syntax for converting XML entities - Key: VELOCITY-391 URL: http://issues.apache.org/jira/browse/VELOCITY-391 Project: Velocity Issue Type: Improvement Components: Engine Affects Versions: 1.4 Environment: Operating System: All Platform: Other Reporter: bob.tarling Priority: Minor I'm using velocity to persist my applications data in XML format. The problem is with converting special XML characters to entities. I have read the developers guide here http://jakarta.apache.org/velocity/developer-guide.html#Velocity%20and%20XML I'm wondering if the developers would consider some addition to the velocity syntax to help with this instead. I can't help think that generation of XML must be a common requirement for velocity users and a shortcut syntax would help keep templates looking neater. How about the likes of the following to display a field with automatic conversion of XML characters to entities. pThe clients name is $clientName/p So the client name John O'Connor becomes pThe clients name is John Oapos;Connor/p There are alternatives, such as having a specific file type. e.g. .xvm as opposed to .vm A secondary advantage to this is that syntax highlighters could be devised to recognise and highlight both the XML and the template code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VELOCITY-392) Switch to a better log system - slf4j
[ http://issues.apache.org/jira/browse/VELOCITY-392?page=all ] Henning Schmiedehausen resolved VELOCITY-392. - Resolution: Won't Fix Assignee: Henning Schmiedehausen (was: Velocity-Dev List) Nope. -1 here. If we move to another logging system it's either JCL (Jakarta commons logging) or log4j directly. There is so much mud slinging around the log4j, nlog4j, slf4j and logback projects (not to talk about the licensing issues with logback to which slf4j is dangerously near) that I don't want to go near there. Nathan did a major rework for velocity logging for 1.5 and currently, while the logging is still a bit too heavy for my liking (I'd like to switch to JCL), there is no way that we move to a politically encumbered project that is run outside the ASF for something as mission critical as logging. Switch to a better log system - slf4j - Key: VELOCITY-392 URL: http://issues.apache.org/jira/browse/VELOCITY-392 Project: Velocity Issue Type: Improvement Components: Source Affects Versions: 1.5 Environment: Operating System: All Platform: All Reporter: Jens Elkner Assigned To: Henning Schmiedehausen Priority: Minor Attachments: velocity.patch Since I'm still very unhappy with the current logging workaround in velocity, I removed the complete velocity logsystem stuff and replaced it with slf4j (see http://slf4j.org/manual.html ; http://slf4j.org/faq.html). So, the final thing is a little bit smaller and should be wrt. logging easier to use (i.e. no need for passing runtime svc handles back and forth just to be able to log something), much faster, safer and more precise and powerful than the old one... In case your are interested, I'll attach the patch made against the saturday evening svn repository. It basically contains the log changes as well as some code cleaning (i.e. remove/comment out unsed vars/methods, removed unneccessary casts as well as nested else clauses, removed throw XExceptions, which are actually not thrown). Finally I switched many log.info into log.debug, since the appropriate messages are important for developers only and should not irritate the enduser (who usually doesn't even understand that freak language ;-)). To get the thing running out of the box, I modified the buildfile to include log4j.properties in the jar, so that nlog4j aka log4j NG ;-) finds and uses it automatically, if one has not explictly configured it. And of course build/lib/log4j has been replaced with nlog4j (see http://www.slf4j.org/nlog4j/download.html) Regards, jens. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-394) RFE: optional record comments
[ http://issues.apache.org/jira/browse/VELOCITY-394?page=all ] Henning Schmiedehausen updated VELOCITY-394: Bugzilla Id: (was: 35724) Component/s: Engine (was: Source) Assignee: (was: Velocity-Dev List) Yep, sounds like a good idea. If you are a parser whiz, it shouldn't also be too hard to implement. Patches anyone? RFE: optional record comments - Key: VELOCITY-394 URL: http://issues.apache.org/jira/browse/VELOCITY-394 Project: Velocity Issue Type: Improvement Components: Engine Affects Versions: 1.5 Environment: Operating System: All Platform: All Reporter: Jens Elkner Priority: Minor At the moment, the whole content except the terminator of a comment are dropped. This ok, for the normal server/application use, where a template is evaluated, but for IDEs it would be a big advantage, to have the whole comment in the parser tree, so that a ParserVisitor can be used, e.g. to highlight comments in an editor. So it would be nice, to have something like parser.recordComments(boolean complete), to dis/enable the recording of the complete comment, if encountered. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-406) Improved Syntax for Maps and Collections
[ http://issues.apache.org/jira/browse/VELOCITY-406?page=all ] Henning Schmiedehausen updated VELOCITY-406: Component/s: Engine (was: Source) Fix Version/s: 1.6 Will think about Maps slices for 1.6. Iterable is supported if you use a custom Uberspect (see whiteboard/henning/jdk15). Groovy might have stolen the horrible map syntax from us, so there is nothing we can do here... :-) Improved Syntax for Maps and Collections Key: VELOCITY-406 URL: http://issues.apache.org/jira/browse/VELOCITY-406 Project: Velocity Issue Type: Improvement Components: Engine Reporter: Jörg Gottschling Priority: Minor Fix For: 1.6 I would like to see some syntatic sugar for Maps and Collections and perhaps other Objects too. (I have read that there will be a syntax for map literals in 1.5, that's a first step.) I want to have something like in groovy: http://groovy.codehaus.org/Collections Scroll down to Slicing with the subscript operator. PS: Please do never implement this terrible confusing groovy map bean syntax, where map.foo ist equivalent to map.get(foo). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VELOCITY-409) Convert Exceptions to RuntimeExceptions
[ http://issues.apache.org/jira/browse/VELOCITY-409?page=all ] Henning Schmiedehausen resolved VELOCITY-409. - Fix Version/s: 1.5 (was: 2.0) Resolution: Fixed We boldly moved VelocityException to extend RuntimeException between beta1 and beta2. Beware of flying pigs overhead. :-) Convert Exceptions to RuntimeExceptions --- Key: VELOCITY-409 URL: http://issues.apache.org/jira/browse/VELOCITY-409 Project: Velocity Issue Type: Improvement Components: Source Affects Versions: 1.4 Reporter: Will Glass-Husain Priority: Minor Fix For: 1.5 There's a movement in the field to simplify Java development by using unchecked Exceptions rather than checked Exceptions. Most notably this approach has been championed by Rod Johnson (J2EE without EJB, Spring Framework) and Bruce Eckels (Thinking in Java). In the last 2 years, popular libraries like Spring Framework and Hibernate 3.0 have used unchecked exceptions. Quote from the DeveloperWorks article listed below: Some exceptions are basically secondary return codes (which generally signal violation of business rules), and some are of the something went horribly wrong variety (such as failure to make a database connection). Johnson advocates using checked exceptions for the first category (alternative return codes), and runtime exceptions for the latter category. In the something went horribly wrong category, the motivation is simply to recognize the fact that no caller is going to effectively handle this exception, so it might as well get propagated all the way up the stack with the minimum of impact on the intervening code (and minimize the chance of exception swallowing). I'd argue that Velocity exceptions like ParseException and ResourceNotFoundException are of the horribly wrong category. Probably MethodInvocationException as well. In version 2.0, we should consider making VelocityException a subclass of java.lang.RuntimeException. Resources: http://www-128.ibm.com/developerworks/java/library/j-jtp05254.html Here's an argument against this practice: http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-434) Commons pool implementation of the parser pool
[ http://issues.apache.org/jira/browse/VELOCITY-434?page=all ] Henning Schmiedehausen updated VELOCITY-434: Component/s: Engine (was: Source) Fix Version/s: 1.5 It might be possible to make the parser pool pluggable and then use the commons-pool implementation. 1.6 stuff. Serge, care to make sure that your patches have the Contribute to the ASF radio button set, that would help us very much when integrating the stuff. Commons pool implementation of the parser pool -- Key: VELOCITY-434 URL: http://issues.apache.org/jira/browse/VELOCITY-434 Project: Velocity Issue Type: Improvement Components: Engine Reporter: Serge Knystautas Priority: Minor Fix For: 1.5 Attachments: CommonsParserPool.java, CommonsParserPool.java, CommonsParserPoolFactory.java Now that with [Velocity-433] we can swap out the parser pool, here is a parser pool that uses commons-pool (http://jakarta.apache.org/commons/pool/). It is very primitive configuration and uses the same configuration name (parser.pool.size) for maximum number of elements in the pool. It is also configured to grow when the maximum number is exhausted, which means that it scales the same way as the original parser, while actually providing some better pool support. One of the nicest parts about this is that you can set your maximum instances to 0 and still get great performance. The first time you need a parser, it will still add one even though the max is reached (since grow when exhausted is set). Assuming the second time you need a parser is within a few seconds, that first instance is still there. Here is some sample code of how to use it your app. Properties configuration = new Properties(); configuration.put(parser.pool.class, com.lokitech.util.pool.CommonsParserPool); configuration.put(parser.pool.size, 0); Velocity.init(configuration); Since Velocity does not have an existing dependency on commons pool, I'm not sure this code will get packaged into the main distribution. This code is licensed using ASL 2.0, so please reuse however you want as long as attribution is kept per the license. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-452) In ASTMethod.execute the IllegalArgumentException should be catched
[ http://issues.apache.org/jira/browse/VELOCITY-452?page=all ] Henning Schmiedehausen updated VELOCITY-452: Component/s: Engine (was: Source) Assignee: Henning Schmiedehausen I look into this for 1.5. In ASTMethod.execute the IllegalArgumentException should be catched --- Key: VELOCITY-452 URL: http://issues.apache.org/jira/browse/VELOCITY-452 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.5 Reporter: Alexey Panchenko Assigned To: Henning Schmiedehausen Priority: Minor Attachments: ASTMethod_invoke_IllegalArgumentException.patch The IllegalArgumentException can be thrown by java.lang.reflect.Method#invoke(java.lang.Object, java.lang.Object[]) blockquote if the method is an instance method and the specified object argument is not an instance of the class or interface declaring the underlying method (or of a subclass or implementor thereof); if the number of actual and formal parameters differ; if an unwrapping conversion for primitive arguments fails; or if, after possible unwrapping, a parameter value cannot be converted to the corresponding formal parameter type by a method invocation conversion. /blockquote It is caused by the passed parameters and should be catched to provide the location in template to the template author. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-191) UnicodeFileResourceLoader for Win2k Notepad UTF-8 files
[ http://issues.apache.org/jira/browse/VELOCITY-191?page=all ] Henning Schmiedehausen updated VELOCITY-191: Bugzilla Id: (was: 21582) Component/s: Engine (was: Source) Fix Version/s: 1.5 Not sure if that will make the 1.5 boat. Please make sure that your example code is either clearly labeled as might be added to the ASF source code base or (better) attach it to the issue with the contribute to the ASF button set. Thanks. UnicodeFileResourceLoader for Win2k Notepad UTF-8 files --- Key: VELOCITY-191 URL: http://issues.apache.org/jira/browse/VELOCITY-191 Project: Velocity Issue Type: Improvement Components: Engine Affects Versions: 1.3.1 Environment: Operating System: All Platform: All Reporter: Mailmur Priority: Minor Fix For: 1.5 [copypaste from velocity-user mailing list] Date: Mon, 14 Jul 2003 01:52:11 -0700 (PDT) From: mailmur [EMAIL PROTECTED] Subject: UnicodeFileResourceLoader to support Win2k Notepad UTF-8 files Content-Type: text/plain; charset=us-ascii I discovered, that files saved with Win2k Notepad UTF-8 format always generated an extra ? character at the start of ISO-8859-1 output text. This was due to lack of UTF8 BOM mark support in InputStreamReader/OutputStreamWriter classes. I then created a inputstream implementation to skip BOM mark to overcome this bug. Please, find here a source + testprogram to see it for yourself. I created UnicodeFileResourceLoader to make all this transparent. http://koti.mbnet.fi/akini/java/unicodereader/ I dont know what is the proper procedure to add this to Velocity core (if you find this useful), but here it is. Feel free to change class package. Or is this even the right list to announce such addition Here is a link to Sun bugparade about the UTF-8 BOM problem: http://developer.java.sun.com/developer/bugParade/bugs/4508058.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-266) change AbstractContext.internalRemove() to have consistent key type
[ http://issues.apache.org/jira/browse/VELOCITY-266?page=all ] Henning Schmiedehausen updated VELOCITY-266: Bugzilla Id: (was: 28605) Component/s: Engine (was: Source) change AbstractContext.internalRemove() to have consistent key type --- Key: VELOCITY-266 URL: http://issues.apache.org/jira/browse/VELOCITY-266 Project: Velocity Issue Type: Improvement Components: Engine Affects Versions: 1.0-Release Environment: Operating System: other Platform: All Reporter: Gerard Oberle Priority: Trivial Fix For: 2.0 org.apache.velocity.context.AbstractContext.internalRemove(Object key) uses an argument type of java.lang.Object for the key. This is inconsistent with other methods (internalGet, internalPut, internalContainsKey), which all use a type of java.lang.String for the key. Of course, this will probably require deprecating it, but maybe there's still time to fix it, assuming few users have implemented their own. - Jerry Oberle perl -e 'printf %silto%c%sberle%cearthlink%cnet%c, ma, 58, go, 64, 46, 10;' # Sorry but I do not know whether spammers can harvest addresses from here -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-439) Improve Resource existence detection
[ http://issues.apache.org/jira/browse/VELOCITY-439?page=all ]
Henning Schmiedehausen updated VELOCITY-439:
Component/s: Engine
(was: Source)
Improve Resource existence detection
Key: VELOCITY-439
URL: http://issues.apache.org/jira/browse/VELOCITY-439
Project: Velocity
Issue Type: Improvement
Components: Engine
Affects Versions: 1.4, 1.5
Reporter: Tassos Bassoukos
Priority: Trivial
Fix For: 1.6
Attachments: resourceloader.patch
Depending on the ResourceLoader used, testing the existence of a resource is
somewhat expensive, as the resource has to be opened to test for its
existence.
I'm proposing the following changes:
1.
Add a new method to
org.apache.velocity.runtime.resource.loader.ResourceLoader:
public boolean resourceExists(String source) {
InputStream is = null;
try {
is = resourceLoader.getResourceStream(resourceName);
if (is != null) {
return true;
}
} catch (ResourceNotFoundException e) {
} finally {
if (is != null) {
try {
is.close();
} catch (Exception e) {
}
}
}
return false;
}
This method keeps compatibility with all current ResourceLoaders, and can be
overriden by subclasses.
2. org.apache.velocity.runtime.resource.ResourceManagerImpl
Modify the String getLoaderNameForResource(String resourceName) method to use
the new ResourceLoader.resourceExists(String) method.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VELOCITY-471) Create velocity.apache.org
[ http://issues.apache.org/jira/browse/VELOCITY-471?page=all ] Henning Schmiedehausen resolved VELOCITY-471. - Resolution: Fixed infra has created velocity.apache.org Create velocity.apache.org -- Key: VELOCITY-471 URL: http://issues.apache.org/jira/browse/VELOCITY-471 Project: Velocity Issue Type: Sub-task Components: Website Reporter: Henning Schmiedehausen Assigned To: Henning Schmiedehausen Trigger infrastructure@ to create velocity.apache.org -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELTOOLS-68) VelocityViewServlet has hard coded ServletLogger
[ http://issues.apache.org/jira/browse/VELTOOLS-68?page=comments#action_12447135 ] Henning Schmiedehausen commented on VELTOOLS-68: Ah yes, I forgot about backwards compatibility again. So your point with LogSystem is surely valid. About the priority: Well as the current is Avalon, Log4j, JDK, I'd probably say that making it configurable for the user and adding a default of ServletLogging (which should always be available in a servlet environment... :-) ) might be fine. VelocityViewServlet has hard coded ServletLogger Key: VELTOOLS-68 URL: http://issues.apache.org/jira/browse/VELTOOLS-68 Project: VelocityTools Issue Type: Bug Components: VelocityView Affects Versions: 1.3 Reporter: Henning Schmiedehausen Priority: Minor VelocityViewServlet configures the Velocity engine to use the ServletLogger (~line 323). Integration of the servlet into applications that use other logging systems (e.g. log4j / commons-logging) is very hard because of that. - VVS should honor the logging setttings in velocity.properties (e.g. for explicit jdk logging) - It should add the ServletLogger to the log engine search path and only use it if no other logger was found (log4j / avalon etc.) - The ServletLogger class implements the deprecated LogSystem. VelocityTools should provide a LogChute implementation of the SrevletLogger. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELTOOLS-68) VelocityViewServlet has hard coded ServletLogger
[ http://issues.apache.org/jira/browse/VELTOOLS-68?page=all ] Henning Schmiedehausen updated VELTOOLS-68: --- Attachment: velocity-tools.patch How about the attached patch? It factors out the property setting by the servlet to work similar to the engine itself (load a properties file from the class path). This explicitly shows what gets set automagically by the servlet and gives useful hints to users that e.g. want to turn on caching for the webapp loader in the application velocity.properties... (webapp.resource.loader.cache = true) The patch also cleans up a number of minor nits, e.g. the usage of getServletContext().log() instead of log() directly... VelocityViewServlet has hard coded ServletLogger Key: VELTOOLS-68 URL: http://issues.apache.org/jira/browse/VELTOOLS-68 Project: VelocityTools Issue Type: Bug Components: VelocityView Affects Versions: 1.3 Reporter: Henning Schmiedehausen Priority: Minor Attachments: velocity-tools.patch VelocityViewServlet configures the Velocity engine to use the ServletLogger (~line 323). Integration of the servlet into applications that use other logging systems (e.g. log4j / commons-logging) is very hard because of that. - VVS should honor the logging setttings in velocity.properties (e.g. for explicit jdk logging) - It should add the ServletLogger to the log engine search path and only use it if no other logger was found (log4j / avalon etc.) - The ServletLogger class implements the deprecated LogSystem. VelocityTools should provide a LogChute implementation of the SrevletLogger. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (VELOCITY-24) calls to local macros not always made when template caching is off
[ http://issues.apache.org/jira/browse/VELOCITY-24?page=all ] Henning Schmiedehausen reassigned VELOCITY-24: -- Assignee: Henning Schmiedehausen calls to local macros not always made when template caching is off -- Key: VELOCITY-24 URL: http://issues.apache.org/jira/browse/VELOCITY-24 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.5 beta1 Environment: Operating System: other Platform: Other Reporter: peterwlynch Assigned To: Henning Schmiedehausen Priority: Blocker Fix For: 1.5 In the latest nightly build Oct 28, 2001 and also in velocity 1.2 rc2 i noticed the following problem with autoreloading macros. Made a simple html page. added a simple one line macro that accepted one param, a letter something like ## local macro, not global #macro(letter $char) This is the letter $char #end #letter(A) #letter(B) #letter(C) etc to Z -- The html page would be loaded in response to a form being submitted. If I clicked on the submit button five times, quickly ( five separate submits), most times the final response would out put something like... This is the letter A This is the letter B This is the letter C This is the letter D This is the letter E #letter#letter#letter #letter .. This is the letter Z As you can see, some macro calls did not get parsed. We were just happening to use velocity through turbine, but I don't think that affects the bug. Besides, the bug went away when the autoreload was false. Once scarab's runbox is back up, might be interesting to test this out on their macros too for comparison, although I don't see that they have any local macros. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VELOCITY-24) calls to local macros not always made when template caching is off
[ http://issues.apache.org/jira/browse/VELOCITY-24?page=all ] Henning Schmiedehausen resolved VELOCITY-24. Resolution: Fixed getResource() must be synchronized. Yes, that sucks for applications that hammer on that and have caching off. Here are some numbers (running on my shiny new Core 2 Duo box, Tomcat and VelocityViewServlet running under the debugger) ab -c 5 -n 1000 http://localhost:8080/testbed/templates/issues/velocity-24.vm unsynced, caching off: Document Path: /testbed/templates/issues/velocity-24.vm Document Length:663 bytes Concurrency Level: 5 Time taken for tests: 4.193717 seconds Complete requests: 1000 Failed requests:760 -- !!! (Connect: 0, Length: 760, Exceptions: 0) Write errors: 0 Total transferred: 595970 bytes HTML transferred: 449860 bytes Requests per second:238.45 [#/sec] (mean) Time per request: 20.969 [ms] (mean) Time per request: 4.194 [ms] (mean, across all concurrent requests) Transfer rate: 138.78 [Kbytes/sec] received unsynced, cache on: Document Path: /testbed/templates/issues/velocity-24.vm Document Length:663 bytes Concurrency Level: 5 Time taken for tests: 0.479525 seconds Complete requests: 1000 Failed requests:0 Write errors: 0 Total transferred: 809809 bytes HTML transferred: 663663 bytes Requests per second:2085.40 [#/sec] (mean) Time per request: 2.398 [ms] (mean) Time per request: 0.480 [ms] (mean, across all concurrent requests) Transfer rate: 1647.46 [Kbytes/sec] received synced, cache off: Document Path: /testbed/templates/issues/velocity-24.vm Document Length:663 bytes Concurrency Level: 5 Time taken for tests: 11.92560 seconds Complete requests: 1000 Failed requests:0 Write errors: 0 Total transferred: 809000 bytes HTML transferred: 663000 bytes Requests per second:90.15 [#/sec] (mean) Time per request: 55.463 [ms] (mean) Time per request: 11.093 [ms] (mean, across all concurrent requests) Transfer rate: 71.22 [Kbytes/sec] received synced, cache on Document Path: /testbed/templates/issues/velocity-24.vm Document Length:663 bytes Concurrency Level: 5 Time taken for tests: 0.333444 seconds Complete requests: 1000 Failed requests:0 Write errors: 0 Total transferred: 810618 bytes HTML transferred: 664326 bytes Requests per second:2999.00 [#/sec] (mean) Time per request: 1.667 [ms] (mean) Time per request: 0.333 [ms] (mean, across all concurrent requests) Transfer rate: 2372.21 [Kbytes/sec] received The response time for cache on (which should be the normal production mode) is about the same level for synced and unsynced. But without cache, syncing makes the difference between fast but wrong and slower but correct. I personally opt for the latter. calls to local macros not always made when template caching is off -- Key: VELOCITY-24 URL: http://issues.apache.org/jira/browse/VELOCITY-24 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.5 beta1 Environment: Operating System: other Platform: Other Reporter: peterwlynch Assigned To: Henning Schmiedehausen Priority: Blocker Fix For: 1.5 In the latest nightly build Oct 28, 2001 and also in velocity 1.2 rc2 i noticed the following problem with autoreloading macros. Made a simple html page. added a simple one line macro that accepted one param, a letter something like ## local macro, not global #macro(letter $char) This is the letter $char #end #letter(A) #letter(B) #letter(C) etc to Z -- The html page would be loaded in response to a form being submitted. If I clicked on the submit button five times, quickly ( five separate submits), most times the final response would out put something like... This is the letter A This is the letter B This is the letter C This is the letter D This is the letter E #letter#letter#letter #letter .. This is the letter Z As you can see, some macro calls did not get parsed. We were just happening to use velocity through turbine, but I don't think that affects the bug. Besides, the bug went away when the autoreload was false. Once scarab's runbox is back up, might be interesting to test this out on their macros too for comparison, although I don't see that they have any local macros. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators:
[jira] Assigned: (VELOCITY-414) Extend the MethodInvocation exception to be able to give the velocity macro writer a usefull error page
[ http://issues.apache.org/jira/browse/VELOCITY-414?page=all ]
Henning Schmiedehausen reassigned VELOCITY-414:
---
Assignee: Henning Schmiedehausen
Extend the MethodInvocation exception to be able to give the velocity macro
writer a usefull error page
---
Key: VELOCITY-414
URL: http://issues.apache.org/jira/browse/VELOCITY-414
Project: Velocity
Issue Type: Improvement
Components: Source
Affects Versions: 1.5, 1.4
Reporter: Matthijs Lambooy
Assigned To: Henning Schmiedehausen
Fix For: 1.5
We use velocity macros that invoke methods in a java written web engine.
When an invoked method fails because of an exception, it is not
possible to use the
MethodInvocation exception to give the velocity macro writer a usefull
error page since the MethodInvocation Exception has not cause set.
So to be short the reason why the method invocation failed can not be
routed back to the veloticy macro writer on a running system.
I extended the MethodInvocationException.java and the method execute in
ASTMethod.java
proposed changes in MethodInvocationException.java :
===
package org.apache.velocity.exception;
import org.apache.velocity.exception.VelocityException;
import org.apache.velocity.runtime.parser.Token;
/*
* Copyright 2001,2004 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
/**
* Application-level exception thrown when a reference method is
* invoked and an exception is thrown.
* br
* When this exception is thrown, a best effort will be made to have
* useful information in the exception's message. For complete
* information, consult the runtime log.
*
* @author a href=mailto:[EMAIL PROTECTED]Geir Magnusson Jr./a
* @version $Id: MethodInvocationException.java,v 1.2.14.1 2004/03/03
23:22:54 geirm Exp $
*/
public class MethodInvocationException extends VelocityException
{
private String methodName = ;
private String referenceName = ;
private Throwable wrapped = null;
private int line; // Added by CX
private int column; // Added by CX
/**
* CTOR - wraps the passed in exception for
* examination later
*
* @param message
* @param e Throwable that we are wrapping
* @param methodName name of method that threw the exception
*/
public MethodInvocationException( String message, Throwable e, String
methodName )
{
super(message);
this.wrapped = e;
this.methodName = methodName;
}
/**
* Returns the name of the method that threw the
* exception
*
* @return String name of method
*/
public String getMethodName()
{
return methodName;
}
/**
* returns the wrapped Throwable that caused this
* MethodInvocationException to be thrown
*
* @return Throwable thrown by method invocation
*/
public Throwable getWrappedThrowable()
{
return wrapped;
}
/**
* Sets the reference name that threw this exception
*
* @param reference name of reference
*/
public void setReferenceName( String ref )
{
referenceName = ref;
}
/**
* Retrieves the name of the reference that caused the
* exception
*
* @return name of reference
*/
public String getReferenceName()
{
return referenceName;
}
/**
* Retrieves the line number where the error occured
*
* @return line number
*/
public int getLine()
{
return line;
}
/**
* Sets the line number where the error occured
*
* @param line
*/
public void setLine(int line)
{
this.line = line;
}
/**
* Retrieves the line number where the error occured
*
* @return column number
*/
public int getColumn()
{
return column;
}
/**
* Sets the column number where the error occured
*
* @param column
*/
[jira] Commented: (VELOCITY-414) Extend the MethodInvocation exception to be able to give the velocity macro writer a usefull error page
[
http://issues.apache.org/jira/browse/VELOCITY-414?page=comments#action_12447181
]
Henning Schmiedehausen commented on VELOCITY-414:
-
Yes, and we actually have everything we need already in place (in form of
ExtendedParseException).
Extend the MethodInvocation exception to be able to give the velocity macro
writer a usefull error page
---
Key: VELOCITY-414
URL: http://issues.apache.org/jira/browse/VELOCITY-414
Project: Velocity
Issue Type: Improvement
Components: Source
Affects Versions: 1.5, 1.4
Reporter: Matthijs Lambooy
Assigned To: Henning Schmiedehausen
Fix For: 1.5
We use velocity macros that invoke methods in a java written web engine.
When an invoked method fails because of an exception, it is not
possible to use the
MethodInvocation exception to give the velocity macro writer a usefull
error page since the MethodInvocation Exception has not cause set.
So to be short the reason why the method invocation failed can not be
routed back to the veloticy macro writer on a running system.
I extended the MethodInvocationException.java and the method execute in
ASTMethod.java
proposed changes in MethodInvocationException.java :
===
package org.apache.velocity.exception;
import org.apache.velocity.exception.VelocityException;
import org.apache.velocity.runtime.parser.Token;
/*
* Copyright 2001,2004 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
/**
* Application-level exception thrown when a reference method is
* invoked and an exception is thrown.
* br
* When this exception is thrown, a best effort will be made to have
* useful information in the exception's message. For complete
* information, consult the runtime log.
*
* @author a href=mailto:[EMAIL PROTECTED]Geir Magnusson Jr./a
* @version $Id: MethodInvocationException.java,v 1.2.14.1 2004/03/03
23:22:54 geirm Exp $
*/
public class MethodInvocationException extends VelocityException
{
private String methodName = ;
private String referenceName = ;
private Throwable wrapped = null;
private int line; // Added by CX
private int column; // Added by CX
/**
* CTOR - wraps the passed in exception for
* examination later
*
* @param message
* @param e Throwable that we are wrapping
* @param methodName name of method that threw the exception
*/
public MethodInvocationException( String message, Throwable e, String
methodName )
{
super(message);
this.wrapped = e;
this.methodName = methodName;
}
/**
* Returns the name of the method that threw the
* exception
*
* @return String name of method
*/
public String getMethodName()
{
return methodName;
}
/**
* returns the wrapped Throwable that caused this
* MethodInvocationException to be thrown
*
* @return Throwable thrown by method invocation
*/
public Throwable getWrappedThrowable()
{
return wrapped;
}
/**
* Sets the reference name that threw this exception
*
* @param reference name of reference
*/
public void setReferenceName( String ref )
{
referenceName = ref;
}
/**
* Retrieves the name of the reference that caused the
* exception
*
* @return name of reference
*/
public String getReferenceName()
{
return referenceName;
}
/**
* Retrieves the line number where the error occured
*
* @return line number
*/
public int getLine()
{
return line;
}
/**
* Sets the line number where the error occured
*
* @param line
*/
public void setLine(int line)
{
this.line = line;
}
/**
* Retrieves the line number where the error occured
*
* @return column number
*/
public int getColumn()
{
return column;
}
/**
*
[jira] Resolved: (VELOCITY-414) Extend the MethodInvocation exception to be able to give the velocity macro writer a usefull error page
[ http://issues.apache.org/jira/browse/VELOCITY-414?page=all ]
Henning Schmiedehausen resolved VELOCITY-414.
-
Resolution: Fixed
Make MethodInvocationException implement ExtendedParseException thus giving it
access to Template name, line number and column number. Not exactly the
suggested patch but the same in spirit. Thanks for the suggestion!
Extend the MethodInvocation exception to be able to give the velocity macro
writer a usefull error page
---
Key: VELOCITY-414
URL: http://issues.apache.org/jira/browse/VELOCITY-414
Project: Velocity
Issue Type: Improvement
Components: Source
Affects Versions: 1.5, 1.4
Reporter: Matthijs Lambooy
Assigned To: Henning Schmiedehausen
Fix For: 1.5
We use velocity macros that invoke methods in a java written web engine.
When an invoked method fails because of an exception, it is not
possible to use the
MethodInvocation exception to give the velocity macro writer a usefull
error page since the MethodInvocation Exception has not cause set.
So to be short the reason why the method invocation failed can not be
routed back to the veloticy macro writer on a running system.
I extended the MethodInvocationException.java and the method execute in
ASTMethod.java
proposed changes in MethodInvocationException.java :
===
package org.apache.velocity.exception;
import org.apache.velocity.exception.VelocityException;
import org.apache.velocity.runtime.parser.Token;
/*
* Copyright 2001,2004 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
/**
* Application-level exception thrown when a reference method is
* invoked and an exception is thrown.
* br
* When this exception is thrown, a best effort will be made to have
* useful information in the exception's message. For complete
* information, consult the runtime log.
*
* @author a href=mailto:[EMAIL PROTECTED]Geir Magnusson Jr./a
* @version $Id: MethodInvocationException.java,v 1.2.14.1 2004/03/03
23:22:54 geirm Exp $
*/
public class MethodInvocationException extends VelocityException
{
private String methodName = ;
private String referenceName = ;
private Throwable wrapped = null;
private int line; // Added by CX
private int column; // Added by CX
/**
* CTOR - wraps the passed in exception for
* examination later
*
* @param message
* @param e Throwable that we are wrapping
* @param methodName name of method that threw the exception
*/
public MethodInvocationException( String message, Throwable e, String
methodName )
{
super(message);
this.wrapped = e;
this.methodName = methodName;
}
/**
* Returns the name of the method that threw the
* exception
*
* @return String name of method
*/
public String getMethodName()
{
return methodName;
}
/**
* returns the wrapped Throwable that caused this
* MethodInvocationException to be thrown
*
* @return Throwable thrown by method invocation
*/
public Throwable getWrappedThrowable()
{
return wrapped;
}
/**
* Sets the reference name that threw this exception
*
* @param reference name of reference
*/
public void setReferenceName( String ref )
{
referenceName = ref;
}
/**
* Retrieves the name of the reference that caused the
* exception
*
* @return name of reference
*/
public String getReferenceName()
{
return referenceName;
}
/**
* Retrieves the line number where the error occured
*
* @return line number
*/
public int getLine()
{
return line;
}
/**
* Sets the line number where the error occured
*
* @param line
*/
public void setLine(int line)
{
this.line = line;
}
/**
* Retrieves the line number where the error occured
*
* @return column number
*/
[jira] Created: (VELTOOLS-68) VelocityViewServlet has hard coded ServletLogger
VelocityViewServlet has hard coded ServletLogger Key: VELTOOLS-68 URL: http://issues.apache.org/jira/browse/VELTOOLS-68 Project: VelocityTools Issue Type: Bug Components: VelocityView Affects Versions: 1.3 Reporter: Henning Schmiedehausen Priority: Minor VelocityViewServlet configures the Velocity engine to use the ServletLogger (~line 323). Integration of the servlet into applications that use other logging systems (e.g. log4j / commons-logging) is very hard because of that. - VVS should honor the logging setttings in velocity.properties (e.g. for explicit jdk logging) - It should add the ServletLogger to the log engine search path and only use it if no other logger was found (log4j / avalon etc.) - The ServletLogger class implements the deprecated LogSystem. VelocityTools should provide a LogChute implementation of the SrevletLogger. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-24) calls to local macros not always made when template caching is off
[ http://issues.apache.org/jira/browse/VELOCITY-24?page=all ] Henning Schmiedehausen updated VELOCITY-24: --- Bugzilla Id: (was: 4483) Affects Version/s: 1.5 beta1 (was: 1.1-rc2) Priority: Blocker (was: Major) Issue is trivially reproducable using ab -c 2 -n 8 http://localhost:8080/testbed/templates/issues/velocity-24.vm There definitely is a race condition somewhere in the Velocity engine that should be fixed for 1.5. Raising prio to blocker for 1.5. calls to local macros not always made when template caching is off -- Key: VELOCITY-24 URL: http://issues.apache.org/jira/browse/VELOCITY-24 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.5 beta1 Environment: Operating System: other Platform: Other Reporter: peterwlynch Priority: Blocker Fix For: 1.5 In the latest nightly build Oct 28, 2001 and also in velocity 1.2 rc2 i noticed the following problem with autoreloading macros. Made a simple html page. added a simple one line macro that accepted one param, a letter something like ## local macro, not global #macro(letter $char) This is the letter $char #end #letter(A) #letter(B) #letter(C) etc to Z -- The html page would be loaded in response to a form being submitted. If I clicked on the submit button five times, quickly ( five separate submits), most times the final response would out put something like... This is the letter A This is the letter B This is the letter C This is the letter D This is the letter E #letter#letter#letter #letter .. This is the letter Z As you can see, some macro calls did not get parsed. We were just happening to use velocity through turbine, but I don't think that affects the bug. Besides, the bug went away when the autoreload was false. Once scarab's runbox is back up, might be interesting to test this out on their macros too for comparison, although I don't see that they have any local macros. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-24) calls to local macros not always made when template caching is off
[ http://issues.apache.org/jira/browse/VELOCITY-24?page=comments#action_12447018 ] Henning Schmiedehausen commented on VELOCITY-24: hmmm. it seems that the whole getTemplate() path is not really threadsafe with respect to local macros. The culprit lies in the dumpNamespace() methods. Will investigate further... calls to local macros not always made when template caching is off -- Key: VELOCITY-24 URL: http://issues.apache.org/jira/browse/VELOCITY-24 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.5 beta1 Environment: Operating System: other Platform: Other Reporter: peterwlynch Priority: Blocker Fix For: 1.5 In the latest nightly build Oct 28, 2001 and also in velocity 1.2 rc2 i noticed the following problem with autoreloading macros. Made a simple html page. added a simple one line macro that accepted one param, a letter something like ## local macro, not global #macro(letter $char) This is the letter $char #end #letter(A) #letter(B) #letter(C) etc to Z -- The html page would be loaded in response to a form being submitted. If I clicked on the submit button five times, quickly ( five separate submits), most times the final response would out put something like... This is the letter A This is the letter B This is the letter C This is the letter D This is the letter E #letter#letter#letter #letter .. This is the letter Z As you can see, some macro calls did not get parsed. We were just happening to use velocity through turbine, but I don't think that affects the bug. Besides, the bug went away when the autoreload was false. Once scarab's runbox is back up, might be interesting to test this out on their macros too for comparison, although I don't see that they have any local macros. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (VELOCITY-423) Report invalid references
[ http://issues.apache.org/jira/browse/VELOCITY-423?page=all ] Henning Schmiedehausen reopened VELOCITY-423: - The following Javadoc Issues were introduced by the patches related here. As Javadocs are currently the most important documentation for this feature, it would be good if the docs are really up to date to the function. I e.g. hunted for quite a while for *what* is returned from invalidGetMethod()... [javadoc] /home/scratch/velocity/engine/bin/src/org/apache/velocity/app/event/EventHandlerMethodExecutor.java:47: warning - @return tag has no arguments. [javadoc] /home/scratch/velocity/engine/bin/src/org/apache/velocity/app/event/EventHandlerUtil.java:248: warning - @return tag has no arguments. [javadoc] /home/scratch/velocity/engine/bin/src/org/apache/velocity/app/event/EventHandlerUtil.java:296: warning - @return tag has no arguments. [javadoc] /home/scratch/velocity/engine/bin/src/org/apache/velocity/app/event/EventHandlerUtil.java:316: warning - @return tag has no arguments. [javadoc] /home/scratch/velocity/engine/bin/src/org/apache/velocity/app/event/EventHandlerUtil.java:271: warning - @param argument reference is not a parameter name. [javadoc] /home/scratch/velocity/engine/bin/src/org/apache/velocity/app/event/EventHandlerUtil.java:271: warning - @param argument object is not a parameter name. [javadoc] /home/scratch/velocity/engine/bin/src/org/apache/velocity/app/event/EventHandlerUtil.java:271: warning - @param argument property is not a parameter name. [javadoc] /home/scratch/velocity/engine/bin/src/org/apache/velocity/app/event/InvalidReferenceEventHandler.java:70: warning - @param argument property is not a parameter name. [javadoc] /home/scratch/velocity/engine/bin/src/org/apache/velocity/app/event/InvalidReferenceEventHandler.java:70: warning - @param argument if is not a parameter name. [javadoc] /home/scratch/velocity/engine/bin/src/org/apache/velocity/app/event/MethodExceptionEventHandler.java:83: warning - @return tag cannot be used in method with void return type. [javadoc] /home/scratch/velocity/engine/bin/src/org/apache/velocity/app/event/implement/ReportInvalidReferences.java:131: warning - @param argument reference is not a parameter name. [javadoc] /home/scratch/velocity/engine/bin/src/org/apache/velocity/app/event/implement/ReportInvalidReferences.java:131: warning - @param argument object is not a parameter name. [javadoc] /home/scratch/velocity/engine/bin/src/org/apache/velocity/app/event/implement/ReportInvalidReferences.java:131: warning - @param argument method is not a parameter name. [javadoc] /home/scratch/velocity/engine/bin/src/org/apache/velocity/app/event/implement/ReportInvalidReferences.java:131: warning - @param argument always is not a parameter name. Report invalid references - Key: VELOCITY-423 URL: http://issues.apache.org/jira/browse/VELOCITY-423 Project: Velocity Issue Type: New Feature Components: Source Reporter: Will Glass-Husain Assigned To: Will Glass-Husain Fix For: 1.5 Attachments: invalidreference.txt I've made a new patch that includes a ReferenceInsertionEventHandler (InvalidReferenceHandler) that collects a list of all invalid references in a Velocity page. To see how it works, look at the test code (the last two methods) in BuiltInEventHandlerTestCase. To make this work, I had to make some changes to the internals. So I thought I'd hold off a couple days before committing, let any interested parties comment. There's a couple of interesting new pieces for plugin writers. (1) In any user-defined plugin (event handlers, uberspectors, etc) you can now throw a subclass of VelocityRuntimeException (new exception). to signal unrecoverable states to the calling application. This runtime exception requires no change to the interface signature and is passed through the Velocity parsing process. (In the past, all Exceptions were caught and logged). Example use: a custom uberspector or event handler that wishes to stop page processing. For example, the InvalidReferenceHandler can be configured to throw an exception at the first reference error. (2) Event handlers can now receive information on the template name, line number, and column by implementing InfoAware. This only works for Local event handlers attached to a context (as opposed to the new Global type defined in Velocity properties). Example use: InvalidReferenceHandler reports out the line,column, and template name of each reference error. Everything is completely backwards compatible. It'd be simpler if it wasn't of course as they we could just redo the interfaces. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the
[jira] Commented: (VELOCITY-471) Create velocity.apache.org
[ http://issues.apache.org/jira/browse/VELOCITY-471?page=comments#action_12445543 ] Henning Schmiedehausen commented on VELOCITY-471: - Created INFRA-1011. Create velocity.apache.org -- Key: VELOCITY-471 URL: http://issues.apache.org/jira/browse/VELOCITY-471 Project: Velocity Issue Type: Sub-task Components: Website Reporter: Henning Schmiedehausen Assigned To: Henning Schmiedehausen Trigger infrastructure@ to create velocity.apache.org -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (VELOCITY-471) Create velocity.apache.org
[ http://issues.apache.org/jira/browse/VELOCITY-471?page=all ] Henning Schmiedehausen reassigned VELOCITY-471: --- Assignee: Henning Schmiedehausen Create velocity.apache.org -- Key: VELOCITY-471 URL: http://issues.apache.org/jira/browse/VELOCITY-471 Project: Velocity Issue Type: Sub-task Components: Website Reporter: Henning Schmiedehausen Assigned To: Henning Schmiedehausen Trigger infrastructure@ to create velocity.apache.org -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELTOOLS-66) Velocity Tools gives access exception with $request reference under Tomcat security manager
[
http://issues.apache.org/jira/browse/VELTOOLS-66?page=comments#action_12445455
]
Henning Schmiedehausen commented on VELTOOLS-66:
Just a quick brain fart: If you do the reflection not on the
org.apache.catalina.xxx object but on the implemented interface (i.e. treat
session as a javax.servlet.http.HttpSession object), does it work?
if yes, it might be possible to enhance the Introspector that when it
encounters a security violation, it looks up the implemented interfaces and
tries reflection on these. Sucky and probably dog slow, but might work.
Velocity Tools gives access exception with $request reference under Tomcat
security manager
---
Key: VELTOOLS-66
URL: http://issues.apache.org/jira/browse/VELTOOLS-66
Project: VelocityTools
Issue Type: New Feature
Components: VelocityView
Affects Versions: 1.2
Reporter: Will Glass-Husain
I'm labeling this as a bug, though it's arguable whether the fault is of
Tomcat or Velocity. Regardless, we should apply a workaround. I've
replicated this issue with Velocity 1.4 / Tools 1.2 / JDK 1.5 / Tomcat 5.5
The problem. When the Tomcat is run under the default security manager
settings, it prohibits reflection on org.catalina classes. This means that
the reference $request.session.id fails with an access violation
INFO: Velocity [error] PROGRAMMER ERROR : PropertyExector() :
java.security.AccessControlException: access denied
(java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina.connector)
sometimes the package given is org.apache.catalina.core, somtimes
org.apache.catalina.session, depending on various factors.
Users can alter their security policy to allow this access. But this is an
obscure procedure and may not be feasible if you do not control your hosting
environment. For the record, the settings for catalina.policy are (change
the path to suit your webapp)
grant codeBase
file:${catalina.home}/webapps/simple/WEB-INF/lib/velocity-1.4.jar
{
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina.connector;
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina.session;
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina.core;
};
grant codeBase
file:${catalina.home}/webapps/simple/WEB-INF/lib/velocity-tools-view-1.2.jar
{
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina.connector;
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina.session;
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina.core;
};
As an alternative, I propose that the Velocity Tools project solve this by
create a wrapper object for HttpServletRequest. (presumably the problem also
exists for $response, though I haven't tried it). This object would simply
pass through all calls to the server-provided HttpServletRequest. Obviously,
there would need to be a parallel wrapper for HttpSession,
HttpServletContext, and similar objects available from HttpServletRequest
methods. The result would be that the Velocity page would never apply
reflection to a Catalina class. (and hence never generate this security
error).
This issue is in reference to a problem encountered and described on the user
list by Robin Mannering.
http://www.mail-archive.com/velocity-user@jakarta.apache.org/msg17060.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-468) Allowing putting objects into control context from VTL
[ http://issues.apache.org/jira/browse/VELOCITY-468?page=comments#action_12445456 ] Henning Schmiedehausen commented on VELOCITY-468: - That patch is actually just a band-aid to texen. The whole thing should either be rewritten or go (IMHO). There are newer solutions (i.e. the one in maven-2) that are much more versatile than the aged texen thing. Allowing putting objects into control context from VTL -- Key: VELOCITY-468 URL: http://issues.apache.org/jira/browse/VELOCITY-468 Project: Velocity Issue Type: Improvement Components: Texen Affects Versions: 1.4 Reporter: Mojmir Hanes Priority: Minor Fix For: 1.6 Attachments: Generator.java.diff I think it would be nice to allow putting objects into control context in VTL. The motivation is straightforward - in some cases you need to put more than one object into context before parsing particular template, so method org.apache.velocity.texen.parse(String inputTemplate, String outputFile, String objectID,Object object) doesn't match your need. What do you think ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (VELOCITY-472) Move Mailing lists to velocity.apache.org
Move Mailing lists to velocity.apache.org - Key: VELOCITY-472 URL: http://issues.apache.org/jira/browse/VELOCITY-472 Project: Velocity Issue Type: Sub-task Components: Website Reporter: Henning Schmiedehausen Move Mailing lists to velocity.apache.org -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (VELOCITY-470) Set up Velocity TLP web site and move there.
Set up Velocity TLP web site and move there. Key: VELOCITY-470 URL: http://issues.apache.org/jira/browse/VELOCITY-470 Project: Velocity Issue Type: Task Components: Website Reporter: Henning Schmiedehausen Assigned To: Henning Schmiedehausen Do the necessary steps to move us to TLP. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (VELOCITY-471) Create velocity.apache.org
Create velocity.apache.org -- Key: VELOCITY-471 URL: http://issues.apache.org/jira/browse/VELOCITY-471 Project: Velocity Issue Type: Sub-task Components: Website Reporter: Henning Schmiedehausen Trigger infrastructure@ to create velocity.apache.org -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (VELOCITY-473) Create wrapper site for velocity TLP
Create wrapper site for velocity TLP Key: VELOCITY-473 URL: http://issues.apache.org/jira/browse/VELOCITY-473 Project: Velocity Issue Type: Sub-task Components: Website Reporter: Henning Schmiedehausen Take the contents of http://svn.apache.org/viewvc/jakarta/velocity/site/ and revamp it into a wrapper site that can be used as main site for all Velocity TLP subprojects (engine, tools, DVSL at the moment) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (VELOCITY-474) Get a Solaris zone for Velocity
Get a Solaris zone for Velocity --- Key: VELOCITY-474 URL: http://issues.apache.org/jira/browse/VELOCITY-474 Project: Velocity Issue Type: Sub-task Components: Website Reporter: Henning Schmiedehausen Get a Solaris zone for the Velocity TLP to set up nightlies / tests etc. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELTOOLS-65) Move to the Maven build system.
[ http://issues.apache.org/jira/browse/VELTOOLS-65?page=comments#action_12442062 ] Henning Schmiedehausen commented on VELTOOLS-65: Thomas, you are right, I should elaborate on that. I'm also a part of the Turbine team, the project that Maven sprang from. My basic issue here is (as most people know that ever had to endure one of my rants about it) that a maven based build is IMHO neither stable nor repeatable. The ant build is and it is important to me to be able to have a stable, hassle-free build. Uploading the binaries and sources to a maven archive automatically is really a plus and getting patches here would be greatly appriated. I know that you can drive the deployment side of maven using ant integration but haven't looked into it. As I said, I'm willing to accept patches to engine for building with maven 2, Natan does the same for velocity-tools, however until maven has been proven to amend on these problems, ant will be first-class citizen for building. Move to the Maven build system. --- Key: VELTOOLS-65 URL: http://issues.apache.org/jira/browse/VELTOOLS-65 Project: VelocityTools Issue Type: New Feature Components: Build Affects Versions: 1.3 Reporter: Thomas Minor Since Velocity 1.5 is moving to maven andVelocity-Tools users will almost certain also use maven Velocity-Tools should also move to maven as the build system. That way it could be easily included in maven projects. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (VELOCITY-466) Look into maven plugins for ant to use automatic deployment to maven repositories
Look into maven plugins for ant to use automatic deployment to maven repositories - Key: VELOCITY-466 URL: http://issues.apache.org/jira/browse/VELOCITY-466 Project: Velocity Issue Type: Improvement Components: Build Affects Versions: 1.5 Reporter: Henning Schmiedehausen Assigned To: Henning Schmiedehausen Priority: Minor Fix For: 1.5 there are maven plugins that can be driven by ant to automatically deploy the velocity builds to the maven repositories (suggested by Thomas Minor, thanks) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELTOOLS-65) Move to the Maven build system.
[ http://issues.apache.org/jira/browse/VELTOOLS-65?page=comments#action_12442066 ] Henning Schmiedehausen commented on VELTOOLS-65: I openend VELOCITY-466 to look into this. Thanks. Move to the Maven build system. --- Key: VELTOOLS-65 URL: http://issues.apache.org/jira/browse/VELTOOLS-65 Project: VelocityTools Issue Type: New Feature Components: Build Affects Versions: 1.3 Reporter: Thomas Minor Since Velocity 1.5 is moving to maven andVelocity-Tools users will almost certain also use maven Velocity-Tools should also move to maven as the build system. That way it could be easily included in maven projects. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-82) VM libs will not autoreload if unparseable at Velocity startup
[ http://issues.apache.org/jira/browse/VELOCITY-82?page=comments#action_12441756 ] Henning Schmiedehausen commented on VELOCITY-82: The problem here is twofold and IMHO fixing it for 1.5 is hard. First, this is an error. If a macro library that is supposed to be loaded cannot be loaded for whatever reason, it is debatable whether this is actually a fatal error and it shouldn't just report in the log file but stop the initialization of the engine altogether. Will proposed the creation of a VelocityInitException which would be thrown in that case. Second, fixing it so that the cache notices there is a macro library available though this resource loader, but it is currently buggy, let's go back after the check interval and see if this has changed at init time is hard. If an existing library that parsed fine the first time gets broken, then the cache simply keeps the last good version (it is argueable whether this is the right behaviour, too). But if there is no good version in the first place, the current internal mechanism of loading resources have to be rewritten (differentiate between unloaded - loaded, but not yet parsed - parsed). I'm afraid that is out of the question for 1.5 and probably most of the 1.x series. VM libs will not autoreload if unparseable at Velocity startup -- Key: VELOCITY-82 URL: http://issues.apache.org/jira/browse/VELOCITY-82 Project: Velocity Issue Type: Bug Components: Source Affects Versions: 1.3-rc1 Environment: Operating System: Linux Platform: All Reporter: Michael Pearson Priority: Minor Fix For: 2.0 I'm using Velocity 1.3-rc1 (updated from CVS (tag TVEL_1_3_BRANCH) as at 28th of May, 2002) on a Redhat 7.2 system, combined with velocity-tools/struts and velocity-tools/view from latest cvs. When a velocimacro library is loaded at initialisation time, it is normally added to the libModMap hash in VelocimacroFactory. The libModMap hash is checked when reloading velocimacro templates. However, if the parsing of the velocimacro library fails midway through, the macros are added to the namespace but the Template is not returned to VelocimacroFactory, and thus not added to libModMap. This means that if a VM library is broken at initialization time, it will never be reloaded until Velocity is restarted. I have not tried this under the HEAD tagged CVS sources, as my macros refuse to parse at all using this branch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VELOCITY-82) VM libs will not autoreload if unparseable at Velocity startup
[ http://issues.apache.org/jira/browse/VELOCITY-82?page=all ] Henning Schmiedehausen resolved VELOCITY-82. Fix Version/s: 2.0 (was: 1.5) Resolution: Later VM libs will not autoreload if unparseable at Velocity startup -- Key: VELOCITY-82 URL: http://issues.apache.org/jira/browse/VELOCITY-82 Project: Velocity Issue Type: Bug Components: Source Affects Versions: 1.3-rc1 Environment: Operating System: Linux Platform: All Reporter: Michael Pearson Priority: Minor Fix For: 2.0 I'm using Velocity 1.3-rc1 (updated from CVS (tag TVEL_1_3_BRANCH) as at 28th of May, 2002) on a Redhat 7.2 system, combined with velocity-tools/struts and velocity-tools/view from latest cvs. When a velocimacro library is loaded at initialisation time, it is normally added to the libModMap hash in VelocimacroFactory. The libModMap hash is checked when reloading velocimacro templates. However, if the parsing of the velocimacro library fails midway through, the macros are added to the namespace but the Template is not returned to VelocimacroFactory, and thus not added to libModMap. This means that if a VM library is broken at initialization time, it will never be reloaded until Velocity is restarted. I have not tried this under the HEAD tagged CVS sources, as my macros refuse to parse at all using this branch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VELOCITY-462) Change headers in source files to comply with new license header policy
[ http://issues.apache.org/jira/browse/VELOCITY-462?page=all ] Henning Schmiedehausen resolved VELOCITY-462. - Resolution: Fixed Files have been bulk-changed. We are now in compliance with the policy post Nov 1st. Change headers in source files to comply with new license header policy --- Key: VELOCITY-462 URL: http://issues.apache.org/jira/browse/VELOCITY-462 Project: Velocity Issue Type: Improvement Components: Source Affects Versions: 1.5 beta1 Reporter: Will Glass-Husain Assigned To: Henning Schmiedehausen Fix For: 1.5 The text at the top of every source file must be changed according to new ASF rules adopted this Spring. The changes are intended to improve cliarity and make the files easier to maintain. According to the new policy, this must be implemented for any release after November 1, 2006. Archived old releases do not need to be changed. There's some scripts available to help out. More info at: http://www.apache.org/legal/src-headers.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VELOCITY-214) References to non-public members (inner classes, fields, etc.) should log a warning rather than failing silently
[ http://issues.apache.org/jira/browse/VELOCITY-214?page=all ] Henning Schmiedehausen resolved VELOCITY-214. - Resolution: Won't Fix Assignee: (was: Daniel Resare) Well, it does report the [info] Null reference [template 'testbed/test.vm', line 1, column 51] : $private.Bar cannot be resolved. in the log file with Velocity 1.5. the problem here is, that we cannot really distinguish whether this is just a typo or really a private/protected function and even if we could, we do run chains of method lookups (e.g. for getters, we are looking for getfoo, getFoo, get(foo)) so reporting functions that we could not find would log a number of false positives that might be even more confusing than not explicitly logging non-accessible functions. And as we don't want to play games with changing the visiblity of the methods on the fly, we are basically stuck with what we have. That is reporting null reference, $private.Bar cannot be resolved. We should add a note to the manual, though. References to non-public members (inner classes, fields, etc.) should log a warning rather than failing silently Key: VELOCITY-214 URL: http://issues.apache.org/jira/browse/VELOCITY-214 Project: Velocity Issue Type: Bug Components: Source Affects Versions: 1.3.1 Environment: Operating System: other Platform: Other Reporter: Daniel Resare Priority: Minor Fix For: 1.5 Attachments: test.vm, VelocibugTest.java When I try to access a property on an object through the context and the defining class of that object is a non-public inner class the reference fails as if there was no object for that key in the context. I'd like to at least get a userful error message in the log. I have reproduced this with both velocity-1.3.1 and cvs HEAD as of today. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VELOCITY-264) Escaping in form of $\!{foo} does not work
[ http://issues.apache.org/jira/browse/VELOCITY-264?page=all ]
Henning Schmiedehausen resolved VELOCITY-264.
-
Fix Version/s: 2.0
(was: 1.5)
Resolution: Later
Yes, this is due to the weird parser magic in respect to escaping and comments.
This is due to a really big cleanup in 2.0. For the moment, this is more of a
don't try this at home, kid problem. We also need to add a note to the docs
about this.
Escaping in form of $\!{foo} does not work
Key: VELOCITY-264
URL: http://issues.apache.org/jira/browse/VELOCITY-264
Project: Velocity
Issue Type: Bug
Components: Source
Affects Versions: 1.4
Environment: Operating System: All
Platform: PC
Reporter: oleg
Priority: Minor
Fix For: 2.0
Below are the results of executing app_example1 with a modified example.vm
file. The content of the example.vm is a copy-paste from Velocity Userâ??s
Guide
(see the URL). Note that $\!{foo} was rendered to $!{, instead of
$!{foo}
as expected:
D:\dev\velocity-1.4\examples\app_example1type example.vm
#set( $foo = bar )
$\!foo
$\!{foo}
$\\!foo
$\\\!foo
D:\dev\velocity-1.4\examples\app_example1example
Using classpath: .;..\..\bin\velocity-1.4.jar;..\..\bin\velocity-dep-1.4.jar
$!foo
$!{
$\!foo
$\\!foo
D:\dev\velocity-1.4\examples\app_example1
Surprisingly, I could really use this feature :) as I want to evaluate my
template in two steps: cache the result of the first generic step and then
reuse it to generate various final messages.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VELOCITY-251) $\!{foo} doesn't render as expected
[ http://issues.apache.org/jira/browse/VELOCITY-251?page=all ]
Henning Schmiedehausen resolved VELOCITY-251.
-
Fix Version/s: 2.0
(was: 1.5)
Resolution: Duplicate
This is a dup.
$\!{foo} doesn't render as expected
---
Key: VELOCITY-251
URL: http://issues.apache.org/jira/browse/VELOCITY-251
Project: Velocity
Issue Type: Bug
Components: Source
Affects Versions: 1.5
Environment: Operating System: other
Platform: Other
Reporter: JiaYun
Fix For: 2.0
Aaccording to the User Guide, $\!{foo} should render as $!{foo}, but the
actual output is $!{ whether $foo was defined or not.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (VELOCITY-463) Finish the docbook based documentation for Velocity 1.5
Finish the docbook based documentation for Velocity 1.5 --- Key: VELOCITY-463 URL: http://issues.apache.org/jira/browse/VELOCITY-463 Project: Velocity Issue Type: Task Components: Engine Affects Versions: 1.5 Reporter: Henning Schmiedehausen Assigned To: Henning Schmiedehausen Priority: Blocker Fix For: 1.5 We have docbook based Documenation coming up at http://svn.apache.org/repos/asf/jakarta/velocity/docbook/trunk This should be finished before releasing 1.5. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (VELOCITY-464) Finish the user guide
Finish the user guide - Key: VELOCITY-464 URL: http://issues.apache.org/jira/browse/VELOCITY-464 Project: Velocity Issue Type: Sub-task Affects Versions: 1.5 Reporter: Henning Schmiedehausen Fix For: 1.5 Docbook based user guide. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (VELOCITY-464) Finish the user guide
[ http://issues.apache.org/jira/browse/VELOCITY-464?page=all ] Henning Schmiedehausen reassigned VELOCITY-464: --- Assignee: Henning Schmiedehausen Finish the user guide - Key: VELOCITY-464 URL: http://issues.apache.org/jira/browse/VELOCITY-464 Project: Velocity Issue Type: Sub-task Affects Versions: 1.5 Reporter: Henning Schmiedehausen Assigned To: Henning Schmiedehausen Fix For: 1.5 Docbook based user guide. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-464) Finish the user guide
[ http://issues.apache.org/jira/browse/VELOCITY-464?page=comments#action_12441817 ] Henning Schmiedehausen commented on VELOCITY-464: - resolve the VELOCITY-264 doc issue. Finish the user guide - Key: VELOCITY-464 URL: http://issues.apache.org/jira/browse/VELOCITY-464 Project: Velocity Issue Type: Sub-task Affects Versions: 1.5 Reporter: Henning Schmiedehausen Assigned To: Henning Schmiedehausen Fix For: 1.5 Docbook based user guide. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-464) Finish the user guide
[ http://issues.apache.org/jira/browse/VELOCITY-464?page=comments#action_12441818 ] Henning Schmiedehausen commented on VELOCITY-464: - resolve the VELOCITY-214 doc issue Finish the user guide - Key: VELOCITY-464 URL: http://issues.apache.org/jira/browse/VELOCITY-464 Project: Velocity Issue Type: Sub-task Affects Versions: 1.5 Reporter: Henning Schmiedehausen Assigned To: Henning Schmiedehausen Fix For: 1.5 Docbook based user guide. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VELOCITY-280) Parsing of braces after a reference fails
[ http://issues.apache.org/jira/browse/VELOCITY-280?page=all ]
Henning Schmiedehausen resolved VELOCITY-280.
-
Fix Version/s: 2.0
(was: 1.5)
Resolution: Later
This problem is related to the complicated parser structure that tries to
resolve references. While I'm able to patch the parser to actually let these
elements pass through, this leads to other side effects. Really fixing this
stuff needs probably some rewrite of the Parser.jj file; if anyone is willing
to do this for 1.5, I'd be more than willing to put that in, else it will get
postponed to 2.0
Parsing of braces after a reference fails
-
Key: VELOCITY-280
URL: http://issues.apache.org/jira/browse/VELOCITY-280
Project: Velocity
Issue Type: Bug
Components: Source
Affects Versions: 1.4
Environment: Operating System: Windows XP
Platform: All
Reporter: Ilkka Priha
Priority: Minor
Fix For: 2.0
Parsing of braces '{}' after a reference fails in all cases:
$foo{bar}
produces
$foo{
\$foo{bar}
produces
\$foo{
#set ($foo = 'foo')
$foo{bar}
produces
foo{
\$foo{bar}
produces
$foo{
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VELOCITY-209) Encountered ) Was expecting one of: )
[ http://issues.apache.org/jira/browse/VELOCITY-209?page=all ] Henning Schmiedehausen resolved VELOCITY-209. - Fix Version/s: 2.0 (was: 1.5) Resolution: Later Assignee: (was: Velocity-Dev List) This is related to BigDecimal not being a reference and getting lost in the parse process. This is reproducable but is just as VELOCITY-280 it doesn't seem to be easily solvable. As with VELOCITY-280, is someone comes up with a patch to the Parser.jj file to fix this, I'm fine to apply it to the 1.5 release, else it goes to the great parser rewrite in 2.0 Encountered ) Was expecting one of: ) --- Key: VELOCITY-209 URL: http://issues.apache.org/jira/browse/VELOCITY-209 Project: Velocity Issue Type: Bug Components: Source Affects Versions: 1.3.1 Environment: Operating System: All Platform: PC Reporter: Mike Kienenberger Priority: Minor Fix For: 2.0 The following velocity directive (which IS NOT proper code and should create a meaningful error) #if ( (1 == $currentAccount.getAmountDue().compareTo(BigDecimal.valueOf(0))) ($currentAccount.isAccountStatusActive()) (0 == $currentAccount.scheduledPaymentList().size()) ) gives this error: Encountered ) at line 27, column 75. Was expecting one of: , ... ) ... ... ... Handcopied from veloedit in Eclipse (a little clearer): Encountered ) at line 27, column 75. [After BigDecimal.valueOf(0)] Was expecting one of: , ... ) ... WHITESPACE ... DOT ... The error thrown is internally-inconsistent (the parser found a right-paren, but expected to find a right-paren) and useless. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (VELOCITY-462) Change headers in source files to comply with new license header policy
[ http://issues.apache.org/jira/browse/VELOCITY-462?page=all ] Henning Schmiedehausen reassigned VELOCITY-462: --- Assignee: Henning Schmiedehausen Change headers in source files to comply with new license header policy --- Key: VELOCITY-462 URL: http://issues.apache.org/jira/browse/VELOCITY-462 Project: Velocity Issue Type: Improvement Components: Source Affects Versions: 1.5 beta1 Reporter: Will Glass-Husain Assigned To: Henning Schmiedehausen Fix For: 1.5 The text at the top of every source file must be changed according to new ASF rules adopted this Spring. The changes are intended to improve cliarity and make the files easier to maintain. According to the new policy, this must be implemented for any release after November 1, 2006. Archived old releases do not need to be changed. There's some scripts available to help out. More info at: http://www.apache.org/legal/src-headers.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-462) Change headers in source files to comply with new license header policy
[ http://issues.apache.org/jira/browse/VELOCITY-462?page=comments#action_12441467 ] Henning Schmiedehausen commented on VELOCITY-462: - I have a tool that can bulk-change these headers. I'll get onto it. Change headers in source files to comply with new license header policy --- Key: VELOCITY-462 URL: http://issues.apache.org/jira/browse/VELOCITY-462 Project: Velocity Issue Type: Improvement Components: Source Affects Versions: 1.5 beta1 Reporter: Will Glass-Husain Assigned To: Henning Schmiedehausen Fix For: 1.5 The text at the top of every source file must be changed according to new ASF rules adopted this Spring. The changes are intended to improve cliarity and make the files easier to maintain. According to the new policy, this must be implemented for any release after November 1, 2006. Archived old releases do not need to be changed. There's some scripts available to help out. More info at: http://www.apache.org/legal/src-headers.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VELOCITY-71) False positive error condition parsing VM_global_library.vm
[ http://issues.apache.org/jira/browse/VELOCITY-71?page=all ] Henning Schmiedehausen resolved VELOCITY-71. Resolution: Fixed This is more of a reporting issue than an actual but. Fixed in 1.5. False positive error condition parsing VM_global_library.vm --- Key: VELOCITY-71 URL: http://issues.apache.org/jira/browse/VELOCITY-71 Project: Velocity Issue Type: Bug Components: Source Affects Versions: 1.3-rc1 Environment: Operating System: Linux Platform: Other Reporter: Daniel Rall Priority: Minor Fix For: 1.5 This bug is actually against 1.3 RC1, but there is no Version listing for that in the Bugzilla config. The initial parsing of the global Velocimacro library is incorrectly indicating an error when context variables which are not passed in as arguments to a macro are used when calling one macro within the body of another. Confusing, eh? I assume that this could be worked around by putting double quotes around the supposedly non-existent arguments to the invoked macro, but was wondering if this was a bug. Included is a sample problem case and some log output. From VM_global_library.vm: #macro(linkedLoginName $acl $user) #linkIf($user.isEditableBy($acl) $currentDomain.getProjectPageURL(UserEdit, userID=$user.getID()) $user.getLoginName()) #end #macro(linkIf $condition $link $text) #if ($condition) a href=$link$text/a #else $text #end #end From velocity.log: 2002-05-01 15:04:28,496 - Velocimacro : added new VM : #enterHelp( filename linktext ) : source = VM_global_library.vm 2002-05-01 15:04:28,843 - VM #linkIf: error : too few arguments to macro. Wanted 3 got 0 2002-05-01 15:04:28,847 - VM #servletLink: error : too few arguments to macro. Wanted 2 got 0 2002-05-01 15:04:28,848 - VM #servletLink: error : too few arguments to macro. Wanted 2 got 0 2002-05-01 15:04:28,849 - VM #servletLink: error : too few arguments to macro. Wanted 2 got 0 2002-05-01 15:04:28,857 - VM #displayProjectTreeAsOptions: error : too few arguments to macro. Wanted 4 got 0 2002-05-01 15:04:28,907 - VM #selectYear: error : too few arguments to macro. Wanted 2 got 0 2002-05-01 15:04:28,907 - VM #selectMonth: error : too few arguments to macro. Wanted 1 got 0 2002-05-01 15:04:28,908 - VM #selectDay: error : too few arguments to macro. Wanted 1 got 0 2002-05-01 15:04:29,109 - ResourceManager : found VM_global_library.vm with loader org.apache.velocity.runtime.resource.loader.FileResourceLoader 2002-05-01 15:04:29,113 - Velocimacro : VM library template macro registration complete. 2002-05-01 15:04:29,113 - Velocimacro : allowInline = true : VMs can be defined inline in templates -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VELOCITY-456) Uberspector chokes on a number of corner cases
[ http://issues.apache.org/jira/browse/VELOCITY-456?page=all ] Henning Schmiedehausen resolved VELOCITY-456. - Resolution: Fixed Corner cases fixed for 1.5 Uberspector chokes on a number of corner cases -- Key: VELOCITY-456 URL: http://issues.apache.org/jira/browse/VELOCITY-456 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.4, 1.5 Reporter: Henning Schmiedehausen Assigned To: Henning Schmiedehausen Fix For: 1.5 The uberspector can be tricked into strange errors like java.lang.StringIndexOutOfBoundsException by passing some unusual property names like or null. It should catch these problems and behave reasonable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VELOCITY-449) Velocity Uberspector behaves differently for get(String) and put(String, Object) methods
[ http://issues.apache.org/jira/browse/VELOCITY-449?page=all ]
Henning Schmiedehausen resolved VELOCITY-449.
-
Resolution: Fixed
Patch will be in 1.5 release.
Velocity Uberspector behaves differently for get(String) and put(String,
Object) methods
Key: VELOCITY-449
URL: http://issues.apache.org/jira/browse/VELOCITY-449
Project: Velocity
Issue Type: Bug
Affects Versions: 1.5
Reporter: Henning Schmiedehausen
Fix For: 1.5
Consider an Object
public class Test {
private Object foo;
public Object get(String dummy) { return foo; }
public void put(String dummy, Object foo) { this.foo = foo };
}
Put this object into a Velocity Context as $test, add a HashMap as $map.
Use the following template:
$map.put(key, val1)
$test.put(key, val1)
$map.get(key) -- Returns val1
$test.get(key) -- Returns val1
$map.key -- Returns val1
$test.key -- Returns val1
#set ($map.key = val2)
#set ($test.key = val2)
$map.key -- Returns val2
$test.key -- Returns val1 !!
The reason for this is, that the UberspectorImpl, in getPropertySet tests in
line 247 whether the passed object is assignable to a Map. This test is no in
the getPropertyGet
and seems to have no reason because the following method lookup for put
will succeed anyway.
I'd suggest the removal of this test.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELTOOLS-62) New empty interfaces that allow one to enforce the scope of a tool
[ http://issues.apache.org/jira/browse/VELTOOLS-62?page=comments#action_12435425 ] Henning Schmiedehausen commented on VELTOOLS-62: I'm also no longer fond of marker interfaces; Spring showed the right approach here. We could investigated xdoclet here but it would introduce a new depenency. Why must the visibility detemined by the tool itself? Isn't that actually something that *should* be kept in the toolbox configuration? What if the toolbox config and the scope requested by the tool don't match up? New empty interfaces that allow one to enforce the scope of a tool -- Key: VELTOOLS-62 URL: http://issues.apache.org/jira/browse/VELTOOLS-62 Project: VelocityTools Issue Type: Improvement Reporter: Claude Brisson Priority: Minor Attachments: ApplicationTool.java, RequestTool.java, ServletToolboxManager.patch, SessionTool.java This is a proposal. Once that a tool implements at least one of the three interfaces RequestTool, SessionTool or ApplicationTool, it means that the actual scope of the tool must correspond to one of the interfaces the tool is implementing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (VELOCITY-458) InternalContextBase defines non-serializable non-transient fields
InternalContextBase defines non-serializable non-transient fields - Key: VELOCITY-458 URL: http://issues.apache.org/jira/browse/VELOCITY-458 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.5 beta1 Reporter: Henning Schmiedehausen Fix For: 1.5 According to Findbugs, org.apache.velocity.context.InternalContextBase defines currentResource and eventCartridge as non-serializable, non-transient in a serializable class. Possible solutions: a) make Resource and EventCartridge serializable (might drag a large number of classes along) b) remove Serializable from InternalContextBase (does the Context get serialized somewhere? Is it needed for e.g. Web Applications?) c) make the fields transient, losing their contents after serialization / de-serialization. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-453) [PATCH] Fix IntrospectionCacheData caching
[ http://issues.apache.org/jira/browse/VELOCITY-453?page=comments#action_12433362 ] Henning Schmiedehausen commented on VELOCITY-453: - Do you have hard numbers for that claim? Are these checks used on a hot path? Just curious. [PATCH] Fix IntrospectionCacheData caching -- Key: VELOCITY-453 URL: http://issues.apache.org/jira/browse/VELOCITY-453 Project: Velocity Issue Type: Bug Components: Source Affects Versions: 1.5 Reporter: Alexey Panchenko Assigned To: Will Glass-Husain Fix For: 1.5 Attachments: ASTMethod_IntrospectionCacheData_cache, ASTMethod_IntrospectionCacheData_cache-v2-retry.patch, ASTMethod_IntrospectionCacheData_cache-v2.patch, IntrospectionCacheDataTest-no-copyright.java, IntrospectionCacheDataTest-no-copyright.java, IntrospectionCacheDataTest-v4.java, IntrospectionCacheDataTest.java The old code used Class[].hashCode() in MethodCacheKey.hashCode() implementation. hashCode() is not overriden for arrays so it returns different value for each array instance. The attached is the correct implementation and a test case to prove the caching actually works. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-453) [PATCH] Fix IntrospectionCacheData caching
[ http://issues.apache.org/jira/browse/VELOCITY-453?page=comments#action_12433363 ] Henning Schmiedehausen commented on VELOCITY-453: - attachments seem to work now. Henri has discovered that you uploaded your files with trailing blanks on the file names and that confused JIRA. Please don't use trailing blanks on file names (I consider this a JIRA bug BTW). Some comments on your patches (I checked the v2-retry.patch because it has the feather): - You seem to use some Windows tool. The diffs have ^M line endings for the diff generated lines. - equals should at least do a if (o == this) return true; check. This short cuts the equals() method in case you test against yourself (set insert e.g.) - I'd love to have unit tests for hashCode() and equals(). - There is a potential NPE with params == null in hashCode() and equals() [PATCH] Fix IntrospectionCacheData caching -- Key: VELOCITY-453 URL: http://issues.apache.org/jira/browse/VELOCITY-453 Project: Velocity Issue Type: Bug Components: Source Affects Versions: 1.5 Reporter: Alexey Panchenko Assigned To: Will Glass-Husain Fix For: 1.5 Attachments: ASTMethod_IntrospectionCacheData_cache, ASTMethod_IntrospectionCacheData_cache-v2-retry.patch, ASTMethod_IntrospectionCacheData_cache-v2.patch, IntrospectionCacheDataTest-no-copyright.java, IntrospectionCacheDataTest-no-copyright.java, IntrospectionCacheDataTest-v4.java, IntrospectionCacheDataTest.java The old code used Class[].hashCode() in MethodCacheKey.hashCode() implementation. hashCode() is not overriden for arrays so it returns different value for each array instance. The attached is the correct implementation and a test case to prove the caching actually works. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-454) clean up escaping to always escape \$ and \#
[
http://issues.apache.org/jira/browse/VELOCITY-454?page=comments#action_12432794
]
Henning Schmiedehausen commented on VELOCITY-454:
-
I agree that the current parser sucks in that respect. As I wrote in the User
Guide, it is mind-boggling that we came up with this, but it is actually tied
to how the parser works. I don't see us to be able to fix this in the 1.5 time
frame, so I postpone this to 1.6.
clean up escaping to always escape \$ and \#
Key: VELOCITY-454
URL: http://issues.apache.org/jira/browse/VELOCITY-454
Project: Velocity
Issue Type: Improvement
Components: Source
Affects Versions: 1.4
Reporter: Bjoern Guenzel
Attachments: testVelocity.vm
I want to use Velocity to generate a template for UJAC, which uses a very
similiar templating language to Velocity. Therefore escaping is a primary
concern.
I am surprised that there seems to be no way to just escape $ and # in
general.
Suppose we have the line \$name
If name is in the context, this will evaluate to $name, otherwise it will
evaluate to \$name
The real problem starts if there is something to escaped like
${something == 3} (this is something that might occur in a UJAC template)
This gives an error in both cases: ${something == 3} and \${something == 3}
both give an error (} expected or something like that).
My guess is that Velocity get's confused when trying to evaluate something
== 3 to see if it is something that is known and should be escaped or
something that is unknown and should not be escaped.
In my opinion the proper behaviour for escaping characters would be to ALWAYS
escape, independent of the context.
Even if the current way of escaping would work in all cases, there would be a
major problem with it. I can't give the velocity template to the Designer,
because only the developer knows all the variables that exist in the context.
So the designer is unable to properly escape all the variables. I think it
would be important to have a way to simply escape everything.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-439) Improve Resource existence detection
[
http://issues.apache.org/jira/browse/VELOCITY-439?page=comments#action_12432804
]
Henning Schmiedehausen commented on VELOCITY-439:
-
I also like this and I actually wrote up some code based on your example
(attached as a patch). However, there are a few more things to check out before
we actually add this:
There is a method in the VelocityEngine, called resourceExists(). It uses
getLoaderNameForResource to determine whether a resource exists or not. It also
leverages the cache to reduce the number of hits to the actual resource
loaders. There is some code in ResourceManagerImpl around line 590, that very
closely resembles the proposed code, so it might probably be replaced with a
call to resourceExists, but there are no unit tests for this and just ripping
the current code out without test is not really a good thing. Especially as we
are discussing to cut an RC now.
I do postpone this for 1.6. Tassos, if you could write some unit tests, that
check the functionality of VelocityEngine.resourceExists() and also the new
resourceExists() method in e.g. the File loader, this would greatly improve the
chances that your code goes in. :-)
Improve Resource existence detection
Key: VELOCITY-439
URL: http://issues.apache.org/jira/browse/VELOCITY-439
Project: Velocity
Issue Type: Improvement
Components: Source
Affects Versions: 1.4
Reporter: Tassos Bassoukos
Priority: Trivial
Attachments: resourceloader.patch
Depending on the ResourceLoader used, testing the existence of a resource is
somewhat expensive, as the resource has to be opened to test for its
existence.
I'm proposing the following changes:
1.
Add a new method to
org.apache.velocity.runtime.resource.loader.ResourceLoader:
public boolean resourceExists(String source) {
InputStream is = null;
try {
is = resourceLoader.getResourceStream(resourceName);
if (is != null) {
return true;
}
} catch (ResourceNotFoundException e) {
} finally {
if (is != null) {
try {
is.close();
} catch (Exception e) {
}
}
}
return false;
}
This method keeps compatibility with all current ResourceLoaders, and can be
overriden by subclasses.
2. org.apache.velocity.runtime.resource.ResourceManagerImpl
Modify the String getLoaderNameForResource(String resourceName) method to use
the new ResourceLoader.resourceExists(String) method.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-439) Improve Resource existence detection
[ http://issues.apache.org/jira/browse/VELOCITY-439?page=all ]
Henning Schmiedehausen updated VELOCITY-439:
Attachment: resourceloader.patch
This is a patch based on the code suggested by Tassos.
Improve Resource existence detection
Key: VELOCITY-439
URL: http://issues.apache.org/jira/browse/VELOCITY-439
Project: Velocity
Issue Type: Improvement
Components: Source
Affects Versions: 1.4
Reporter: Tassos Bassoukos
Priority: Trivial
Attachments: resourceloader.patch
Depending on the ResourceLoader used, testing the existence of a resource is
somewhat expensive, as the resource has to be opened to test for its
existence.
I'm proposing the following changes:
1.
Add a new method to
org.apache.velocity.runtime.resource.loader.ResourceLoader:
public boolean resourceExists(String source) {
InputStream is = null;
try {
is = resourceLoader.getResourceStream(resourceName);
if (is != null) {
return true;
}
} catch (ResourceNotFoundException e) {
} finally {
if (is != null) {
try {
is.close();
} catch (Exception e) {
}
}
}
return false;
}
This method keeps compatibility with all current ResourceLoaders, and can be
overriden by subclasses.
2. org.apache.velocity.runtime.resource.ResourceManagerImpl
Modify the String getLoaderNameForResource(String resourceName) method to use
the new ResourceLoader.resourceExists(String) method.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-439) Improve Resource existence detection
[ http://issues.apache.org/jira/browse/VELOCITY-439?page=all ]
Henning Schmiedehausen updated VELOCITY-439:
Fix Version/s: 1.6
Affects Version/s: 1.5
Improve Resource existence detection
Key: VELOCITY-439
URL: http://issues.apache.org/jira/browse/VELOCITY-439
Project: Velocity
Issue Type: Improvement
Components: Source
Affects Versions: 1.4, 1.5
Reporter: Tassos Bassoukos
Priority: Trivial
Fix For: 1.6
Attachments: resourceloader.patch
Depending on the ResourceLoader used, testing the existence of a resource is
somewhat expensive, as the resource has to be opened to test for its
existence.
I'm proposing the following changes:
1.
Add a new method to
org.apache.velocity.runtime.resource.loader.ResourceLoader:
public boolean resourceExists(String source) {
InputStream is = null;
try {
is = resourceLoader.getResourceStream(resourceName);
if (is != null) {
return true;
}
} catch (ResourceNotFoundException e) {
} finally {
if (is != null) {
try {
is.close();
} catch (Exception e) {
}
}
}
return false;
}
This method keeps compatibility with all current ResourceLoaders, and can be
overriden by subclasses.
2. org.apache.velocity.runtime.resource.ResourceManagerImpl
Modify the String getLoaderNameForResource(String resourceName) method to use
the new ResourceLoader.resourceExists(String) method.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-179) prevent execution of methods on Class, ClassLoader and related classes
[ http://issues.apache.org/jira/browse/VELOCITY-179?page=comments#action_12432806 ] Henning Schmiedehausen commented on VELOCITY-179: - This case is now unchanged for almost a year. Will, do you think that this is something that we can provide as addon for 1.6? I'll postpone it to 1.6 anyway but the question is, can this go into contrib now or does it still need work? prevent execution of methods on Class, ClassLoader and related classes -- Key: VELOCITY-179 URL: http://issues.apache.org/jira/browse/VELOCITY-179 Project: Velocity Issue Type: Improvement Components: Source Affects Versions: 1.4 Environment: Operating System: All Platform: All Reporter: Will Glass-Husain Priority: Minor Fix For: 1.6 Attachments: IntrospectorTestCase4.java, patch1.txt, patch2.txt, patch2b.txt, testcases.xml.patch Template designers currently have the capability to acquire a ClassLoader, instantiate an arbitrary class, and call an arbitrary method. (Example: [1], although more compact examples exist). This is a drastic break with the MVC model, as template designers can execute any arbitary code. It gets worse if you have untrusted template designers who might call methods that erase files, execute arbitrary SQL code, or shut down the VM. This has been discussed on the dev list [2]. This patch prevents any method from being called on objects of a class that has reflection, classloader, or runtime capabilities. (List at the end of the report [4]). It's configurable with a property, but the default is ON, as security restrictions, IMHO, should be strict by default. An alternate solution to this issue would be to prohibit the ClassLoader through the Java Security Manager, as proposed here [4]. I believe this solution to be too difficult for the typical developer. It's complex, and requires knowledge of the Velocity source code. Essentially, you have to split the files that execute the methods on the Java classes into a separate JAR file, then designate that jar file as not have permission to call getClassLoader. This requires that you (A) know what those Velocity classes are (B) understand how to work with the security manager, which is quite complex, and (C) have to modify the Velocity package every time there is a new release. I think it would be better if this is handled natively within Velocity. Finally, this patch does not include docs or test cases. I'd be willing to write both, if a committer is willing to put in the patch. [1] Example of VTL to call arbitray method http://nagoya.apache.org/eyebrowse/ReadMsg?listName=velocity- [EMAIL PROTECTED]msgNo=6114 [2] Related discussion http://nagoya.apache.org/eyebrowse/ReadMsg?listId=102msgNo=5980 http://nagoya.apache.org/eyebrowse/ReadMsg?listName=velocity- [EMAIL PROTECTED]msgNo=10444 [3] Classes affected java.lang.Class java.lang.ClassLoader java.lang.Compiler java.lang.Package java.lang.Process java.lang.InheritableThreadLocal java.lang.Runtime java.lang.RuntimePermission java.lang.SecurityManager java.lang.System java.lang.Thread java.lang.ThreadGroup java.lang.ThreadLocal java.lang.reflect.* [4] Java security manager proposal http://nagoya.apache.org/eyebrowse/ReadMsg?listName=velocity- [EMAIL PROTECTED]msgNo=6012 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
