velocity-dev@jakarta.apache.org
[Top] [All Lists]

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

Subject: [jira] Commented: (VELOCITY-736) Introspection regression from 1.5 to 1.6.2
From: "Nathan Bubna (JIRA)"
Date: Thu, 8 Oct 2009 11:11:31 -0700 PDT
    [ 
https://issues.apache.org/jira/browse/VELOCITY-736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12763601#action_12763601
 ] 

Nathan Bubna commented on VELOCITY-736:
---------------------------------------

I've been thinking about this.  The oft-stated intention of Velocity is to 
provide access to "public methods declared in public classes (or public 
interface)".  The method in question is public and it is being called on an 
instance of a public subclass, but it is not actually declared in a public 
class.  So, it was something of an undocumented, unintentional fluke that this 
worked previously.  Such regressions are undesirable, but are arguably bug 
fixes.   Certainly in the work for 1.6, we never thought about supporting 
"public methods declared *or inherited* by public classes".

That said, i think the Commons-FileUpload folks are correct to have the 
SizeException class be protected and you are clearly justified to expect that a 
public method inherited by a public subclass should be callable via VTL.  So it 
feels like more than a regression, this is exposing a bug in our "oft-stated 
intention".

Though i haven't looked deeply at it, my instinct is that fixing this will 
either carry a significant performance penalty for ClassMap, require an even 
wider broadening of the methods support and/or undo other recent fixes.  Unless 
further examination proves me wrong on that, it is not very likely that this 
will be un-regressed in 1.6.x.  Right now, i'm guessing that fixing this will 
lead to a broadening of supported methods and thus be only fit for 1.7.

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

<Prev in Thread] Current Thread [Next in Thread>