Nabble - Velocity - Dev

[jira] Created: (VELOCITY-745) Modify ClassMap.java to use getMethods() rather than get getDeclaredMethods()

2009-11-19T14:49:39Z

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@...
For additional commands, e-mail: dev-help@...

[jira] Created: (VELOCITY-744) No more VM adding logs

2009-11-19T10:11:39Z

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@...
For additional commands, e-mail: dev-help@...

[jira] Created: (VELTOOLS-124) LoopTool fails to retrieve $loop.index, $loop.first etc for the last element in a collection.

2009-11-17T15:14:39Z

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@...
For additional commands, e-mail: dev-help@...

[jira] Updated: (VELTOOLS-124) LoopTool fails to retrieve $loop.index, $loop.first etc for the last element in a collection.

2009-11-17T15:14:39Z

[ 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@...
For additional commands, e-mail: dev-help@...

Re: [tools] Adding localization method to DateTool

2009-11-15T12:24:12Z

On Sun, Nov 15, 2009 at 7:26 AM, Christopher Schultz
<chris@...> 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@...> 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@...
For additional commands, e-mail: dev-help@...

Re: [tools] Adding localization method to DateTool

2009-11-15T07:26:32Z

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@...> 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

signature.asc (268 bytes) Download Attachment

[jira] Updated: (VELOCITY-657) $velocityHasNext not working properly (returns true even if iterator does not have next value)

2009-11-13T06:37:39Z

[ 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).

[jira] Commented: (VELOCITY-657) $velocityHasNext not working properly (returns true even if iterator does not have next value)

2009-11-13T06:35:39Z

[ 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

[jira] Created: (DBF-11) Update libraries version (FOP)

2009-11-13T03:12:39Z

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@...
For additional commands, e-mail: dev-help@...

[Velocity Wiki] Update of "BoardReport-November2009" by HenningSchmiedehausen

2009-11-12T12:01:03Z

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@...
For additional commands, e-mail: dev-help@...

[Velocity Wiki] Update of "ASFBoardReports" by HenningSchmiedehausen

2009-11-12T10:30:47Z

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@...
For additional commands, e-mail: dev-help@...

[jira] Updated: (VELOCITY-743) The character ":" if present within the curly braces of a variable throws exception

2009-11-09T11:11:32Z

[ 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?

[jira] Created: (VELOCITY-743) The character ":" if present within the curly braces of a variable throws exception

2009-11-09T10:57:32Z

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@...
For additional commands, e-mail: dev-help@...

[jira] Created: (VELOCITY-742) Easily Add/Remove/Replace Directives Without Cracking Open Velocity Jar

2009-11-06T06:20:32Z

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:  (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@...
For additional commands, e-mail: dev-help@...

[jira] Commented: (VELOCITY-736) Introspection regression from 1.5 to 1.6.2

2009-11-04T05:57:32Z

[ 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());
> }
> }

[jira] Commented: (VELOCITY-715) Leaked object in FileResourceLoader#templatePaths

2009-11-03T18:13:32Z

[ 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

[jira] Resolved: (VELOCITY-740) InvalidReferenceEventHandler should get indication that a reference is quiet

2009-11-02T21:33:59Z

[ 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.

[jira] Resolved: (VELOCITY-586) Add debugging hooks to #parse

2009-11-02T19:09:59Z

[ 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@...">Geir Magnusson Jr.</a>
> * @author <a href="mailto:jvanzyl@...">Jason van Zyl</a>
> * @author <a href="mailto:Christoph.Reck@...">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;
> }
> }

[jira] Updated: (VELOCITY-715) Leaked object in FileResourceLoader#templatePaths

2009-11-02T19:06:00Z

[ 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)

[jira] Commented: (VELOCITY-715) Leaked object in FileResourceLoader#templatePaths

2009-11-02T19:05:59Z

[ 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

[jira] Resolved: (VELOCITY-738) It would be useful to know that the error is occurred in which context.

2009-11-02T18:55:59Z

[ 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()".

[jira] Commented: (VELOCITY-739) Do not throw exception for quiet references in strict reference checking mode

2009-11-02T18:53:59Z

[ 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.

[jira] Resolved: (VELOCITY-720) Suppress startup error message if macro library not found

2009-11-02T18:49:59Z

[ 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)

[jira] Resolved: (VELOCITY-724) [PATCH] Is junit-3.8.1.jar optional for Velocity as specified in jar dependencies?

2009-11-02T18:39:59Z

[ 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?

[jira] Updated: (VELOCITY-724) [PATCH] Is junit-3.8.1.jar optional for Velocity as specified in jar dependencies?

2009-11-02T18:33:59Z

[ 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)

[jira] Updated: (VELOCITY-724) [PATCH] Is junit-3.8.1.jar optional for Velocity as specified in jar dependencies?

2009-11-02T18:27:59Z

> [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?

[jira] Resolved: (VELOCITY-717) Engine throws an NPE using custom macro libs if the IncludeEventHandler returns null

2009-11-02T18:11:59Z

[ 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)

[jira] Commented: (VELOCITY-717) Engine throws an NPE using custom macro libs if the IncludeEventHandler returns null

2009-11-02T18:07:59Z

[ https://issues.apache.org/jira/browse/VELOCITY-717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12772828#action_12772828 ]

Will Glass-Husain commented on VELOCITY-717:
--------------------------------------------

Hi,

I tried to replicate this issue and couldn't. I tried merging in a macro library with Template.merge() as you suggest. I also tried doing #parse in the included file and referencing the macro in the parent file. Neither generated an NPE.

Can you please provide more details, ideally the VM and macro files you are using, and a code sample showing how you include the macros and merge the code.

[jira] Commented: (VELOCITY-739) Do not throw exception for quiet references in strict reference checking mode

2009-10-30T16:23:59Z

[ https://issues.apache.org/jira/browse/VELOCITY-739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12772172#action_12772172 ]

Byron Foster commented on VELOCITY-739:
---------------------------------------

My preference would be the current behavior. But, it's not a strong preference, and if most people like the above described behavior, I would not object.

My only argument is that it casts a wider net, and now all references with the bang notation don't benefit as much from strict checking and error reporting.

I'v considered making it so that expressions that evaluate to null, simply render as an empty string without error, which makes the current use of the bang reference unnecessary. If someone did want stricter handling of nulls they could do it through handlers.

I assume that the above behavior is only for the root variable, so given:

$!a.b

if 'a' is not in the context, then nothing is rendered. But if 'a' is defined but does not contain the method 'b', or 'a' is null, then Velocity will throw an error.

Re: [tools] Adding localization method to DateTool

2009-10-29T12:04:27Z

On Thu, Oct 29, 2009 at 8:06 AM, Christopher Schultz
<chris@...> 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.

> Thanks,
> -chris
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Re: [tools] Adding localization method to DateTool

2009-10-29T08:06:30Z

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?

Thanks,
-chris

signature.asc (268 bytes) Download Attachment

Re: [tools] Adding localization method to DateTool

2009-10-29T08:02:07Z

Nathan,

On 10/29/2009 10:36 AM, Nathan Bubna wrote:
>> return df.toLocalizedPattern();
>
> I believe you'll have to cast to (SimpleDateFormat) to get the
> toLocalizedPattern() method.

Yup, I noticed that as I started to write the code. For now, I just have
it allowing a ClassCastException. I wasn't sure what to do if the
DateFormat returned wasn't a SimpleDateFormat. I suppose I could always
re-code whatever DateFormat comes back into a SimpleDateFormat and use
that. That ought to always work, even if it ends up being a bit slow.

> In practice, such a cast should always
> work, but i don't trust that. So, perhaps cast, but try/catch any
> ClassCastException and return null (or attempt your original plan in
> such cases.

I like re-coding into SimpleDataFormat better.

I'm working on unit tests right now and everything looks good, including
the use of special formats such as 'short_time' and stuff like that.

I'll also fix the direct-access of the 'timezone' member when I'm
finished with this.

-chris

signature.asc (268 bytes) Download Attachment

Re: [tools] Adding localization method to DateTool

2009-10-29T07:36:33Z

On Thu, Oct 29, 2009 at 7:27 AM, Christopher Schultz
<chris@...> wrote:

> All,
>
> On 10/28/2009 5:10 PM, Christopher Schultz wrote:
>> public String toLocalizedPattern(String dateFormat,
>> Locale targetLocale)
>> {
>> new SimpleDateFormat(formatPattern,
> targetLocale).toLocalizedPattern();
>> }
>
> After looking at DateTool, I'm thinking that I should probably write
> this method as:
>
> public String toLocalizedPattern(String dateFormat,
> Locale targetLocale)
> {
> DateFormat df = getDateFormat(dateFormat,
> targetLocale,
> getTimeZone());
>
> return df.toLocalizedPattern();
> }

I believe you'll have to cast to (SimpleDateFormat) to get the
toLocalizedPattern() method. In practice, such a cast should always
work, but i don't trust that. So, perhaps cast, but try/catch any
ClassCastException and return null (or attempt your original plan in
such cases.

> Using the getDateFormat will allow date formats such as "short" and
> "short_date" and stuff like that, and will be more consistent with the
> rest of the DateTool API.
>
> Any comments?
>
> Also, I noticed that some methods explicitly use this.getTimeZone() and
> others reference the private member directly.

that's probably an error that should be fixed. i can't think of why
any methods but the setters and getters should use the member.

> Technically, DateUtil does
> have a subclass (ComparisonDateTool) so it should always use getTimeZone
> in case the subclass wishes to override it. On the other hand, this
> class is not /really/ meant for subclassing and so direct member access
> seems reasonable.

no. it's meant to be subclassable.

> Any comments on this while I'm mucking-around in
> DateTool? (Of course, any changes to other parts of the code will be
> made in a different commit).

thanks. :)

>
> Thanks,
> -chris
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Re: [tools] Adding localization method to DateTool

2009-10-29T07:27:04Z

All,

On 10/28/2009 5:10 PM, Christopher Schultz wrote:
> public String toLocalizedPattern(String dateFormat,
> Locale targetLocale)
> {
> new SimpleDateFormat(formatPattern,
targetLocale).toLocalizedPattern();
> }

After looking at DateTool, I'm thinking that I should probably write
this method as:

public String toLocalizedPattern(String dateFormat,
Locale targetLocale)
{
DateFormat df = getDateFormat(dateFormat,
targetLocale,
getTimeZone());

return df.toLocalizedPattern();
}

Using the getDateFormat will allow date formats such as "short" and
"short_date" and stuff like that, and will be more consistent with the
rest of the DateTool API.

Any comments?

Also, I noticed that some methods explicitly use this.getTimeZone() and
others reference the private member directly. Technically, DateUtil does
have a subclass (ComparisonDateTool) so it should always use getTimeZone
in case the subclass wishes to override it. On the other hand, this
class is not /really/ meant for subclassing and so direct member access
seems reasonable. Any comments on this while I'm mucking-around in
DateTool? (Of course, any changes to other parts of the code will be
made in a different commit).

Thanks,
-chris

signature.asc (268 bytes) Download Attachment

Re: [tools] Adding localization method to DateTool

2009-10-29T07:02:58Z

Nathan,

On 10/28/2009 6:32 PM, Nathan Bubna wrote:

> You've not been forgotten. :) You're correct that this is not
> currently supported. This only adds a simple method to a single
> tool's VTL API and thus would not impede any forthcoming long-wished
> for 2.0 release (at least in my book). Go for it.
>
> One question, would it make sense to also add a:
>
> public String toLocalizedPattern(String format) {
> return toLocalizedPattern(format, getLocale());
> }
>
> for completeness? Or is that redundant?

After reading everyone's comments, I'm not really sure a second method
is necessary. As Antonio mentions, the server Locale is next to useless,
although tools.xml can be used to define the default locale for
DateTool. For times when you know you want to use the server's Locale
(or the DateTool's Locale), you can easily get that Locale object and
pass it into the two-argument method.

The bottom line is that neither technique (using a custom Locale nor the
server/DateTool Locale) is possible at the moment, and adding a single
method allows them both if desired.

I'm happy to add a second method if there's a lot of support for it,
especially because it's nearly as trivial as the first.

Thanks,
-chris

signature.asc (268 bytes) Download Attachment