Many thanks for your help Nathan, regards Malcolm Edgar On Tue, Dec 8, 2009 at 10:18 AM, Nathan Bubna <nbubna@gmail.com> wrote: > Ok, it seems to me that VELOCITY-731 set back performance enough for > people that we should not wait for 1.7 to have an official release > with the new "directive.if.tostring.nullcheck" config switch > available. So, here's a 1.6.3 test build. Please try it out and > report problems ASAP. :) > > http://people.apache.org/~nbubna/velocity/engine/1.6.3/ > > I plan to call for a release vote on Fri (12/11), aiming for a 12/16 > release date. > > (personal note: based on rev 888167 in the 1.6.x branch) > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org > For additional commands, e-mail: dev-help@velocity.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org For additional commands, e-mail: dev-help@velocity.apache.org
[ https://issues.apache.org/jira/browse/VELOCITY-736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787191#action_12787191
]
Nathan Bubna commented on VELOCITY-736:
---------------------------------------
I was unable to duplicate this in a test case, so fixing is rather problematic. I do, however,
intend to move forward on VELOCITY-745 prior to a 1.7 release. That, i hope, would render
this a non-problem.
> Introspection regression from 1.5 to 1.6.2
> ------------------------------------------
>
> Key: VELOCITY-736
> URL: https://issues.apache.org/jira/browse/VELOCITY-736
> Project: Velocity
> Issue Type: Bug
> Components: Engine
> Affects Versions: 1.6.2
> Environment: Sun JDK 1.6.0_16
> Reporter: David Esposito
> Attachments: Velocity736TestCase.java
>
>
> When upgrading from Velcocity 1.5 to 1.6.2, the following snippet of code changed behavior.
> In Velocity 1.5, the output was:
> The file upload exceeded 100
> In Velocity 1.6.2, the output is:
> The file upload exceeded $ex.permittedSize
> There is nothing in the velocity log file to help me identify why it's not resolving
'permittedSize' to the correct bean method.
> Here is a test program to replicate the problem. The context variable in question is
the Commons FileUpload exception class documented here:
> http://commons.apache.org/fileupload/apidocs/org/apache/commons/fileupload/FileUploadBase.SizeLimitExceededException.html
> I am using commons-fileupload-1.2.jar
> import java.io.StringWriter;
> import org.apache.commons.fileupload.FileUploadBase;
> import org.apache.velocity.VelocityContext;
> import org.apache.velocity.app.VelocityEngine;
> import org.apache.velocity.context.Context;
> public class Main {
> public static void main(String[] args) throws Exception{
> VelocityEngine e = new VelocityEngine();
> String testTemplate = "The file upload exceeded $ex.permittedSize";
> StringWriter out = new StringWriter();
> Context ctx = new VelocityContext();
> FileUploadBase.FileSizeLimitExceededException ex = new FileUploadBase.FileSizeLimitExceededException("too
big!", 50, 100);
> ctx.put("ex",ex);
> e.evaluate(ctx, out, "Tester", testTemplate);
> System.out.println(out.toString());
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[ https://issues.apache.org/jira/browse/VELOCITY-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Bubna updated VELOCITY-745:
----------------------------------
If there were once reasons for doing it as it currently is done, i've been unable to think
of them so far. I'll aim to deal with this before any 1.7 release. It ought to simplify
things, and simply trying it is probably the best way to see if there's something i'm overlooking.
> Modify ClassMap.java to use getMethods() rather than get getDeclaredMethods()
> -----------------------------------------------------------------------------
>
> Key: VELOCITY-745
> URL: https://issues.apache.org/jira/browse/VELOCITY-745
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
> Affects Versions: 1.6.2
> Environment: All
> Reporter: Steve O'Hara
> Priority: Minor
>
> The code that recurses up the super classes to find all public methods using getDeclaredMethods()
is now redundant and can be replaced with a single call to getMethods() - this intrinsically
provides all inherited public methods.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Ok, it seems to me that VELOCITY-731 set back performance enough for people that we should not wait for 1.7 to have an official release with the new "directive.if.tostring.nullcheck" config switch available. So, here's a 1.6.3 test build. Please try it out and report problems ASAP. :) http://people.apache.org/~nbubna/velocity/engine/1.6.3/ I plan to call for a release vote on Fri (12/11), aiming for a 12/16 release date. (personal note: based on rev 888167 in the 1.6.x branch) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org For additional commands, e-mail: dev-help@velocity.apache.org
Great, always look forward to new Velocity releases. thanks Malcolm Edgar On Tue, Dec 8, 2009 at 8:28 AM, Nathan Bubna <nbubna@gmail.com> wrote: > Plans? Nope. But now that you mention it, i think i can make the > time to kick that process off. Of course, i may request help, if i've > overestimated my availability. :) > > 2009/12/6 Malcolm Edgar <malcolm.edgar@gmail.com>: >> Hi All, >> >> Are there any plans to release 1.6.3 in the near future? We are >> looking to include VELOCITY-731 in Apache Click. >> >> regards Malcolm Edgar >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org >> For additional commands, e-mail: dev-help@velocity.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org > For additional commands, e-mail: dev-help@velocity.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org For additional commands, e-mail: dev-help@velocity.apache.org
Plans? Nope. But now that you mention it, i think i can make the time to kick that process off. Of course, i may request help, if i've overestimated my availability. :) 2009/12/6 Malcolm Edgar <malcolm.edgar@gmail.com>: > Hi All, > > Are there any plans to release 1.6.3 in the near future? We are > looking to include VELOCITY-731 in Apache Click. > > regards Malcolm Edgar > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org > For additional commands, e-mail: dev-help@velocity.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org For additional commands, e-mail: dev-help@velocity.apache.org
Hi All, Are there any plans to release 1.6.3 in the near future? We are looking to include VELOCITY-731 in Apache Click. regards Malcolm Edgar --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org For additional commands, e-mail: dev-help@velocity.apache.org
[ https://issues.apache.org/jira/browse/VELOCITY-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ravikanth L updated VELOCITY-747:
---------------------------------
Attachment: VelocityInitializationExample.ZIP
> Macros with same name in different templates creates issue when VelocityEngine initialized
with init(Properties) method
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: VELOCITY-747
> URL: https://issues.apache.org/jira/browse/VELOCITY-747
> Project: Velocity
> Issue Type: Bug
> Components: Engine
> Affects Versions: 1.6.x
> Reporter: Ravikanth L
> Attachments: VelocityInitializationExample.ZIP
>
>
> I have two different templates with same macro names performing different functions.
Works fine when VelocityEngine is initialized with init(propsFileName).
> When VelocityEngine is initialized with init(Properties), macro defined in template1
will be used when macro defined in template2 is called.
> Ex:
> one.vm:
> #macro ( myMacro )
> This is from myMacro macro of one.vm
> #end
> #myMacro
> two.vm
> #macro ( myMacro )
> This is from myMacro macro of two.vm
> #end
> #myMacro
> settings in my velocity.properties:
> directive.foreach.counter.initial.value = 1
> file.resource.loader.path = E:/Programs
> file.resource.loader.cache = true
> file.resource.loader.modificationCheckInterval = -1
> velocimacro.permissions.allow.inline.local.scope = true
> directive.set.null.allowed = true
> velocimacro.max.depth = -1
> code in java file:
> VelocityEngine engine = new VelocityEngine();
> Properties props = new Properties();
> props.load( new FileInputStream("velocity.properties") );
> engine.init(props);
> //engine.init("velocity.properties");
> StringWriter writer = new StringWriter();
> VelocityContext ctx = new VelocityContext();
> engine.mergeTemplate("one.vm","UTF-8", ctx,writer);
> System.out.println("Template 1 output:" + writer.toString());
> StringWriter writerTwo = new StringWriter();
> engine.mergeTemplate("two.vm","UTF-8", ctx,writerTwo);
> System.out.println("Template 2 output:" + writerTwo.toString());
> Expected output :
> Template 1 output:This is from Test1 macro of one.vm
> Template 2 output:This is from Test1 macro of two.vm
> Actual output:
> Template 1 output:This is from Test1 macro of one.vm
> Template 2 output:This is from Test1 macro of one.vm
> But with the same code will work properly when initialized with the commented line i.e.
engine.init("velocity.properties");
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[ https://issues.apache.org/jira/browse/VELOCITY-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ravikanth L updated VELOCITY-747:
---------------------------------
Description:
I have two different templates with same macro names performing different functions. Works
fine when VelocityEngine is initialized with init(propsFileName).
When VelocityEngine is initialized with init(Properties), macro defined in template1 will
be used when macro defined in template2 is called.
Ex:
one.vm:
#macro ( myMacro )
This is from myMacro macro of one.vm
#end
#myMacro
two.vm
#macro ( myMacro )
This is from myMacro macro of two.vm
#end
#myMacro
settings in my velocity.properties:
directive.foreach.counter.initial.value = 1
file.resource.loader.path = E:/Programs
file.resource.loader.cache = true
file.resource.loader.modificationCheckInterval = -1
velocimacro.permissions.allow.inline.local.scope = true
directive.set.null.allowed = true
velocimacro.max.depth = -1
code in java file:
VelocityEngine engine = new VelocityEngine();
Properties props = new Properties();
props.load( new FileInputStream("velocity.properties") );
engine.init(props);
//engine.init("velocity.properties");
StringWriter writer = new StringWriter();
VelocityContext ctx = new VelocityContext();
engine.mergeTemplate("one.vm","UTF-8", ctx,writer);
System.out.println("Template 1 output:" + writer.toString());
StringWriter writerTwo = new StringWriter();
engine.mergeTemplate("two.vm","UTF-8", ctx,writerTwo);
System.out.println("Template 2 output:" + writerTwo.toString());
Expected output :
Template 1 output:This is from Test1 macro of one.vm
Template 2 output:This is from Test1 macro of two.vm
Actual output:
Template 1 output:This is from Test1 macro of one.vm
Template 2 output:This is from Test1 macro of one.vm
But with the same code will work properly when initialized with the commented line i.e. engine.init("velocity.properties");
was:
I have two different templates with same macro names performing different functions. Works
fine when VelocityEngine is initialized with init(propsFileName).
When VelocityEngine is initialized with init(Properties), macro defined in template1 will
be used when macro defined in template2 is called.
Ex:
one.vm:
#macro ( myMacro )
This is from myMacro macro of one.vm
#end
#myMacro
two.vm
#macro ( myMacro )
This is from myMacro macro of two.vm
#end
#myMacro
settings in my velocity.properties:
directive.foreach.counter.initial.value = 1
file.resource.loader.path = E:/Programs
file.resource.loader.cache = true
file.resource.loader.modificationCheckInterval = -1
velocimacro.permissions.allow.inline.local.scope = true
directive.set.null.allowed = true
velocimacro.max.depth = -1
code in java file:
VelocityEngine engine = new VelocityEngine();
Properties props = new Properties();
props.load( new FileInputStream("velocity.properties") );
engine.init(props);
//engine.init("velocity.properties");
StringWriter writer = new StringWriter();
VelocityContext ctx = new VelocityContext();
engine.mergeTemplate("one.vm","UTF-8", ctx,writer);
System.out.println("Template 1 output:" + writer.toString());
StringWriter writerTwo = new StringWriter();
engine.mergeTemplate("two.vm","UTF-8", ctx,writerTwo);
System.out.println("Template 2 output:" + writerTwo.toString());
Expected output :
Template 1 output:This is from Test1 macro of one.vm
Template 2 output:This is from Test1 macro of two.vm
Actual output:
Template 1 output:This is from Test1 macro of one.vm
Template 2 output:This is from Test1 macro of one.vm
But with the same code will work properly when initialized with the commented line i.e. engine.init("velocity.properties");
> Macros with same name in different templates creates issue when VelocityEngine initialized
with init(Properties) method
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: VELOCITY-747
> URL: https://issues.apache.org/jira/browse/VELOCITY-747
> Project: Velocity
> Issue Type: Bug
> Components: Engine
> Affects Versions: 1.6.x
> Reporter: Ravikanth L
>
> I have two different templates with same macro names performing different functions.
Works fine when VelocityEngine is initialized with init(propsFileName).
> When VelocityEngine is initialized with init(Properties), macro defined in template1
will be used when macro defined in template2 is called.
> Ex:
> one.vm:
> #macro ( myMacro )
> This is from myMacro macro of one.vm
> #end
> #myMacro
> two.vm
> #macro ( myMacro )
> This is from myMacro macro of two.vm
> #end
> #myMacro
> settings in my velocity.properties:
> directive.foreach.counter.initial.value = 1
> file.resource.loader.path = E:/Programs
> file.resource.loader.cache = true
> file.resource.loader.modificationCheckInterval = -1
> velocimacro.permissions.allow.inline.local.scope = true
> directive.set.null.allowed = true
> velocimacro.max.depth = -1
> code in java file:
> VelocityEngine engine = new VelocityEngine();
> Properties props = new Properties();
> props.load( new FileInputStream("velocity.properties") );
> engine.init(props);
> //engine.init("velocity.properties");
> StringWriter writer = new StringWriter();
> VelocityContext ctx = new VelocityContext();
> engine.mergeTemplate("one.vm","UTF-8", ctx,writer);
> System.out.println("Template 1 output:" + writer.toString());
> StringWriter writerTwo = new StringWriter();
> engine.mergeTemplate("two.vm","UTF-8", ctx,writerTwo);
> System.out.println("Template 2 output:" + writerTwo.toString());
> Expected output :
> Template 1 output:This is from Test1 macro of one.vm
> Template 2 output:This is from Test1 macro of two.vm
> Actual output:
> Template 1 output:This is from Test1 macro of one.vm
> Template 2 output:This is from Test1 macro of one.vm
> But with the same code will work properly when initialized with the commented line i.e.
engine.init("velocity.properties");
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Macros with same name in different templates creates issue when VelocityEngine initialized
with init(Properties) method
-----------------------------------------------------------------------------------------------------------------------
Key: VELOCITY-747
URL: https://issues.apache.org/jira/browse/VELOCITY-747
Project: Velocity
Issue Type: Bug
Components: Engine
Affects Versions: 1.6.x
Reporter: Ravikanth L
I have two different templates with same macro names performing different functions. Works
fine when VelocityEngine is initialized with init(propsFileName).
When VelocityEngine is initialized with init(Properties), macro defined in template1 will
be used when macro defined in template2 is called.
Ex:
one.vm:
#macro ( myMacro )
This is from myMacro macro of one.vm
#end
#myMacro
two.vm
#macro ( myMacro )
This is from myMacro macro of two.vm
#end
#myMacro
settings in my velocity.properties:
directive.foreach.counter.initial.value = 1
file.resource.loader.path = E:/Programs
file.resource.loader.cache = true
file.resource.loader.modificationCheckInterval = -1
velocimacro.permissions.allow.inline.local.scope = true
directive.set.null.allowed = true
velocimacro.max.depth = -1
code in java file:
VelocityEngine engine = new VelocityEngine();
Properties props = new Properties();
props.load( new FileInputStream("velocity.properties") );
engine.init(props);
//engine.init("velocity.properties");
StringWriter writer = new StringWriter();
VelocityContext ctx = new VelocityContext();
engine.mergeTemplate("one.vm","UTF-8", ctx,writer);
System.out.println("Template 1 output:" + writer.toString());
StringWriter writerTwo = new StringWriter();
engine.mergeTemplate("two.vm","UTF-8", ctx,writerTwo);
System.out.println("Template 2 output:" + writerTwo.toString());
Expected output :
Template 1 output:This is from Test1 macro of one.vm
Template 2 output:This is from Test1 macro of two.vm
Actual output:
Template 1 output:This is from Test1 macro of one.vm
Template 2 output:This is from Test1 macro of one.vm
But with the same code will work properly when initialized with the commented line i.e. engine.init("velocity.properties");
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Add Info to MethodExceptionEventHandler.methodException parameter
-----------------------------------------------------------------
Key: VELOCITY-746
URL: https://issues.apache.org/jira/browse/VELOCITY-746
Project: Velocity
Issue Type: Improvement
Components: Engine
Affects Versions: 1.6.2
Reporter: Siri C.
I can't get information where exception is occurs from method exception handler.
The exception handler method contains nothing about line of error.
{code}
MethodExceptionEventHandler.methodException(Class class1, String s, Exception exception)
{code}
Compare with InvalidReferenceEventHandler
{code}
InvalidReferenceEventHandler.invalidGetMethod(Context context, String s, Object obj, String
s1, Info info);
InvalidReferenceEventHandler.invalidSetMethod(Context context, String s, String s1, Info info);
InvalidReferenceEventHandler.invalidMethod(Context context, String s, Object obj, String s1,
Info info);
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Hi!
I am using torque in one of my projects to manage the database. Torque uses
velocity to generate sql-files for the data to be inserted in the database.
For those not familiar with torque it takes (in my case) an xml-file, like
this one:
<dataset name="all">
<Role Id="0" Name="Role_0"/>
<Role Id="1" Name="Role_1"/>
.
<Role Id="n" Name="Role_n"/>
</dataset>
And creates an sql-file like this one:
INSERT INTO role (id,name)
VALUES (1,'Role_1');
INSERT INTO role (id,name)
VALUES (2,'Role_2');
.
INSERT INTO role (id,name)
VALUES (n,'Role_n');
A problem I encountered was that when working with large files (but normal
size for describing databases) was that the program threw an
java.lang.OutOfMemoryError. It turns out that for an input xml-file of 60Kb,
that generates an output file of 100 Kb, the program used 50Mb of memory.
The amount of memory used was proportional to the size of the input file.
For my actual database file, which currently has a size of ca 700kb, the
program needs 415Mb of memory. It seems to me that a great efficiency
improvement could be done here. And even though we have access to a lot of
memory, extending the allowed amount of memory for the program doesn't seem
like a long term solution if the database grows.
We did some tracking using Java Visual VM, which confirms memory usage
constantly increasing while running the program. The velocity engine creates
a lot of instances of org.apache.velocity.runtime.parser.Token that are
never garbage collected. It also creates a lot of strings and chars, but
they, or some of them, are destroyed when running the GC. I'm not very
familiar with the velocity code and I don't know if all the instances of the
token class are needed or if they can be destroyed over time. That said, one
can of course not say that the token class definitely is the reason for the
crash.
I have tried this with velocity 1.5 and 1.6.2. It said in the release notes
that velocity 1.6 contained a major performance improvement but I could not
notice any difference in this case.
Does anyone have any ideas about this?
/Ludwig
[ https://issues.apache.org/jira/browse/VELTOOLS-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781201#action_12781201
]
Frederic Daoud commented on VELTOOLS-123:
-----------------------------------------
Thanks again for adding this. I am using Velocity Tools in Rayures[1].
[1]: http://www.stripesbook.com/rayures.html
> Layout Servlet: Look for alternate layout in request attribute
> --------------------------------------------------------------
>
> Key: VELTOOLS-123
> URL: https://issues.apache.org/jira/browse/VELTOOLS-123
> Project: Velocity Tools
> Issue Type: Improvement
> Components: VelocityView
> Affects Versions: 1.4
> Reporter: Frederic Daoud
> Fix For: 2.0, 2.x
>
>
> The layout servlet looks for an alternate layout in the request parameters, and in the
context (e.g. #set($layout="...").
> It would be very useful if it would also look in the request attributes, e.g. request.getAttribute("layout").
This would allow a servlet filter to specify which layout to use, according to whatever criteria,
by setting the layout as a request attribute.
> This improvement is very easy to add, and it would be oh so useful!
> VelocityLayoutServlet.java (1.4):
> protected Context createContext(HttpServletRequest request,
> HttpServletResponse response)
> {
> Context ctx = super.createContext(request, response);
> // check if an alternate layout has been specified
> // by way of the request parameters
> String layout = request.getParameter(KEY_LAYOUT);
> // also look in the request attributes
> if (layout == null)
> {
> layout = request.getAttribute(KEY_LAYOUT);
> }
> if (layout != null)
> {
> // let the template know what its new layout is
> ctx.put(KEY_LAYOUT, layout);
> }
> return ctx;
> }
> Thanks in advance.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Modify ClassMap.java to use getMethods() rather than get getDeclaredMethods()
-----------------------------------------------------------------------------
Key: VELOCITY-745
URL: https://issues.apache.org/jira/browse/VELOCITY-745
Project: Velocity
Issue Type: Improvement
Components: Engine
Affects Versions: 1.6.2
Environment: All
Reporter: Steve O'Hara
Priority: Minor
The code that recurses up the super classes to find all public methods using getDeclaredMethods()
is now redundant and can be replaced with a single call to getMethods() - this intrinsically
provides all inherited public methods.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
No more VM adding logs
----------------------
Key: VELOCITY-744
URL: https://issues.apache.org/jira/browse/VELOCITY-744
Project: Velocity
Issue Type: Bug
Components: Engine
Affects Versions: 1.6.2
Reporter: Alexandre Garnier
Priority: Minor
org.apache.velocity.runtime.VelocimacroFactory.addVelocimacro(String, String, String[], String)
add a log "added <VMName> : source = <VMBody>"
The new 1.6 method org.apache.velocity.runtime.VelocimacroFactory.addVelocimacro(String, Node,
String[], String) no more log this.
The first one is used by org.apache.velocity.runtime.RuntimeInstance.addVelocimacro(String,
String, String[], String) which is now deprecated for org.apache.velocity.runtime.RuntimeInstance.addVelocimacro(String,
Node, String[], String) which use the new VelocimacroFactory.addVelocimacro
This logs was usefull for debug.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
LoopTool fails to retrieve $loop.index, $loop.first etc for the last element in a collection.
---------------------------------------------------------------------------------------------
Key: VELTOOLS-124
URL: https://issues.apache.org/jira/browse/VELTOOLS-124
Project: Velocity Tools
Issue Type: Bug
Components: GenericTools
Affects Versions: 2.x
Environment: velocity-tools-2.0-beta4 with velocity-1.6.2
Reporter: Sergiy Kovalchuk
Fix For: 2.x
$loop.index, $loop.first and other LoopTool methods (that depend on iterator) return null
for the last element in a collection.
Try to run:
#set( $list = [1..3] )
#foreach($i in $loop.watch($list))
$i - ${loop.index},
#end
The result is:
i[0]=1; i[1]=2; i[${loop.index}]=3;
I tried to investigate it a little, and seems like the problem is inside "cacheNext(boolean
popWhenDone)".
First it checks if (!iterator.hasNext()) and if not then removes this iterator from the stack.
But later in this method it retrieves next element from a collection "this.next = iterator.next();".
Seems like it causes removing iterator too early, when calling ${loop.index} on the last element
the iterator is already removed.
Thanks.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[ https://issues.apache.org/jira/browse/VELTOOLS-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergiy Kovalchuk updated VELTOOLS-124:
--------------------------------------
Description:
$loop.index, $loop.first and other LoopTool methods (that depend on iterator) return null
for the last element in a collection.
Try to run:
#set( $list = [1..3] )
#foreach($i in $loop.watch($list))
i[${loop.index}]=$i;
#end
The result is:
i[0]=1; i[1]=2; i[${loop.index}]=3;
I tried to investigate it a little, and seems like the problem is inside "cacheNext(boolean
popWhenDone)".
First it checks if (!iterator.hasNext()) and if not then removes this iterator from the stack.
But later in this method it retrieves next element from a collection "this.next = iterator.next();".
Seems like it causes removing iterator too early, when calling ${loop.index} on the last element
the iterator is already removed.
Thanks.
was:
$loop.index, $loop.first and other LoopTool methods (that depend on iterator) return null
for the last element in a collection.
Try to run:
#set( $list = [1..3] )
#foreach($i in $loop.watch($list))
$i - ${loop.index},
#end
The result is:
i[0]=1; i[1]=2; i[${loop.index}]=3;
I tried to investigate it a little, and seems like the problem is inside "cacheNext(boolean
popWhenDone)".
First it checks if (!iterator.hasNext()) and if not then removes this iterator from the stack.
But later in this method it retrieves next element from a collection "this.next = iterator.next();".
Seems like it causes removing iterator too early, when calling ${loop.index} on the last element
the iterator is already removed.
Thanks.
> LoopTool fails to retrieve $loop.index, $loop.first etc for the last element in a collection.
> ---------------------------------------------------------------------------------------------
>
> Key: VELTOOLS-124
> URL: https://issues.apache.org/jira/browse/VELTOOLS-124
> Project: Velocity Tools
> Issue Type: Bug
> Components: GenericTools
> Affects Versions: 2.x
> Environment: velocity-tools-2.0-beta4 with velocity-1.6.2
> Reporter: Sergiy Kovalchuk
> Fix For: 2.x
>
>
> $loop.index, $loop.first and other LoopTool methods (that depend on iterator) return
null for the last element in a collection.
> Try to run:
> #set( $list = [1..3] )
> #foreach($i in $loop.watch($list))
> i[${loop.index}]=$i;
> #end
> The result is:
> i[0]=1; i[1]=2; i[${loop.index}]=3;
> I tried to investigate it a little, and seems like the problem is inside "cacheNext(boolean
popWhenDone)".
> First it checks if (!iterator.hasNext()) and if not then removes this iterator from the
stack. But later in this method it retrieves next element from a collection "this.next = iterator.next();".
Seems like it causes removing iterator too early, when calling ${loop.index} on the last element
the iterator is already removed.
> Thanks.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
On Sun, Nov 15, 2009 at 7:26 AM, Christopher Schultz <chris@christopherschultz.net> wrote: > Nathan, > > Resurrecting this because I'm ready to commit. > > On 10/29/2009 3:04 PM, Nathan Bubna wrote: >> On Thu, Oct 29, 2009 at 8:06 AM, Christopher Schultz >> <chris@christopherschultz.net> wrote: >>> Nathan, >>> >>> On 10/29/2009 11:02 AM, Christopher Schultz wrote: >>>> I like re-coding into SimpleDataFormat better. >>> >>> D'oh: that's not possible because DateFormat doesn't expose the pattern >>> it's using, so I'll have to return something unrelated. Hmm. I'm not a >>> big fan of NULL but it's also not exactly consistent with the API if an >>> error message is returned. >>> >>> Any ideas other than NULL? >> >> Not really, because a) it's unlikely to ever occur in practice and b) >> that's the traditional VelocityTools response to bad inputs. If you >> call $date.toLocalizedPattern($invalidInput) then that's little better >> than $date.noSuchMethod($validinput). Either way, part of the >> reference is invalid, and we want to render it as an invalid >> reference. Returning null accomplishes that. > > While I agree that VelocityTools' traditional response to bad input is > null, the problem here isn't the user's bad input: instead, it's our > reliance on an unpublished but highly likely coincidence that DateFormat > always hands-out SimpleDateFormat objects. ah, but i didn't mean to imply that it is *just* the standard response to bad input. it's the convention for all errors when attempting to execute a tool method. it tells the user there's a problem in a consistent manner, responds to silent notation, is easily caught by an event handler, and properly blows up when VelocityEngine is running in the new strict mode. returning an error string would be inconsistent and fail to draw the attention of other facilities for error checking/handling that Velocity provides. > For patterns other than "simple_date" and stuff like that, I could > simply construct a new SimpleDateFormat object and use that, but then > the behavior of toLocalizedPattern would differ from the other methods > -- that is, "short_date" would work, except when it doesn't :( yeah, but i think that's acceptable. do the best we can, return null when nothing can be done. > Thanks, > -chris > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org For additional commands, e-mail: dev-help@velocity.apache.org
Nathan, Resurrecting this because I'm ready to commit. On 10/29/2009 3:04 PM, Nathan Bubna wrote: > On Thu, Oct 29, 2009 at 8:06 AM, Christopher Schultz > <chris@christopherschultz.net> wrote: >> Nathan, >> >> On 10/29/2009 11:02 AM, Christopher Schultz wrote: >>> I like re-coding into SimpleDataFormat better. >> >> D'oh: that's not possible because DateFormat doesn't expose the pattern >> it's using, so I'll have to return something unrelated. Hmm. I'm not a >> big fan of NULL but it's also not exactly consistent with the API if an >> error message is returned. >> >> Any ideas other than NULL? > > Not really, because a) it's unlikely to ever occur in practice and b) > that's the traditional VelocityTools response to bad inputs. If you > call $date.toLocalizedPattern($invalidInput) then that's little better > than $date.noSuchMethod($validinput). Either way, part of the > reference is invalid, and we want to render it as an invalid > reference. Returning null accomplishes that. While I agree that VelocityTools' traditional response to bad input is null, the problem here isn't the user's bad input: instead, it's our reliance on an unpublished but highly likely coincidence that DateFormat always hands-out SimpleDateFormat objects. For patterns other than "simple_date" and stuff like that, I could simply construct a new SimpleDateFormat object and use that, but then the behavior of toLocalizedPattern would differ from the other methods -- that is, "short_date" would work, except when it doesn't :( Thanks, -chris
[ https://issues.apache.org/jira/browse/VELOCITY-657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Parmeley updated VELOCITY-657:
--------------------------------------
Comment: was deleted
(was: I am using velocity 1.6.2 and this is still occuring. Using $velocityHasNext does not
work in nested loops.
For example:
I have: #foreach(${column} in ${columns})${column.columnName}#if(${velocityHasNext}),#end#end
However, if I have two columns named "foo" and "bar" this is resulting in "foobar". If I change
the condition in the if statment to something cheesy like (3 > 2) then the expected results
of "foo,bar" is generated.
So the $velocityHasNext is still not working in velocity 1.6.2.
I have this property in my velocity.properties:
directive.foreach.iterator.name = velocityHasNext
)
> $velocityHasNext not working properly (returns true even if iterator does not have next
value)
> ----------------------------------------------------------------------------------------------
>
> Key: VELOCITY-657
> URL: https://issues.apache.org/jira/browse/VELOCITY-657
> Project: Velocity
> Issue Type: Bug
> Components: Engine
> Affects Versions: 1.6
> Reporter: Dominik Marks
> Priority: Minor
> Fix For: 1.6.2, 1.7
>
> Attachments: velocity-657-testcase.patch
>
>
> Using the new "velocityHasNext" feature in loops does not work as expected.
> When using the following excerpt:
> #foreach ($value in $element.values)
> $value
> #if( $velocityHasNext )
> SEPARATOR
> #end
> #end
> and having $element.values as e.g. "test1", "test2", "test3"
> I get
> test1 SEPARATOR test2 SEPARATOR test3 SEPARATOR
> but I would expect
> test1 SEPARATOR test2 SEPARATOR test3
> When looking into the source code, I see the following in org.apache.velocity.runtime.directive.Foreach.render():
> while (!maxNbrLoopsExceeded && i.hasNext())
> {
> // TODO: JDK 1.5+ -> Integer.valueOf()
> put(context, counterName , new Integer(counter));
> put(context, hasNextName, Boolean.valueOf(i.hasNext()));
> Object value = i.next();
> put(context, elementKey, value);
> ....
> }
> Isn't this the wrong order of instructions?
> I would expect:
> Object value = i.next();
> put(context, hasNextName, Boolean.valueOf(i.hasNext()));
> So that the $velocityHasNext variable will be filled with the "hasNext" of the follow-up
iteration and not with the "hasNext" of the current iteration (which will always be true,
otherwise the loop has finished before).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[ https://issues.apache.org/jira/browse/VELOCITY-657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12777514#action_12777514
]
Michael Parmeley commented on VELOCITY-657:
-------------------------------------------
I am using velocity 1.6.2 and this is still occuring. Using $velocityHasNext does not work
in nested loops.
For example:
I have: #foreach(${column} in ${columns})${column.columnName}#if(${velocityHasNext}),#end#end
However, if I have two columns named "foo" and "bar" this is resulting in "foobar". If I change
the condition in the if statment to something cheesy like (3 > 2) then the expected results
of "foo,bar" is generated.
So the $velocityHasNext is still not working in velocity 1.6.2.
I have this property in my velocity.properties:
directive.foreach.iterator.name = velocityHasNext
> $velocityHasNext not working properly (returns true even if iterator does not have next
value)
> ----------------------------------------------------------------------------------------------
>
> Key: VELOCITY-657
> URL: https://issues.apache.org/jira/browse/VELOCITY-657
> Project: Velocity
> Issue Type: Bug
> Components: Engine
> Affects Versions: 1.6
> Reporter: Dominik Marks
> Priority: Minor
> Fix For: 1.6.2, 1.7
>
> Attachments: velocity-657-testcase.patch
>
>
> Using the new "velocityHasNext" feature in loops does not work as expected.
> When using the following excerpt:
> #foreach ($value in $element.values)
> $value
> #if( $velocityHasNext )
> SEPARATOR
> #end
> #end
> and having $element.values as e.g. "test1", "test2", "test3"
> I get
> test1 SEPARATOR test2 SEPARATOR test3 SEPARATOR
> but I would expect
> test1 SEPARATOR test2 SEPARATOR test3
> When looking into the source code, I see the following in org.apache.velocity.runtime.directive.Foreach.render():
> while (!maxNbrLoopsExceeded && i.hasNext())
> {
> // TODO: JDK 1.5+ -> Integer.valueOf()
> put(context, counterName , new Integer(counter));
> put(context, hasNextName, Boolean.valueOf(i.hasNext()));
> Object value = i.next();
> put(context, elementKey, value);
> ....
> }
> Isn't this the wrong order of instructions?
> I would expect:
> Object value = i.next();
> put(context, hasNextName, Boolean.valueOf(i.hasNext()));
> So that the $velocityHasNext variable will be filled with the "hasNext" of the follow-up
iteration and not with the "hasNext" of the current iteration (which will always be true,
otherwise the loop has finished before).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Update libraries version (FOP)
------------------------------
Key: DBF-11
URL: https://issues.apache.org/jira/browse/DBF-11
Project: DocBook Framework
Issue Type: Bug
Reporter: Alessandro Ruzzon
Can you create a binary version that could work with version 0.95 of Apache FOP? There is
a bug when you try to insert a rotated image (in which height is more than width), so I need
to solve it. It seems it's a bug of FOP, and actually the version supported is 0.20.5.
Thanks all
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Velocity Wiki" for change notification. The "BoardReport-November2009" page has been changed by HenningSchmiedehausen. http://wiki.apache.org/velocity/BoardReport-November2009 -------------------------------------------------- New page: == November 2009 Board Report == === Status === Velocity still continues it quiet, steady flow. Activity picked up a little in October with some messages on the dev list. The user lists continues to be very self-helping with questions getting answered by members of the user and dev communities. Velocity changed its chair from Will Glass-Husain to Henning Schmiedehausen. The Velocity project currently has no board-level issues at this time. There were new committers or PMC members voted in since the last board meeting. No beta or final releases were made since the last board report. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org For additional commands, e-mail: dev-help@velocity.apache.org
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Velocity Wiki" for change notification. The "ASFBoardReports" page has been changed by HenningSchmiedehausen. http://wiki.apache.org/velocity/ASFBoardReports?action=diff&rev1=1&rev2=2 -------------------------------------------------- * [[BoardReport-February2009]] * [[BoardReport-May2009]] * [[BoardReport-October2009]] + * [[BoardReport-November2009]] --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org For additional commands, e-mail: dev-help@velocity.apache.org
[ https://issues.apache.org/jira/browse/VELOCITY-743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Bubna updated VELOCITY-743:
----------------------------------
Component/s: Engine
Priority: Minor (was: Major)
Issue Type: Improvement (was: Bug)
Sorry, this is intentional. The colon is not a supported character in references. It will
certainly never be considered a valid reference character for standard $reference notation.
I'll leave this open as an RFE though, since i suppose it would be possible to increase the
scope of legal reference characters in formal ${reference} notation.
For now, your best bet is probably to add the context to itself:
context.put("ctx", context);
and then do $ctx.get("EPL_JOBTITLE:varB_EPL") to give yourself more character freedom.
> The character ":" if present within the curly braces of a variable throws exception
> ------------------------------------------------------------------------------------
>
> Key: VELOCITY-743
> URL: https://issues.apache.org/jira/browse/VELOCITY-743
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
> Affects Versions: 1.6.2
> Environment: JRE 6, Apache tomcat 6.0.18
> Reporter: Vinay
> Priority: Minor
>
> I am trying to write a template that is customized like this
> -----------------------------------------------------------------------------
> <hi>
> <variable1> ${EPL_JOBTITLE:varB_EPL} </variable1>
> <variable2>${SPL_EMPLOYEENUMBER:varA_SPL} </variable2>
> </hi>
> -----------------------------------------------------------------------------
> Now the ${EPL_JOBTITLE:varB_EPL} is custom parsed and replaced with the appropriate values
in the context.
> However, as soon as the Template is loaded by the velocity engine I get a
> Template Parse Exception :
> Encountered ":varB_EPL}\r\n\r\n\r\n" at MY Script - 1\Test this.vm[line 1, column 15]
> Was expecting one of:
> "}" ...
> <DOT> ...
> How is the ":" character an invalid one within braces ? Shouldn't it be supported within
a variable name?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
The character ":" if present within the curly braces of a variable throws exception
------------------------------------------------------------------------------------
Key: VELOCITY-743
URL: https://issues.apache.org/jira/browse/VELOCITY-743
Project: Velocity
Issue Type: Bug
Affects Versions: 1.6.2
Environment: JRE 6, Apache tomcat 6.0.18
Reporter: Vinay
I am trying to write a template that is customized like this
-----------------------------------------------------------------------------
<hi>
<variable1> ${EPL_JOBTITLE:varB_EPL} </variable1>
<variable2>${SPL_EMPLOYEENUMBER:varA_SPL} </variable2>
</hi>
-----------------------------------------------------------------------------
Now the ${EPL_JOBTITLE:varB_EPL} is custom parsed and replaced with the appropriate values
in the context.
However, as soon as the Template is loaded by the velocity engine I get a
Template Parse Exception :
Encountered ":varB_EPL}\r\n\r\n\r\n" at MY Script - 1\Test this.vm[line 1, column 15]
Was expecting one of:
"}" ...
<DOT> ...
How is the ":" character an invalid one within braces ? Shouldn't it be supported within a
variable name?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Easily Add/Remove/Replace Directives Without Cracking Open Velocity Jar
-----------------------------------------------------------------------
Key: VELOCITY-742
URL: https://issues.apache.org/jira/browse/VELOCITY-742
Project: Velocity
Issue Type: New Feature
Components: Engine
Affects Versions: 1.6.2
Reporter: Tim White
Priority: Minor
There are two use cases that I have for this issue:
1) We need to turn off #include in order to parse .html files that include SSI directives:
<!--#include virtual=""--> (we always use #parse in our world, so no loss for #include
going away)
2) We need to supply our own version of #parse that contains the development hooks that I
described in a different issue.
Right now, the only crisp way to do is is to crack open the velocity .jar and make these changes,
which is very risky, because future developers may upgrade to new versions of Velocity and
not realize that there are customizations and/or not understand how to remake them....not
to mention in a shared-classpath environment, we don't always have control over which copy
of the Velocity .jar we're using.
Ideally, there would be config options like this:
directive_remove ("#parse", "#include")
directive_add ("#parse", "com.qwest.velocity.directives.Parse")
Thanks!
Tim
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[ https://issues.apache.org/jira/browse/VELOCITY-736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12773486#action_12773486
]
David Esposito commented on VELOCITY-736:
-----------------------------------------
Hi Guys,
I was hoping for a resolution one way or the other on this. If it's not going to be "fixed",
I will need to work around it ... If it is, when could I expect the fix to be included?
Nathan, addressing the detail of "public methods declared in public classes" ... Why isn't
it as simple as "public methods"? .. Why does the protection of the class have any relevance?
From an end-user perspective, I would expect that I can invoke any 'getter' that I can from
my Java code regardless of the inheritance scheme of the class ... In this case, I have the
Javadocs and source code of the Commons-Fileupload classes to understand what the developers
intended, but if it's a closed source library I'm using, I would have to decompile the binaries
to figure out why my methods aren't being invoke from VTL.
-Dave
> Introspection regression from 1.5 to 1.6.2
> ------------------------------------------
>
> Key: VELOCITY-736
> URL: https://issues.apache.org/jira/browse/VELOCITY-736
> Project: Velocity
> Issue Type: Bug
> Components: Engine
> Affects Versions: 1.6.2
> Environment: Sun JDK 1.6.0_16
> Reporter: David Esposito
> Attachments: Velocity736TestCase.java
>
>
> When upgrading from Velcocity 1.5 to 1.6.2, the following snippet of code changed behavior.
> In Velocity 1.5, the output was:
> The file upload exceeded 100
> In Velocity 1.6.2, the output is:
> The file upload exceeded $ex.permittedSize
> There is nothing in the velocity log file to help me identify why it's not resolving
'permittedSize' to the correct bean method.
> Here is a test program to replicate the problem. The context variable in question is
the Commons FileUpload exception class documented here:
> http://commons.apache.org/fileupload/apidocs/org/apache/commons/fileupload/FileUploadBase.SizeLimitExceededException.html
> I am using commons-fileupload-1.2.jar
> import java.io.StringWriter;
> import org.apache.commons.fileupload.FileUploadBase;
> import org.apache.velocity.VelocityContext;
> import org.apache.velocity.app.VelocityEngine;
> import org.apache.velocity.context.Context;
> public class Main {
> public static void main(String[] args) throws Exception{
> VelocityEngine e = new VelocityEngine();
> String testTemplate = "The file upload exceeded $ex.permittedSize";
> StringWriter out = new StringWriter();
> Context ctx = new VelocityContext();
> FileUploadBase.FileSizeLimitExceededException ex = new FileUploadBase.FileSizeLimitExceededException("too
big!", 50, 100);
> ctx.put("ex",ex);
> e.evaluate(ctx, out, "Tester", testTemplate);
> System.out.println(out.toString());
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[ https://issues.apache.org/jira/browse/VELOCITY-715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12773349#action_12773349
]
Byron Foster commented on VELOCITY-715:
---------------------------------------
The WeakHashMap will correctly drop the value when the key is gargage collected, but as your
link points out the WeakHashMap is not a cache. JVM behavior will differ, but in general
key/value pairs will be dropped for every garbage sweep, which mean allot of rebuilding of
templates. Also, as you point out, this is only an issue with many 10s of thousands of file
names... I can't imagine a use case where this is a practical concern.
I don't see a bug here..
> Leaked object in FileResourceLoader#templatePaths
> -------------------------------------------------
>
> Key: VELOCITY-715
> URL: https://issues.apache.org/jira/browse/VELOCITY-715
> Project: Velocity
> Issue Type: Bug
> Components: Engine
> Reporter: Atsushi Isobe
> Priority: Minor
> Attachments: FileResourceLoader.patch, FileResourceLoaderLeakedObjectTest.java
>
>
> org.apache.velocity.runtime.resource.loader.FileResourceLoader#templatePaths has stored
templatename and real file path permanently.So if VelocityEngine#getTemplate(String) has called
by too many files, #templatePaths have been enlarged.
> Bellow my test results.
> ----------------------------------------
> 2009-05-08 19:16:54,571 INFO [FileResourceLoaderLeakedObjectTest] count: 000,000 total:
002,696,488
> 2009-05-08 19:19:23,381 INFO [FileResourceLoaderLeakedObjectTest] count: 065,536 total:
014,689,896
> 2009-05-08 19:22:03,782 INFO [FileResourceLoaderLeakedObjectTest] count: 131,072 total:
025,374,944
> 2009-05-08 19:24:14,756 INFO [FileResourceLoaderLeakedObjectTest] count: 196,608 total:
036,282,696
> 2009-05-08 19:26:37,864 INFO [FileResourceLoaderLeakedObjectTest] count: 262,144 total:
046,776,168
> 2009-05-08 19:28:55,090 INFO [FileResourceLoaderLeakedObjectTest] count: 327,680 total:
057,119,560
> 2009-05-08 19:31:37,524 INFO [FileResourceLoaderLeakedObjectTest] count: 393,216 total:
069,858,824
> 2009-05-08 19:34:10,425 INFO [FileResourceLoaderLeakedObjectTest] count: 458,752 total:
080,019,920
> 2009-05-08 19:36:52,788 INFO [FileResourceLoaderLeakedObjectTest] count: 524,288 total:
090,093,168
> 2009-05-08 19:39:13,662 INFO [FileResourceLoaderLeakedObjectTest] count: 589,824 total:
097,385,776
> 2009-05-08 19:41:54,621 INFO [FileResourceLoaderLeakedObjectTest] count: 655,360 total:
107,387,792
> 2009-05-08 19:44:31,601 INFO [FileResourceLoaderLeakedObjectTest] count: 720,896 total:
117,451,912
> 2009-05-08 19:47:08,890 INFO [FileResourceLoaderLeakedObjectTest] count: 786,432 total:
137,151,792
> 2009-05-08 19:49:44,924 INFO [FileResourceLoaderLeakedObjectTest] count: 851,968 total:
147,277,856
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[ https://issues.apache.org/jira/browse/VELOCITY-740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Glass-Husain resolved VELOCITY-740.
----------------------------------------
Resolution: Fixed
Done. Now passes $!foo instead of $foo to InvalidReferenceHandler upon hitting an invalid
silent reference.
> InvalidReferenceEventHandler should get indication that a reference is quiet
> ----------------------------------------------------------------------------
>
> Key: VELOCITY-740
> URL: https://issues.apache.org/jira/browse/VELOCITY-740
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
> Affects Versions: 1.6.2
> Reporter: Will Glass-Husain
> Fix For: 1.7
>
>
> Right now the InvalidReferenceEventHandler is called for bad references whether they
are quiet or not. The reference is passed as "$abc" even if the template actually contains
"$!abc".
> Typically, you'd want to ignore invalid references. We should fix this to pass "$!abc"
instead of $abc.
> It's not a hard fix -- anyone mind if I change this? Technically, it's a break in backwards
compatibility but a pretty minor one. It will still get called but with an indication the
reference is quiet.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[ https://issues.apache.org/jira/browse/VELOCITY-586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Glass-Husain resolved VELOCITY-586.
----------------------------------------
Resolution: Won't Fix
Thanks for sharing this.
Going to resolve this issue - I think we don't want to mix HTTP and #parse. But it's a good
custom directive if you need it.
An alternate way of doing this is to use IncludeEventHandler to redirect to a "wrapper" page
which includes this kind of info.
> Add debugging hooks to #parse
> -----------------------------
>
> Key: VELOCITY-586
> URL: https://issues.apache.org/jira/browse/VELOCITY-586
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
> Affects Versions: 1.5
> Reporter: Tim White
> Priority: Minor
>
> When you have a page that is made up of a complex web of templates and #parsed includes,
it is critical to be able to quickly see what parts of the page are really in what file.
> To do this, I've hacked #parse to inject debugging information into the template when
a 'debug mode' is engaged. This debug mode is engaged via a URL parameter.
> I also inject this information in the VVS right before the main template is rendered.
In this way, you can create a debug overlay on top of the page in your browser that shows
you where each piece of text is coming from.
> I think this probably could better be implemented using hooks, so that a user could trigger
when the debug information was being injected.
> I also suggest that the name of the current template, it's resource loader, etc. be passed
into the context, so it can be used to see what template is where and what loader it came
from.
> Finally, if there could be a way to conditionally prepend or append a template to each
merged or #parse template, that could also help.
> Thanks!!!
> package org.apache.velocity.runtime.directive;
> /*
> * Licensed to the Apache Software Foundation (ASF) under one
> * or more contributor license agreements. See the NOTICE file
> * distributed with this work for additional information
> * regarding copyright ownership. The ASF licenses this file
> * to you 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.
> */
> import java.io.IOException;
> import java.io.Writer;
> import javax.servlet.http.HttpSession;
> import org.apache.velocity.Template;
> import org.apache.velocity.app.event.EventHandlerUtil;
> import org.apache.velocity.context.InternalContextAdapter;
> import org.apache.velocity.exception.MethodInvocationException;
> import org.apache.velocity.exception.ParseErrorException;
> import org.apache.velocity.exception.ResourceNotFoundException;
> import org.apache.velocity.runtime.RuntimeConstants;
> import org.apache.velocity.runtime.parser.node.Node;
> import org.apache.velocity.runtime.parser.node.SimpleNode;
> import com.qwest.velocity.VelocityConstants;
> /**
> * Pluggable directive that handles the <code>#parse()</code> statement in
VTL.
> *
> * <pre>
> * Notes:
> * -----
> * 1) The parsed source material can only come from somewhere in
> * the TemplateRoot tree for security reasons. There is no way
> * around this. If you want to include content from elsewhere on
> * your disk, use a link from somwhere under Template Root to that
> * content.
> *
> * 2) There is a limited parse depth. It is set as a property
> * "parse_directive.maxdepth = 10" for example. There is a 20
iteration
> * safety in the event that the parameter isn't set.
> * </pre>
> *
> * @author <a href="mailto:geirm@optonline.net">Geir Magnusson Jr.</a>
> * @author <a href="mailto:jvanzyl@apache.org">Jason van Zyl</a>
> * @author <a href="mailto:Christoph.Reck@dlr.de">Christoph Reck</a>
> * @version $Id: Parse.java 463298 2006-10-12 16:10:32Z henning $
> */
> public class Parse extends InputBase {
> /**
> * Return name of this directive.
> *
> * @return The name of this directive.
> */
> public String getName() {
> return "parse";
> }
> /**
> * Return type of this directive.
> *
> * @return The type of this directive.
> */
> public int getType() {
> return LINE;
> }
> /**
> * iterates through the argument list and renders every argument that is appropriate.
Any non appropriate arguments are logged, but render() continues.
> *
> * @param context
> * @param writer
> * @param node
> * @return True if the directive rendered successfully.
> * @throws IOException
> * @throws ResourceNotFoundException
> * @throws ParseErrorException
> * @throws MethodInvocationException
> */
> public boolean render(InternalContextAdapter context, Writer writer, Node node) throws
IOException, ResourceNotFoundException, ParseErrorException, MethodInvocationException {
> /*
> * if rendering is no longer allowed (after a stop), we can safely skip execution of
all the parse directives.
> */
> if (!context.getAllowRendering()) {
> return true;
> }
> /*
> * did we get an argument?
> */
> if (node.jjtGetChild(0) == null) {
> rsvc.getLog().error("Portal #parse() null argument");
> return false;
> }
> /*
> * does it have a value? If you have a null reference, then no.
> */
> Object value = node.jjtGetChild(0).value(context);
> if (value == null) {
> rsvc.getLog().error("Portal #parse() null argument");
> return false;
> }
> /*
> * get the path
> */
> String sourcearg = value.toString();
> /*
> * check to see if the argument will be changed by the event cartridge
> */
> String arg = EventHandlerUtil.includeEvent(rsvc, context, sourcearg, context.getCurrentTemplateName(),
getName());
> /*
> * a null return value from the event cartridge indicates we should not input a resource.
> */
> boolean blockinput = false;
> if (arg == null)
> blockinput = true;
> /*
> * see if we have exceeded the configured depth. If it isn't configured, put a stop
at 20 just in case.
> */
> Object[] templateStack = context.getTemplateNameStack();
> if (templateStack.length >= rsvc.getInt(RuntimeConstants.PARSE_DIRECTIVE_MAXDEPTH,
20)) {
> StringBuffer path = new StringBuffer();
> for (int i = 0; i < templateStack.length; ++i) {
> path.append(" > " + templateStack[i]);
> }
> rsvc.getLog().error("Portal #parse: Max recursion depth reached (" + templateStack.length
+ ')' + " File stack:" + path);
> return false;
> }
> /*
> * now use the Runtime resource loader to get the template
> */
> Template t = null;
> try {
> if (!blockinput)
> t = rsvc.getTemplate(arg, getInputEncoding(context));
> } catch (ResourceNotFoundException rnfe) {
> /*
> * the arg wasn't found. Note it and throw
> */
> rsvc.getLog().error("Portal #parse(): cannot find template '" + arg + "', called from
template " + context.getCurrentTemplateName() + " at (" + getLine() + ", " + getColumn() +
")");
> throw rnfe;
> } catch (ParseErrorException pee) {
> /*
> * the arg was found, but didn't parse - syntax error note it and throw
> */
> rsvc.getLog().error(
> "Portal #parse(): syntax error in #parse()-ed template '" + arg + "', called from
template " + context.getCurrentTemplateName() + " at (" + getLine() + ", " + getColumn() +
")");
> throw pee;
> }
> /**
> * pass through application level runtime exceptions
> */
> catch (RuntimeException e) {
> throw e;
> } catch (Exception e) {
> rsvc.getLog().error("Portal #parse() : arg = " + arg + '.', e);
> return false;
> }
> /*
> * and render it
> */
> try {
> if (rsvc.getLog().isDebugEnabled()) {
> rsvc.getLog().debug("*** Portal #Parse Template Path: " + t.getName());
> }
>
> /* Save the name of the main template before resetting templateName for this include
*/
> String mainTemplateName = "";
> if (context.get(VelocityConstants.TEMPLATE_NAME_VAR) != null) {
> mainTemplateName = context.get(VelocityConstants.TEMPLATE_NAME_VAR).toString();
> }
> /* Set the name of the current template in the context for general use */
> context.put(VelocityConstants.TEMPLATE_NAME_VAR, t.getName());
> /* Check various places to see if debug mode is enabled */
> boolean debugMode = false;
> /* This supports PortalVelocityViewServlet */
> if (context.get(VelocityConstants.DEBUG_ATTRIBUTE) != null) {
> debugMode = true;
> }
> /* This supports qcms.getMessage() */
> if (context.get("session") != null) {
> HttpSession session = (HttpSession) context.get("session");
> if (session.getAttribute("qCmsDebugger") != null) {
> debugMode = true;
> }
> }
> /* Print Debug start output to browser if debug mode is on */
> if (debugMode) {
> Template startTemplate = rsvc.getTemplate(VelocityConstants.DEBUG_OUTLINE_START_TEMPLATE,
getInputEncoding(context));
> startTemplate.merge(context, writer);
> Template nameTemplate = rsvc.getTemplate(VelocityConstants.DEBUG_NAME_TEMPLATE, getInputEncoding(context));
> nameTemplate.merge(context, writer);
> }
>
> if (!blockinput) {
> context.pushCurrentTemplateName(arg);
> ((SimpleNode) t.getData()).render(context, writer);
> }
>
> /* Print Debug end output to browser if debug mode is on */
> if (debugMode) {
> Template endTemplate = rsvc.getTemplate(VelocityConstants.DEBUG_OUTLINE_END_TEMPLATE,
getInputEncoding(context));
> endTemplate.merge(context, writer);
> }
> /* Restore the templateName variable to match the main template name */
> context.put(VelocityConstants.TEMPLATE_NAME_VAR, mainTemplateName);
> }
> /*
> * if it's a MIE, it came from the render.... throw it...
> */
> catch (MethodInvocationException e) {
> throw e;
> }
> /**
> * pass through application level runtime exceptions
> */
> catch (RuntimeException e) {
> throw e;
> }
> catch (Exception e) {
> rsvc.getLog().error("Portal #parse: Exception rendering #parse(" + arg + ')', e);
> return false;
> } finally {
> if (!blockinput)
> context.popCurrentTemplateName();
> }
> /*
> * note - a blocked input is still a successful operation as this is expected behavior.
> */
> return true;
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[ https://issues.apache.org/jira/browse/VELOCITY-715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Glass-Husain updated VELOCITY-715:
---------------------------------------
Fix Version/s: (was: 1.7)
> Leaked object in FileResourceLoader#templatePaths
> -------------------------------------------------
>
> Key: VELOCITY-715
> URL: https://issues.apache.org/jira/browse/VELOCITY-715
> Project: Velocity
> Issue Type: Bug
> Components: Engine
> Reporter: Atsushi Isobe
> Priority: Minor
> Attachments: FileResourceLoader.patch, FileResourceLoaderLeakedObjectTest.java
>
>
> org.apache.velocity.runtime.resource.loader.FileResourceLoader#templatePaths has stored
templatename and real file path permanently.So if VelocityEngine#getTemplate(String) has called
by too many files, #templatePaths have been enlarged.
> Bellow my test results.
> ----------------------------------------
> 2009-05-08 19:16:54,571 INFO [FileResourceLoaderLeakedObjectTest] count: 000,000 total:
002,696,488
> 2009-05-08 19:19:23,381 INFO [FileResourceLoaderLeakedObjectTest] count: 065,536 total:
014,689,896
> 2009-05-08 19:22:03,782 INFO [FileResourceLoaderLeakedObjectTest] count: 131,072 total:
025,374,944
> 2009-05-08 19:24:14,756 INFO [FileResourceLoaderLeakedObjectTest] count: 196,608 total:
036,282,696
> 2009-05-08 19:26:37,864 INFO [FileResourceLoaderLeakedObjectTest] count: 262,144 total:
046,776,168
> 2009-05-08 19:28:55,090 INFO [FileResourceLoaderLeakedObjectTest] count: 327,680 total:
057,119,560
> 2009-05-08 19:31:37,524 INFO [FileResourceLoaderLeakedObjectTest] count: 393,216 total:
069,858,824
> 2009-05-08 19:34:10,425 INFO [FileResourceLoaderLeakedObjectTest] count: 458,752 total:
080,019,920
> 2009-05-08 19:36:52,788 INFO [FileResourceLoaderLeakedObjectTest] count: 524,288 total:
090,093,168
> 2009-05-08 19:39:13,662 INFO [FileResourceLoaderLeakedObjectTest] count: 589,824 total:
097,385,776
> 2009-05-08 19:41:54,621 INFO [FileResourceLoaderLeakedObjectTest] count: 655,360 total:
107,387,792
> 2009-05-08 19:44:31,601 INFO [FileResourceLoaderLeakedObjectTest] count: 720,896 total:
117,451,912
> 2009-05-08 19:47:08,890 INFO [FileResourceLoaderLeakedObjectTest] count: 786,432 total:
137,151,792
> 2009-05-08 19:49:44,924 INFO [FileResourceLoaderLeakedObjectTest] count: 851,968 total:
147,277,856
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[ https://issues.apache.org/jira/browse/VELOCITY-715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12772855#action_12772855
]
Will Glass-Husain commented on VELOCITY-715:
--------------------------------------------
Thanks for sharing this.
This isn't a use case I've encountered. These are all unique file names, right? Your test
is assuming hundreds of thousands of different file names. Most sites I've seen have a much
smaller number of template names.
I'm also concerned about the use of a WeakHashMap. I'm not super experienced with this, but
doesn't this remove the key but not the value? I'm concerned this may still leave the reference.
http://www.codeinstructions.com/2008/09/weakhashmap-is-not-cache-understanding.html
> Leaked object in FileResourceLoader#templatePaths
> -------------------------------------------------
>
> Key: VELOCITY-715
> URL: https://issues.apache.org/jira/browse/VELOCITY-715
> Project: Velocity
> Issue Type: Bug
> Components: Engine
> Reporter: Atsushi Isobe
> Priority: Minor
> Attachments: FileResourceLoader.patch, FileResourceLoaderLeakedObjectTest.java
>
>
> org.apache.velocity.runtime.resource.loader.FileResourceLoader#templatePaths has stored
templatename and real file path permanently.So if VelocityEngine#getTemplate(String) has called
by too many files, #templatePaths have been enlarged.
> Bellow my test results.
> ----------------------------------------
> 2009-05-08 19:16:54,571 INFO [FileResourceLoaderLeakedObjectTest] count: 000,000 total:
002,696,488
> 2009-05-08 19:19:23,381 INFO [FileResourceLoaderLeakedObjectTest] count: 065,536 total:
014,689,896
> 2009-05-08 19:22:03,782 INFO [FileResourceLoaderLeakedObjectTest] count: 131,072 total:
025,374,944
> 2009-05-08 19:24:14,756 INFO [FileResourceLoaderLeakedObjectTest] count: 196,608 total:
036,282,696
> 2009-05-08 19:26:37,864 INFO [FileResourceLoaderLeakedObjectTest] count: 262,144 total:
046,776,168
> 2009-05-08 19:28:55,090 INFO [FileResourceLoaderLeakedObjectTest] count: 327,680 total:
057,119,560
> 2009-05-08 19:31:37,524 INFO [FileResourceLoaderLeakedObjectTest] count: 393,216 total:
069,858,824
> 2009-05-08 19:34:10,425 INFO [FileResourceLoaderLeakedObjectTest] count: 458,752 total:
080,019,920
> 2009-05-08 19:36:52,788 INFO [FileResourceLoaderLeakedObjectTest] count: 524,288 total:
090,093,168
> 2009-05-08 19:39:13,662 INFO [FileResourceLoaderLeakedObjectTest] count: 589,824 total:
097,385,776
> 2009-05-08 19:41:54,621 INFO [FileResourceLoaderLeakedObjectTest] count: 655,360 total:
107,387,792
> 2009-05-08 19:44:31,601 INFO [FileResourceLoaderLeakedObjectTest] count: 720,896 total:
117,451,912
> 2009-05-08 19:47:08,890 INFO [FileResourceLoaderLeakedObjectTest] count: 786,432 total:
137,151,792
> 2009-05-08 19:49:44,924 INFO [FileResourceLoaderLeakedObjectTest] count: 851,968 total:
147,277,856
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[ https://issues.apache.org/jira/browse/VELOCITY-738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Glass-Husain resolved VELOCITY-738.
----------------------------------------
Resolution: Won't Fix
If you catch the ParseException, it contains properties for the template name, line, and column
number,
> It would be useful to know that the error is occurred in which context.
> -----------------------------------------------------------------------
>
> Key: VELOCITY-738
> URL: https://issues.apache.org/jira/browse/VELOCITY-738
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
> Affects Versions: 1.6.2
> Reporter: Siri C.
>
> It would be better, if an error message display surroundings of the place where the error
is.
> For example:
> To display that an "(" character is illegal (there are hundreds of those characters in
a template)
> but it would be useful to know that this character occurred in the context "product.getName()".
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[ https://issues.apache.org/jira/browse/VELOCITY-739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12772850#action_12772850
]
Will Glass-Husain commented on VELOCITY-739:
--------------------------------------------
In the interests of conservatism, I'm going to leave this alone. If more people want it
speak up.
> Do not throw exception for quiet references in strict reference checking mode
> -----------------------------------------------------------------------------
>
> Key: VELOCITY-739
> URL: https://issues.apache.org/jira/browse/VELOCITY-739
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
> Affects Versions: 1.6.2
> Reporter: Will Glass-Husain
>
> I used strict reference checking for the first time and discovered that it throws exceptions
even for quiet references.
> <input class="signupInput" type="text" id="StxtFirstNames"
> name="firstName" value="$!user.firstName"/>
> org.apache.velocity.exception.MethodInvocationException: Variable
> $user has not been set at layout/slide_login.vm[line 13, column 117]
> This doesn't make sense to me. If a template author designates a reference as quiet,
it's explicitly not an error. We're preventing the use of this convenient feature.
> It's not a hard change to fix this. Does it break backwards compatibility if we change
this?
> Incidentally, there's an identical problem for InvalidReferenceEventHandler. I'll file
a separate issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[ https://issues.apache.org/jira/browse/VELOCITY-720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Glass-Husain resolved VELOCITY-720.
----------------------------------------
Resolution: Fixed
I changed the Resource Loader code to omit the stack trace for a resource not found. It seems
overkill. (and rather frightening). It still logs the message, in this case: cannot find
resource VM_global_library.vm.
> Suppress startup error message if macro library not found
> ---------------------------------------------------------
>
> Key: VELOCITY-720
> URL: https://issues.apache.org/jira/browse/VELOCITY-720
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
> Reporter: Will Glass-Husain
> Priority: Minor
> Fix For: 1.7
>
>
> Ever since upgrading to Velocity 1.6.2 I get a stack trace when starting up due to a
missing macro library. The stack trace in particular makes for a very noisy log. I suggest
we do not print a stacktrace for a missing macro library at startup.
> Here's my settings
> VelocityEngine ve = new VelocityEngine();
> ve.setProperty("resource.loader", "class");
> ve.setProperty("class.resource.loader.class", "org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader");
> ve.setProperty("class.resource.loader.cache", "false");
> ve.setProperty("runtime.Log.invalid.references ", "false");
> ve.setProperty("resource.manager.logwhenfound", "false");
> ve.setProperty("runtime.log.logsystem.class", "org.apache.velocity.runtime.log.SimpleLog4JLogSystem");
> ve.setProperty("runtime.log.logsystem.log4j.category", "com.forio.Velocity");
> And here's the log report
> 2009-05-26 23:46:58 DEBUG Velocimacro : "velocimacro.library" is not set. Trying default
library: VM_global_library.vm
> 2009-05-26 23:46:58 DEBUG Could not load resource 'VM_global_library.vm' from ResourceLoader
org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader:
> 2009-05-26 23:46:58 DEBUG
> org.apache.velocity.exception.ResourceNotFoundException:
> ClasspathResourceLoader Error: cannot find resource VM_global_library.vm
> at org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader.getResourceStream(ClasspathResourceLoader.java:131)
> at org.apache.velocity.runtime.resource.loader.ResourceLoader.resourceExists(ResourceLoader.java:224)
> at org.apache.velocity.runtime.resource.ResourceManagerImpl.getLoaderForResource(ResourceManagerImpl.java:641)
> at org.apache.velocity.runtime.resource.ResourceManagerImpl.getLoaderNameForResource(ResourceManagerImpl.java:624)
> at org.apache.velocity.runtime.RuntimeInstance.getLoaderNameForResource(RuntimeInstance.java:1464)
> at org.apache.velocity.runtime.VelocimacroFactory.initVelocimacro(VelocimacroFactory.java:159)
> at org.apache.velocity.runtime.RuntimeInstance.init(RuntimeInstance.java:261)
> at org.apache.velocity.app.VelocityEngine.init(VelocityEngine.java:107)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[ https://issues.apache.org/jira/browse/VELOCITY-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Glass-Husain resolved VELOCITY-724.
----------------------------------------
Resolution: Fixed
Hi,
It makes sense to me to upgrade to ant 1.7-- it's been out for a long time. (and the manual
copying of junit lib is very confusing).
I went ahead and upgraded to ant 1.7 but did not drop junit dependency. (changed the build
file with your patch and the docs). It doesn't look like ant comes with junit. Instead,
if it's in the app classpath, it uses it automatically (no need to copy to lib directory).
Does this sound right?
Go ahead and reopen the issue if you've further comments.
Thanks for raising the issue.
WILL
> [PATCH] Is junit-3.8.1.jar optional for Velocity as specified in jar dependencies?
> ----------------------------------------------------------------------------------
>
> Key: VELOCITY-724
> URL: https://issues.apache.org/jira/browse/VELOCITY-724
> Project: Velocity
> Issue Type: Bug
> Components: Build
> Affects Versions: 1.6.2
> Reporter: Aruna Venkataraman
> Priority: Trivial
> Fix For: 1.7
>
> Attachments: Build succeeds with junit.jar.jpg, build.patch, current error message.PNG,
jnuit build failed.jpg, revised error message.PNG, svn diff.PNG
>
>
> When i navigate to the build directory in Velocity 1.6.2 and invoke "ant" then the below
error is got:
> Could not create task or type of type: junit. lib\test.
> Ant could not find the task or a class this task relies upon.
> Refer screenshot
> I deleted the junit-3.8.1.jar file from bin\test-lib as it was specified to be optional,
but it gets created automatically.
> Do we need to remove the dependency on this junit-3.8.1.jar manually?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[ https://issues.apache.org/jira/browse/VELOCITY-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Glass-Husain updated VELOCITY-724:
---------------------------------------
Attachment: (was: ant17.patch)
> [PATCH] Is junit-3.8.1.jar optional for Velocity as specified in jar dependencies?
> ----------------------------------------------------------------------------------
>
> Key: VELOCITY-724
> URL: https://issues.apache.org/jira/browse/VELOCITY-724
> Project: Velocity
> Issue Type: Bug
> Components: Build
> Affects Versions: 1.6.2
> Reporter: Aruna Venkataraman
> Priority: Trivial
> Fix For: 1.7
>
> Attachments: Build succeeds with junit.jar.jpg, build.patch, current error message.PNG,
jnuit build failed.jpg, revised error message.PNG, svn diff.PNG
>
>
> When i navigate to the build directory in Velocity 1.6.2 and invoke "ant" then the below
error is got:
> Could not create task or type of type: junit. lib\test.
> Ant could not find the task or a class this task relies upon.
> Refer screenshot
> I deleted the junit-3.8.1.jar file from bin\test-lib as it was specified to be optional,
but it gets created automatically.
> Do we need to remove the dependency on this junit-3.8.1.jar manually?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[ https://issues.apache.org/jira/browse/VELOCITY-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Glass-Husain updated VELOCITY-724:
---------------------------------------
Attachment: ant17.patch
upgrade requirements to ant 1.7 and drop junit download.
> [PATCH] Is junit-3.8.1.jar optional for Velocity as specified in jar dependencies?
> ----------------------------------------------------------------------------------
>
> Key: VELOCITY-724
> URL: https://issues.apache.org/jira/browse/VELOCITY-724
> Project: Velocity
> Issue Type: Bug
> Components: Build
> Affects Versions: 1.6.2
> Reporter: Aruna Venkataraman
> Priority: Trivial
> Fix For: 1.7
>
> Attachments: ant17.patch, Build succeeds with junit.jar.jpg, build.patch, current
error message.PNG, jnuit build failed.jpg, revised error message.PNG, svn diff.PNG
>
>
> When i navigate to the build directory in Velocity 1.6.2 and invoke "ant" then the below
error is got:
> Could not create task or type of type: junit. lib\test.
> Ant could not find the task or a class this task relies upon.
> Refer screenshot
> I deleted the junit-3.8.1.jar file from bin\test-lib as it was specified to be optional,
but it gets created automatically.
> Do we need to remove the dependency on this junit-3.8.1.jar manually?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[ https://issues.apache.org/jira/browse/VELOCITY-717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Glass-Husain resolved VELOCITY-717.
----------------------------------------
Resolution: Cannot Reproduce
resolving. try with the latest version (from svn head). if you still have this difficulty,
please reopen the bug and give a little more detail. Thanks!
> Engine throws an NPE using custom macro libs if the IncludeEventHandler returns null
> ------------------------------------------------------------------------------------
>
> Key: VELOCITY-717
> URL: https://issues.apache.org/jira/browse/VELOCITY-717
> Project: Velocity
> Issue Type: Bug
> Components: Engine
> Affects Versions: 1.6.2
> Environment: Suse Linux
> Reporter: Johann Weber
> Priority: Critical
> Fix For: 1.7
>
>
> The Engine throws an NPE if the IncludeEventHandler returns null.
> (using merge method with a list of macro libs)
> java.lang.NullPointerException
> >> at java.util.Hashtable.get(Hashtable.java:333)
> >> at org.apache.velocity.runtime.VelocimacroManager.getNamespace(VelocimacroManager.java:318)
> >> at org.apache.velocity.runtime.VelocimacroManager.get(VelocimacroManager.java:215)
> >> at org.apache.velocity.runtime.VelocimacroFactory.getVelocimacro(VelocimacroFactory.java:563)
> >> at org.apache.velocity.runtime.RuntimeInstance.getVelocimacro(RuntimeInstance.java:1563)
> >> at org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:218)
> >> at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:175)
> >> at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:336)
> >> at org.apache.velocity.runtime.directive.Parse.render(Parse.java:260)
> >> at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:175)
> >> at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:336)
> >> at org.apache.velocity.Template.merge(Template.java:328)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org