Re: [VOTE] Velocity Engine 1.6.1 release
+1 it still works -- Ilkka Nathan Bubna wrote: Ok, there were no complaints about the latest 1.6.1 test build, so it is time to vote: The test build candidate for release is still available here: http://people.apache.org/~nbubna/velocity/engine/1.6.1/ Please vote regarding your support for releasing this test build as Velocity Engine 1.6.1: [ ] +1 Let's do it [ ] +0 Have fun; i don't care. [ ] -0 Not sure about this, but i won't stop you. [ ] -1 No, because __ The voting period is typically 72 hours, putting its close time as roughly 7am PST on Mon, Dec 15th. Vote early and vote often! :) On Fri, Dec 5, 2008 at 9:58 AM, Nathan Bubna nbu...@gmail.com wrote: if you didn't notice, a vararg method reflection bug (VELOCITY-651) was found shortly after we got 1.6 released. it is now fixed, and i think we need to do a bug fix release for it. it's not the sort of thing that should wait around for a 1.7 release. so, here's a test build for 1.6.1. http://people.apache.org/~nbubna/velocity/engine/1.6.1/ please give it a look and a test. i'll probably call for a vote on Tuesday. i'm aiming for a Fri (12/12) release. thanks, nathan - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
Re: [VOTE] Release Velocity Engine 1.6
+1 test build works great for us :) -- Ilkka Nathan Bubna wrote: Ok, there were no complaints about the current test build that were worth generating a new test build and delaying this (IMO), so i'm moving on to a vote. The test build candidate for release is still available here: http://people.apache.org/~nbubna/velocity/engine/1.6/ Please vote regarding your support for releasing this new test build as Velocity Engine 1.6: [ ] +1 Let's do it [ ] +0 Have fun; i don't care. [ ] -0 Not sure about this, but i won't stop you. [ ] -1 No, because __ The voting period is typically 72 hours, putting its close time as roughly 7am PST on Monday, Dec 1st. If the vote passes, I'll push this to the mirrors and change the web site and get Henning to deploy it. With luck i'll be able to announce it by Wed. On Fri, Nov 21, 2008 at 11:38 AM, Nathan Bubna [EMAIL PROTECTED] wrote: ok folks, i think the time has come; here's a build for Engine 1.6: http://people.apache.org/~nbubna/velocity/engine/1.6/ please kick the tires and report any and all nitpicks soon. PLEASE try it out and look for problems. (yes, i am begging!) assuming no one sees any problems, i'll call for a release vote next friday. thanks, nathan p.s. this release should rock; here's a rough list of new things in this release: Major memory and speed performance improvements varargs support for object method calls #evaluate( $stringthatcontainsvtl ) #define( $body ) for VTL blocks as references #end #break for ending #foreach loops prematurely Static utility methods via context.put(Math, Math.class) fixes for many annoying little syntax/parsing bugs #parse( mymacros.vm ) CommonsLogLogChute, ServletLogChute Fixed and much improved StringResourceLoader velocimacro.max.depth programmatic inclusion of macro libraries can now call fixed-length list methods on arrays $velocityHasNext for #foreach loops configurable connection timeout for URLResourceLoader Uberspect chainability and link-ability consistent, correct line numbers and macro/template stacks in logs and exceptions - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (VELOCITY-642) Array arguments in method calls are wrapped with an extra array
Array arguments in method calls are wrapped with an extra array
---
Key: VELOCITY-642
URL: https://issues.apache.org/jira/browse/VELOCITY-642
Project: Velocity
Issue Type: Bug
Components: Engine
Affects Versions: 1.6-beta1
Reporter: Ilkka Priha
Velocity 1.6 b2 wraps array arguments of method calls with an extra array
causing the calls to fail and making this version incompatible with previous
versions.
A simple template, like this, demonstrates the behavior:
#set ($_array = [ 1, 2, 3 ])
$test.arrayTest($_array.toArray())
Depending on the signature of test.arrayTest() , the template prints:
public String arrayTest(Object[] array)
{
return java.util.Arrays.deepToString((Object[]) array);
}
[[1, 2, 3]]
public String arrayTest(Object... array)
{
return java.util.Arrays.deepToString(array);
}
[[1, 2, 3]]
public String arrayTest(Object array)
{
return java.util.Arrays.deepToString((Object[]) array);
}
[1, 2, 3]
Actually, I noticed later that the argument doesn't have to be an array, this
version of Velocity seems to wrap any argument into an array if the method
expects an array. So maybe this is a feature and not a bug, but it should
detect already correct array arguments and leave them intact to keep existing
templates working.
-- Ilkka
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-595) ResourceManagerImpl.getResource() causes locking issues
[ https://issues.apache.org/jira/browse/VELOCITY-595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12604043#action_12604043 ] Ilkka Priha commented on VELOCITY-595: -- Wouldn't it be enough to synchronize the loadResource() method only, now reading from the cache is also synchronized. The benchmark comparing the effects of this change was run with a duo-core processor, but in heavy duty servers we may have 8-16 processors where synchronization slows down performance much more than in simpler cases (couldn't find the test template to reproduce and test VELOCITY-24). ResourceManagerImpl.getResource() causes locking issues --- Key: VELOCITY-595 URL: https://issues.apache.org/jira/browse/VELOCITY-595 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.5 Environment: jdk 1.5 Reporter: Allen Gilliland The ResourceManagerImpl.getResource() method is synchronized, which makes it difficult to share a Velocity Runtime between threads in an environment such as a j2ee web application. After upgrading Velocity to version 1.5 in Roller and running some performance tests I saw a very noticeable decrease in throughput for the application. I fired up jconsole and noticed that almost all of my app server threads were in a BLOCKED state and were waiting on the ResourceManagerImpl.getResource() method. In my particular case the difference resulted in a loss of 2/3 of my original ops/sec, which is pretty huge. After simply switching Velocity back to the 1.4 release and rerunning the test I saw the results I expected. I assume this is overactive use of Java synchronization because the developer guide suggests that the singleton model is very appropriate model for use in a Servlet 2.2+ compliant web application. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-600) #foreach velocityCount
[
https://issues.apache.org/jira/browse/VELOCITY-600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12603777#action_12603777
]
Ilkka Priha commented on VELOCITY-600:
--
One of the good design principles in Velocity core has been to not to reserve
hard-coded keywords from the context. To follow this principle,
$velocityHasNext should be configurable in the same way as $velocityCount is.
-- Ilkka
#foreach velocityCount
Key: VELOCITY-600
URL: https://issues.apache.org/jira/browse/VELOCITY-600
Project: Velocity
Issue Type: Improvement
Components: Engine
Reporter: Adrian Tarau
Priority: Minor
Fix For: 1.5.1
Attachments: VELOCITY-600.patch
velocityCount = Used in the #foreach() directive, defines the string to be
used as the context key for the loop count. A template would access the loop
count as $velocityCount.
Knowing current version of the loop counter is very useful, but something is
missing. Very often, when you generate some content base on a
model(JavaScript code based on some UI model) you have the need to know if
this is the last time when the #foreach block will be executed or not.
Example
You have a collection of objects Property(bean with key, value fields) and
you want to generate a JavaScript object with them. The result should be like
this :
{id : 1 , name = John, ...}
you can generate this with
{
#foreach($property in $properties)
$property.key : $property.value #if($velocityCount !=
$properties.size()) , #end
#end
}
You can store $properties.size() of course outside the loop.
The template will be less verbose if I will have something like that.
#if($velocityHasNext) , #end.
Instead of saving only the counter, a new variable called velocityHasNext
whould be populated with the result of iterator.hasNext(). This is a minor
modification of current #foreach directive
while (!maxNbrLoopsExceeded i.hasNext())
{
// TODO: JDK 1.4+ - valueOf()
context.localPut(counterName , new Integer(counter));
context.localPut(hasNextName , i.hasNext()); --- here is the
change
Object value = i.next();
context.localPut(elementKey, value);
/*
* If the value is null, use the special null holder context
*/
if( value == null )
{
if( nullHolderContext == null )
{
// lazy instantiation
nullHolderContext = new NullHolderContext(elementKey,
context);
}
node.jjtGetChild(3).render(nullHolderContext, writer);
}
else
{
node.jjtGetChild(3).render(context, writer);
}
counter++;
// Determine whether we're allowed to continue looping.
// ASSUMPTION: counterInitialValue is not negative!
maxNbrLoopsExceeded = (counter - counterInitialValue) =
maxNbrLoops;
}
also init should contain
public void init(RuntimeServices rs, InternalContextAdapter context, Node
node)
throws TemplateInitException
{
super.init(rs, context, node);
counterName = rsvc.getString(RuntimeConstants.COUNTER_NAME);
hasNextName = rsvc.getString(RuntimeConstants.HAS_NEXT_NAME);
counterInitialValue =
rsvc.getInt(RuntimeConstants.COUNTER_INITIAL_VALUE);
}
This should help creating clear templates(and avoid some mistakes, sometime -
like using the wrong collection to test :) ).
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
