OK. Here is what I've found. For some reason, in the ResourceMangerImpl.refreshResource, the macros file is coming back a resource type of 0 instead of 1 or 2. Therefore, it is throwing a null pointer exception when attempts to create a new resource.
On Mon, Aug 4, 2008 at 12:45 PM, Erron Austin <[EMAIL PROTECTED]>wrote: > Is there a test case for including macros in a seperate file that is > included using the template merge? > > I'm testing this build and I'm getting a null pointer only when I > update the file. > > > > On 8/4/08, Jarkko Viinamäki (JIRA) <[email protected]> wrote: > > > > [ > > > https://issues.apache.org/jira/browse/VELOCITY-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > > ] > > > > Jarkko Viinamäki updated VELOCITY-607: > > -------------------------------------- > > > > Attachment: velocity-1.6-dev-macro-performance-IDEAS-v2.2.patch > > > > Latest attachment includes final tweaks to improve performance. I'll > start > > waiting for feedback on these changes. With these changes 1.6-dev is > 10-20% > > faster than 1.5 with the tests I ran (on single core laptop). > > > > Interestingly the creation of the macro context in > VelocimacroProxy.render > > method costs a lot of time because of the memory allocation. There's no > easy > > way to avoid this though. > > > >> Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared > to > >> 1.5 > >> > ------------------------------------------------------------------------------ > >> > >> Key: VELOCITY-607 > >> URL: https://issues.apache.org/jira/browse/VELOCITY-607 > >> Project: Velocity > >> Issue Type: Bug > >> Components: Engine > >> Environment: Maven 2, JUnit, JUnitPerf, JRat, custom testbench: > >> http://www.iki.fi/wyla/velocity/testbench > >> Reporter: Jarkko Viinamäki > >> Priority: Critical > >> Fix For: 1.6 > >> > >> Attachments: velocity-1.5-velocity24-test.PNG, > >> velocity-1.6-dev-macro-performance-IDEAS-v2.2.patch, > >> velocity-1.6-head-20080725-velocity24-test.PNG > >> > >> > >> The following test template (see VELOCITY-24): > >> ## local macro, not global > >> #macro(letter $char) > >> This is the letter $char > >> #end > >> #letter("A") > >> #letter("B") > >> #letter("C") > >> #letter("D") > >> #letter("E") > >> #letter("F") > >> #letter("G") > >> #letter("H") > >> #letter("I") > >> #letter("J") > >> #letter("K") > >> #letter("L") > >> #letter("M") > >> #letter("N") > >> #letter("O") > >> #letter("P") > >> #letter("Q") > >> #letter("R") > >> #letter("S") > >> #letter("T") > >> #letter("U") > >> #letter("V") > >> #letter("W") > >> #letter("X") > >> #letter("Y") > >> #letter("Z") > >> --- > >> Works quickly and correctly with Velocity 1.5 with several concurrent > >> threads. However, 1.6-dev is a LOT slower (even 20x). > >> The major performance bottlenecks seem to be: > >> RuntimeMacro.render (60% of time) > >> VelocimacroFactory.getVelocimacro (20% of time) > >> With several threads this test also causes Velocity to throw error(s): > >> org.apache.velocity.exception.MacroOverflowException: Exceed maximum 20 > >> macro calls. Call Stack:letter->letter->letter->letter->letter > >> at > >> > org.apache.velocity.runtime.VelocimacroFactory.startMacroRendering(VelocimacroFactory.java:179) > >> at > >> > org.apache.velocity.runtime.RuntimeInstance.startMacroRendering(RuntimeInstance.java:1693) > >> at > >> > org.apache.velocity.runtime.directive.VelocimacroProxy.render(VelocimacroProxy.java:200) > >> at > >> > org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:230) > >> at > >> > org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:178) > >> at > >> > org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:323) > >> at org.apache.velocity.Template.merge(Template.java:324) > >> at org.apache.velocity.Template.merge(Template.java:232) > >> at > >> > org.apache.velocity.test.load.Velocity24Test.testRendering(Velocity24Test.java:51) > >> This is related to VELOCITY-297 but the fix doesn't seem work with the > new > >> modified macro implementation. > > > > -- > > 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] > > > > > > -- > Sent from Gmail for mobile | mobile.google.com >
