Gump is failing
Hi, Gump is still failing due to missing hsqldb jars. How do we get them in there? Henning, last time we talked you weren't seeing all the Gump messages - did you see the last one? WILL -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tlp site?
Thanks! What are the jakarta.apache.org tasks? WILL On 11/9/06, Henri Yandell [EMAIL PROTECTED] wrote: Looks like you guys are ready to move to velocity.apache.org? Let me know if you want me to take care of the jakarta.apache.org side of things (it's become a routine). Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (VELOCITY-362) can't load macros in file loaded with #parse
[ http://issues.apache.org/jira/browse/VELOCITY-362?page=all ] Will Glass-Husain reopened VELOCITY-362: As discussed on the dev list, I see this as an important to-do for version 1.6. Reopening. can't load macros in file loaded with #parse Key: VELOCITY-362 URL: http://issues.apache.org/jira/browse/VELOCITY-362 Project: Velocity Issue Type: Improvement Components: Engine Affects Versions: 1.4 Environment: Operating System: All Platform: All Reporter: whxbb Priority: Minor I think this is a big bug. I've used velocity in my projects, erveything is ok but this. i want to know it's this problem will be resolved in next version? if it's not, i have to abandon velocity. the bug is : from doc: This is important to remember if you try to #parse() a template containing inline #macro() directives. Because the #parse() happens at runtime, and the parser decides if a VM-looking element in the template is a VM at parsetime, #parse()-ing a set of VM declarations won't work as expected. To get around this, simply use the velocimacro.library facility to have Velocity load your VMs at startup. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-448) Can't define macro in separate file and use it in another file.
[ http://issues.apache.org/jira/browse/VELOCITY-448?page=comments#action_12448752 ] Will Glass-Husain commented on VELOCITY-448: As discussed on the dev list, I see this as an important todo for 1.6. I've reopened Velocity-362 as a reminder of this. Can't define macro in separate file and use it in another file. --- Key: VELOCITY-448 URL: http://issues.apache.org/jira/browse/VELOCITY-448 Project: Velocity Issue Type: Improvement Environment: WindowsXP Reporter: Colbert Philippe Fix For: 1.6 I my first file called myDefinition.vm , I difined a trivial macro #macro ( myMycro $p1 $p2) $p1 $p2 #end In my second file, I parse and call my macro: #parse( myDefinition.vm) #myMacro( apple orange) The result is always a single line: #myMacro( apple orange) Velocity does not recognize the definition of my macro. I tried putting the macro is the same file and that works. But when the definition from another file does not seem to work. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VELOCITY-284) MethodInvocationException is handled inconsistently
[ http://issues.apache.org/jira/browse/VELOCITY-284?page=all ]
Will Glass-Husain resolved VELOCITY-284.
Fix Version/s: 1.5
(was: 2.0)
(was: 1.6)
Resolution: Fixed
rsolved again. r473363
MethodInvocationException is handled inconsistently
---
Key: VELOCITY-284
URL: http://issues.apache.org/jira/browse/VELOCITY-284
Project: Velocity
Issue Type: Improvement
Components: Engine
Affects Versions: 1.4, 1.5
Environment: Operating System: All
Platform: Other
Reporter: Mike Rettig
Assigned To: Will Glass-Husain
Priority: Minor
Fix For: 1.5
Attachments: swallowed_exception.txt
It appears that the exception handling is different depending on whether the
method is invoked as a passed parameter to a velocimacro or just in a
template.
Ex.
#doTextLink( ${myObj.exception})
${myObj.exception}
The first #doTextLink macro will throw an exception, but it will be logged and
ignored. However, the second invocation will throw the exception properly.
I have a patch that should fix this behavior. The exception just needs to be
rethrown up the call stack. A small signature change to a couple of methods.
Thanks,
Mike Rettig
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r471381 - in
Hmmm... Directive.init() might be a problem. If a user writes a custom directive, they subclass Directive. init used to throw Exception, now it throws TemplateInitException. Since this is a class not an interface we might still be ok. Let me test this. I previously tested this patch with a binary of a custom directive I'd written and found compatibility to be fine, but my directive didn't implement init(). WILL On 11/6/06, Nathan Bubna [EMAIL PROTECTED] wrote: That's no problem for code calling the methods, but not for code overriding them. Are there any legitimate use cases for overriding these methods? On 11/5/06, Will Glass-Husain [EMAIL PROTECTED] wrote: You might be right. It started as a small change but became more significant as I worked through it. Still, I think it's ok since we are taking away exceptions not adding them. WILL On 11/5/06, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] writes: I like that but it is still a bold change right before beta2. :-) I do expect heavy bleeding edge users like Malcolm to squeal if that breaks things. :-) Best regards Henning Author: wglass Date: Sun Nov 5 00:56:58 2006 New Revision: 471381 URL: http://svn.apache.org/viewvc?view=revrev=471381 Log: Removed generic Exception from throws for Template class and most Node classes. In response to VELOCITY-436. There's a danger of a change to an API call since this involves method signatures, but the only interface that seems relevant is Node.init (used when defining custom directives). Since we are removing Exception and adding TemplateInitException this seems to work. -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Social behaviour: Bavarians can be extremely egalitarian and folksy. -- http://en.wikipedia.org/wiki/Bavaria Most Franconians do not like to be called Bavarians. -- http://en.wikipedia.org/wiki/Franconia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - 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] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: macro issues
Great, will do. A little more detail on when I think we should mark WONTFIX (lets discuss). I think it's nice to have enhancement requests/future thoughts in JIRA. The wont fix is rather offputting. There's a continuum for responses to enhancement requests.. -- committers really enthusiastic about idea; will certainly go in -- idea fits with philosophical direction of tool, might go in but not right now -- idea is from left field, will likely not go in I'd suggest we always leave the first two bullets as open issues. Helps capture usage details, example cases, mailing list threads. The third is a matter of judgement. Doesn't hurt to occasionally leave a creative idea open, but more often we should provide feedback and (if appropriate) ask the poster to move sample code to the wiki. A good rule of thumb should be that all active committers believe an idea is from left field in order to mark WONTFIX. Or at least that it's ok for a committer who's interested in immediate reopen the issue. Just my thoughts. Comments? WILL On 11/6/06, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Will Glass-Husain [EMAIL PROTECTED] writes: Sure, go ahead. I thought the wiki page to be sufficient but if you feel more comfortable with having it in JIRA, I'm all +1 for that. Best regards Henning Henning, I noticed you closed all the Macro-related JIRA issues. I see this as a usability barrier and something we should definitely address in a future version. In particular, the need to be able to #parse a file that includes macros is important. I'd like to reopen the issues. They serve as a reminder to address these issues for 1.6. But I don't want to get into a open/close/open/close fight. Any comments before I do this? (see http://blogs.codehaus.org/people/geir/archives/001414_somtimes_process_is_good_somtimes_not.html ) WILL -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Social behaviour: Bavarians can be extremely egalitarian and folksy. -- http://en.wikipedia.org/wiki/Bavaria Most Franconians do not like to be called Bavarians. -- http://en.wikipedia.org/wiki/Franconia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: macro issues
sounds reasonable. As long as we're okay with reopening issues. WILL On 11/6/06, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Will Glass-Husain [EMAIL PROTECTED] writes: Great, will do. A little more detail on when I think we should mark WONTFIX (lets discuss). I think it's nice to have enhancement requests/future thoughts in JIRA. The wont fix is rather offputting. There's a continuum for responses to enhancement requests.. -- committers really enthusiastic about idea; will certainly go in -- idea fits with philosophical direction of tool, might go in but not right now -- idea is from left field, will likely not go in I'd suggest we always leave the first two bullets as open issues. Helps capture usage details, example cases, mailing list threads. While I agree with that, I still say that we want to close issues at some point. And wontfix is IMHO a valid response. Issues falling in the middle category will always be subject to discussion anyway, so we can move these to the mailing list / Wiki. If we keep issues open indefinitely we will always have nn open issues for any given part of the system. Next to being bad press (and we all remember people showing up here and bean-counting open bugs, don't we?), they also tend to hide the real bug reports. I agree that we could resolve as Later. :-) Best regards Henning The third is a matter of judgement. Doesn't hurt to occasionally leave a creative idea open, but more often we should provide feedback and (if appropriate) ask the poster to move sample code to the wiki. A good rule of thumb should be that all active committers believe an idea is from left field in order to mark WONTFIX. Or at least that it's ok for a committer who's interested in immediate reopen the issue. Just my thoughts. Comments? WILL On 11/6/06, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Will Glass-Husain [EMAIL PROTECTED] writes: Sure, go ahead. I thought the wiki page to be sufficient but if you feel more comfortable with having it in JIRA, I'm all +1 for that. Best regards Henning Henning, I noticed you closed all the Macro-related JIRA issues. I see this as a usability barrier and something we should definitely address in a future version. In particular, the need to be able to #parse a file that includes macros is important. I'd like to reopen the issues. They serve as a reminder to address these issues for 1.6. But I don't want to get into a open/close/open/close fight. Any comments before I do this? (see http://blogs.codehaus.org/people/geir/archives/001414_somtimes_process_is_good_somtimes_not.html ) WILL -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Social behaviour: Bavarians can be extremely egalitarian and folksy. -- http://en.wikipedia.org/wiki/Bavaria Most Franconians do not like to be called Bavarians. -- http://en.wikipedia.org/wiki/Franconia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Social behaviour: Bavarians can be extremely egalitarian and folksy. -- http://en.wikipedia.org/wiki/Bavaria Most Franconians do not like to be called Bavarians. -- http://en.wikipedia.org/wiki/Franconia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: macro issues
We have a separate Resolved vs Closed category? Just checked - you're right. Seems unnecessarily onerous to me. Once the issue is done, it's done. Should be the same thing. WILL On 11/6/06, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Nathan Bubna [EMAIL PROTECTED] writes: +1 if and only if... Or at least that it's ok for a committer who's interested in immediate reopen the issue. this is the canonical process. close if you don't like it. if no committer re-opens, then that means no interest. this is more workable than seeking acks on a motion to close an issue. To be nit-picking: We are resolving the issue. Not closing it. :-) So they all will be touched one more time by closing resolved issues. Best regards Henning Just my thoughts. Comments? WILL On 11/6/06, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Will Glass-Husain [EMAIL PROTECTED] writes: Sure, go ahead. I thought the wiki page to be sufficient but if you feel more comfortable with having it in JIRA, I'm all +1 for that. Best regards Henning Henning, I noticed you closed all the Macro-related JIRA issues. I see this as a usability barrier and something we should definitely address in a future version. In particular, the need to be able to #parse a file that includes macros is important. I'd like to reopen the issues. They serve as a reminder to address these issues for 1.6. But I don't want to get into a open/close/open/close fight. Any comments before I do this? (see http://blogs.codehaus.org/people/geir/archives/001414_somtimes_process_is_good_somtimes_not.html ) WILL -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Social behaviour: Bavarians can be extremely egalitarian and folksy. -- http://en.wikipedia.org/wiki/Bavaria Most Franconians do not like to be called Bavarians. -- http://en.wikipedia.org/wiki/Franconia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - 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] -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person Open Source Consulting, Development, Design | Velocity - Turbine guy Save the cheerleader. Save the world. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-285) reference within macro and foreach is incorrect
[ http://issues.apache.org/jira/browse/VELOCITY-285?page=comments#action_12447568 ] Will Glass-Husain commented on VELOCITY-285: nice catch and nice fix! sometimes it takes an alert user to find a subtle use case that exposes a more general underlying problem. reference within macro and foreach is incorrect --- Key: VELOCITY-285 URL: http://issues.apache.org/jira/browse/VELOCITY-285 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.4 Environment: Operating System: other Platform: Other Reporter: Gilles Scokart Assigned To: Henning Schmiedehausen Priority: Minor Fix For: 1.5 It seems that there is a bug when we have loop into a recursive macro. Here is the test I run : #macro (test_loop $p) call to test_loop ($p) #foreach($child in $p) in the loop the param should not be changed : ($p) #test_loop($child) #end return #end #set($l1=[a]) #set($l = [$l1]) #test_loop($l) It produce: call to test_loop ([[a]]) in the loop the param should not be changed : ([[a]]) call to test_loop ([a]) in the loop the param should not be changed : (a) call to test_loop (a) return return return IMHO, it should be call to test_loop ([[a]]) in the loop the param should not be changed : ([[a]]) call to test_loop ([a]) in the loop the param should not be changed : ([a]) call to test_loop (a) return return return The difference is in the second recusive call. I don't know why, but it seems that the instruction #foreach($child in $p) has modified $p that contains the value of $child. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
the bug fix release
Just a quick comment. I'm looking at the subtle problems recently solved by Henning. I'd pushed a year ago to set a target of zero bugs remaining when we release Velocity 1.5, regardless of how long it took. I feel really good that we're going to essentially meet that goal. As we get close to release candidate, I note that we have 114 issues resolved and 11 left. The only ones pushed off are a couple of obscure escaping issues and the #parse of macros problem. When we release 1.5 we should highlight this improved stability. Support of our user base will be easier. And we'll be in good shape to add another round of incremental features for 1.6 knowing that the core is rock solid. WILL -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
beta 2 release - slight delay
Just as a FYI, I've a full schedule for a couple days. Since there seems to be a flurry of activity, I'm thinking of waiting until mid-week then cutting the release. We could branch right now of course, (or even branch from this past Saturday's revision) but I'm personally happy to take advantage of recent bug fixes in the beta2. WILL -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VELOCITY-436) Remove Exception type throwing.
[ http://issues.apache.org/jira/browse/VELOCITY-436?page=all ] Will Glass-Husain resolved VELOCITY-436. Resolution: Fixed removed generic Exception throwing from Template.merge, and in fact many methods (including all public Template methods). Remove Exception type throwing. - Key: VELOCITY-436 URL: http://issues.apache.org/jira/browse/VELOCITY-436 Project: Velocity Issue Type: Improvement Components: Source Environment: NA Reporter: Waldemar Baraldi Priority: Trivial I have to use Checkstyle coding standards at my job. Some methos of Velocity throw exceptions using the raw Exception type. So Checkstyle points an error everywhere I use Velocity and, unfortunately, that's a fact I cannot override in my source code. So it would be nice if those throws Exception are replaced by some Velocity proper exception. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r471381 - in
You might be right. It started as a small change but became more significant as I worked through it. Still, I think it's ok since we are taking away exceptions not adding them. WILL On 11/5/06, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] writes: I like that but it is still a bold change right before beta2. :-) I do expect heavy bleeding edge users like Malcolm to squeal if that breaks things. :-) Best regards Henning Author: wglass Date: Sun Nov 5 00:56:58 2006 New Revision: 471381 URL: http://svn.apache.org/viewvc?view=revrev=471381 Log: Removed generic Exception from throws for Template class and most Node classes. In response to VELOCITY-436. There's a danger of a change to an API call since this involves method signatures, but the only interface that seems relevant is Node.init (used when defining custom directives). Since we are removing Exception and adding TemplateInitException this seems to work. -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Social behaviour: Bavarians can be extremely egalitarian and folksy. -- http://en.wikipedia.org/wiki/Bavaria Most Franconians do not like to be called Bavarians. -- http://en.wikipedia.org/wiki/Franconia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VELOCITY-477) DOCTYPE url correction in veltag.tld
[ http://issues.apache.org/jira/browse/VELOCITY-477?page=all ] Will Glass-Husain resolved VELOCITY-477. Fix Version/s: 1.5 beta2 Resolution: Fixed fixed - thanks! I'm a little puzzled by this though. The spec shows library but I definitely found the lib version when googling around. WILL DOCTYPE url correction in veltag.tld Key: VELOCITY-477 URL: http://issues.apache.org/jira/browse/VELOCITY-477 Project: Velocity Issue Type: Bug Components: Engine Environment: All Reporter: Lee van der Veen Priority: Minor Fix For: 1.5 beta2 Attachments: patchfile.txt I noticed that the DOCTYPE declaration in experimantal/veltag/examples/veltag.tld uses http://java.sun.com/j2ee/dtds/web-jsptaglib_1_1.dtd; but should use http://java.sun.com/j2ee/dtds/web-jsptaglibrary_1_1.dtd;. Very little drama here, I know. But I figured I should point it out anyway. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Removed source component from JIRA
makes sense. in the middle of skimming through the JIRA notes from today with that as the sole change. WILL On 11/5/06, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Hi, I triaged all open issues in the source component, moved most of them to engine and then removed the source component from JIRA as it was really misleading (tools, DVSL etc also have source...). All resolved and closed issues from source went to engine because that is where most of them belonged anyway. Best regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Social behaviour: Bavarians can be extremely egalitarian and folksy. -- http://en.wikipedia.org/wiki/Bavaria Most Franconians do not like to be called Bavarians. -- http://en.wikipedia.org/wiki/Franconia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-392) Switch to a better log system - slf4j
[ http://issues.apache.org/jira/browse/VELOCITY-392?page=comments#action_12447367 ] Will Glass-Husain commented on VELOCITY-392: Makes sense. Obviously, you could always create a LogChute that acts as a bridge between Velocity and slf4j. Switch to a better log system - slf4j - Key: VELOCITY-392 URL: http://issues.apache.org/jira/browse/VELOCITY-392 Project: Velocity Issue Type: Improvement Components: Engine Affects Versions: 1.5 Environment: Operating System: All Platform: All Reporter: Jens Elkner Assigned To: Henning Schmiedehausen Priority: Minor Attachments: velocity.patch Since I'm still very unhappy with the current logging workaround in velocity, I removed the complete velocity logsystem stuff and replaced it with slf4j (see http://slf4j.org/manual.html ; http://slf4j.org/faq.html). So, the final thing is a little bit smaller and should be wrt. logging easier to use (i.e. no need for passing runtime svc handles back and forth just to be able to log something), much faster, safer and more precise and powerful than the old one... In case your are interested, I'll attach the patch made against the saturday evening svn repository. It basically contains the log changes as well as some code cleaning (i.e. remove/comment out unsed vars/methods, removed unneccessary casts as well as nested else clauses, removed throw XExceptions, which are actually not thrown). Finally I switched many log.info into log.debug, since the appropriate messages are important for developers only and should not irritate the enduser (who usually doesn't even understand that freak language ;-)). To get the thing running out of the box, I modified the buildfile to include log4j.properties in the jar, so that nlog4j aka log4j NG ;-) finds and uses it automatically, if one has not explictly configured it. And of course build/lib/log4j has been replaced with nlog4j (see http://www.slf4j.org/nlog4j/download.html) Regards, jens. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
macro issues
Henning, I noticed you closed all the Macro-related JIRA issues. I see this as a usability barrier and something we should definitely address in a future version. In particular, the need to be able to #parse a file that includes macros is important. I'd like to reopen the issues. They serve as a reminder to address these issues for 1.6. But I don't want to get into a open/close/open/close fight. Any comments before I do this? (see http://blogs.codehaus.org/people/geir/archives/001414_somtimes_process_is_good_somtimes_not.html ) WILL -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (VELOCITY-284) MethodInvocationException is handled inconsistently
[ http://issues.apache.org/jira/browse/VELOCITY-284?page=all ]
Will Glass-Husain reassigned VELOCITY-284:
--
Assignee: Will Glass-Husain
MethodInvocationException is handled inconsistently
---
Key: VELOCITY-284
URL: http://issues.apache.org/jira/browse/VELOCITY-284
Project: Velocity
Issue Type: Improvement
Components: Engine
Affects Versions: 1.4, 1.5
Environment: Operating System: All
Platform: Other
Reporter: Mike Rettig
Assigned To: Will Glass-Husain
Priority: Minor
Fix For: 2.0, 1.6
Attachments: swallowed_exception.txt
It appears that the exception handling is different depending on whether the
method is invoked as a passed parameter to a velocimacro or just in a
template.
Ex.
#doTextLink( ${myObj.exception})
${myObj.exception}
The first #doTextLink macro will throw an exception, but it will be logged and
ignored. However, the second invocation will throw the exception properly.
I have a patch that should fix this behavior. The exception just needs to be
rethrown up the call stack. A small signature change to a couple of methods.
Thanks,
Mike Rettig
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-227) ResourceFactory not extensible
[ http://issues.apache.org/jira/browse/VELOCITY-227?page=comments#action_12447368 ] Will Glass-Husain commented on VELOCITY-227: Since you can choose the implementation via velocity.properties, wouldn't this fall under a prohibited 'not-backwards-compatible' change? ResourceFactory not extensible -- Key: VELOCITY-227 URL: http://issues.apache.org/jira/browse/VELOCITY-227 Project: Velocity Issue Type: Improvement Components: Engine Affects Versions: 1.5 Environment: Operating System: All Platform: All Reporter: Charles Morehead Priority: Minor The class org.apache.velocity.runtime.resource.ResourceFactory provides no mechanism for allowing sub-classes of Template or ContentResources to be returned. Since ResourceManagerImpl makes a call to ResourceFactory.getResource(), the only way to override the behavior is to subclass ResourceManagerImpl and cut-paste-then-modify the code for loadResource(). At the very least, moving the ResourceFactory.getResource() call into a separate, protected method in ResourceManagerImpl would greatly simplify sub-classing Templates and/or ContentResources. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-183) StringResourceLoader
[
http://issues.apache.org/jira/browse/VELOCITY-183?page=comments#action_12447369
]
Will Glass-Husain commented on VELOCITY-183:
I've changed my mind about this. It should go into the core. Eventually we
need to re-do most of the unit tests to remove file system dependencies and
this would be really quite useful.
StringResourceLoader
Key: VELOCITY-183
URL: http://issues.apache.org/jira/browse/VELOCITY-183
Project: Velocity
Issue Type: Improvement
Components: Engine
Affects Versions: 1.3.1
Environment: Operating System: other
Platform: Other
Reporter: Eelco Hillenius
Priority: Minor
Fix For: 1.5
Attachments: StringResource.java, StringResourceException.java,
StringResourceLoader.java, StringResourceRepository.java,
StringResourceRepositoryFactory.java, StringResourceRepositoryImpl.java
Resource loader that works with Strings. Users should manualy add
resources to the repository that is know by the factory of this package.
Below is an example configuration for this loader.
Note that 'repositoryimpl' is not mandatory;
if not provided, the factory will fall back on using the default
implementation of this package.
stringres.resource.loader.description = Velocity StringResource loader
stringres.resource.loader.class =
org.apache.velocity.tools.stringresources.StringResourceLoader
stringres.resource.loader.repositoryimpl =
org.apache.velocity.tools.stringresources.StringResourceRepositoryImpl
Resources can be added to the repository like this:
StringResourceRepositoryFactory vsRepository = null;
vsRepository = StringResourceRepositoryFactory.getRepository();
String myTemplateName = /somewhere/intherepo/name;
String myTemplateBody = Hi, ${username}... this is a some template!;
vsRepository.putStringResource(myTemplateName, myTemplateBody);
After this, the templates can be retrieved as usual
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
back to double digits!
I was so excited last night that the JIRA issues for 1.5 were down to single digits... now Henning has put them back up to 15. I'd argue we should move all the new features back to 1.6 if they aren't in good shape or with appropriate legal permissions in the near future. WILL -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-24) calls to local macros not always made when template caching is off
[ http://issues.apache.org/jira/browse/VELOCITY-24?page=comments#action_12447184 ] Will Glass-Husain commented on VELOCITY-24: --- So, it cuts the speed in half for uncached operation? Seems acceptable to me, since we offer a pretty good cache. Nice work on tracking this down and solving it. calls to local macros not always made when template caching is off -- Key: VELOCITY-24 URL: http://issues.apache.org/jira/browse/VELOCITY-24 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.5 beta1 Environment: Operating System: other Platform: Other Reporter: peterwlynch Assigned To: Henning Schmiedehausen Priority: Blocker Fix For: 1.5 In the latest nightly build Oct 28, 2001 and also in velocity 1.2 rc2 i noticed the following problem with autoreloading macros. Made a simple html page. added a simple one line macro that accepted one param, a letter something like ## local macro, not global #macro(letter $char) This is the letter $char #end #letter(A) #letter(B) #letter(C) etc to Z -- The html page would be loaded in response to a form being submitted. If I clicked on the submit button five times, quickly ( five separate submits), most times the final response would out put something like... This is the letter A This is the letter B This is the letter C This is the letter D This is the letter E #letter#letter#letter #letter .. This is the letter Z As you can see, some macro calls did not get parsed. We were just happening to use velocity through turbine, but I don't think that affects the bug. Besides, the bug went away when the autoreload was false. Once scarab's runbox is back up, might be interesting to test this out on their macros too for comparison, although I don't see that they have any local macros. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (VELOCITY-435) ParseErrorException not thrown with #macro parse error
[ http://issues.apache.org/jira/browse/VELOCITY-435?page=all ] Will Glass-Husain reassigned VELOCITY-435: -- Assignee: Will Glass-Husain ParseErrorException not thrown with #macro parse error -- Key: VELOCITY-435 URL: http://issues.apache.org/jira/browse/VELOCITY-435 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.5 Environment: Windows XP, JDK 1.4.2_09 Reporter: Malcolm Edgar Assigned To: Will Glass-Husain Fix For: 1.5 Attachments: macroargumenterror.patch I have just been reviewing the new error handlingin Velocity 1.5-dev. One change I have observed it that an invalid macro call, passing 2 arguments instead of one will log an error message: [Velocity] [error] VM #writeForm: error : too many arguments to macro. Wanted 1 got 2 [Velocity] [error] VM error writeForm. Null AST However it will not throw an ParseErrorException like it used to in 1.5-dev. Please see the example below for the earlier behaviour: http://www.sunvolt.com/click-examples/exception.htm?actionLink=brokenBorderLink# I prefer earlier approach, as the error is explicit. The new approach logs an error message, but beyond that you would not have known that an error occured. The #writeForm() call is not even rendered, as is done with an invalid object reference. regards Malcolm Edgar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VELOCITY-435) ParseErrorException not thrown with #macro parse error
[ http://issues.apache.org/jira/browse/VELOCITY-435?page=all ] Will Glass-Husain resolved VELOCITY-435. Resolution: Fixed Fix applied. Need to set property velocimacro.arguments.strict to true for the exception to be thrown. Thanks for the idea, Malcom! ParseErrorException not thrown with #macro parse error -- Key: VELOCITY-435 URL: http://issues.apache.org/jira/browse/VELOCITY-435 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.5 Environment: Windows XP, JDK 1.4.2_09 Reporter: Malcolm Edgar Assigned To: Will Glass-Husain Fix For: 1.5 Attachments: macroargumenterror.patch I have just been reviewing the new error handlingin Velocity 1.5-dev. One change I have observed it that an invalid macro call, passing 2 arguments instead of one will log an error message: [Velocity] [error] VM #writeForm: error : too many arguments to macro. Wanted 1 got 2 [Velocity] [error] VM error writeForm. Null AST However it will not throw an ParseErrorException like it used to in 1.5-dev. Please see the example below for the earlier behaviour: http://www.sunvolt.com/click-examples/exception.htm?actionLink=brokenBorderLink# I prefer earlier approach, as the error is explicit. The new approach logs an error message, but beyond that you would not have known that an error occured. The #writeForm() call is not even rendered, as is done with an invalid object reference. regards Malcolm Edgar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-413) Add Velocity 1.5 jar to DVSL
[ http://issues.apache.org/jira/browse/VELOCITY-413?page=all ] Will Glass-Husain updated VELOCITY-413: --- Summary: Add Velocity 1.5 jar to DVSL (was: DVSL doesn't appear to work with Velocity 1.5) Fix Version/s: (was: 1.5) Add Velocity 1.5 jar to DVSL Key: VELOCITY-413 URL: http://issues.apache.org/jira/browse/VELOCITY-413 Project: Velocity Issue Type: Bug Components: DVSL, Source Affects Versions: 1.5 Environment: WinXP Pro Reporter: Nathan Bubna I tried to generate the docs for VelocityTools (which are generated via DVSL) using a recent build of Velocity-1.5-dev, and the files DVSL generated were empty. No error messages were sent to std out and Ant considered the build successful. Also, DVSL only appears to work with older versions of Dom4j (such as 1.1). If used with Dom4j 1.6.1, then NoClassDefFoundErrors pop up. It might be good to upgrade DVSL, if possible. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
synchronization of Template class
Henning-- Since you just dug into the synchronization issue, do you have any thoughts on http://issues.apache.org/jira/browse/VELOCITY-383 ? WILL -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: POLL - release beta 2?
We've a go-ahead to release Velocity 1.5 beta 2. I haven't cast an official vote yet, but mine is obviously +1. +1 Malcolm Edgar Matthijs Lambooy Nathan Bubna Henning P. Schmiedehausen Will Glass-Husain I'll go ahead and get things started. I'd like to put a link to it on the home page this time. best, WILL On 11/1/06, Will Glass-Husain [EMAIL PROTECTED] wrote: Hi, I think we should release a beta 2 version of Velocity allowing users to test out the recent spurt of bug fixes and improvements. You can see a report on improvements made during the recent Hackathon at these links: http://www.mail-archive.com/velocity-dev@jakarta.apache.org/msg15131.html http://wiki.apache.org/jakarta-velocity/HackaThon2006 Opinions? [ ] +1 Let's do Beta Two [ ] 0 I don't care. [ ] -1 No go I'll collect votes till Saturday. WILL -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r470900 - /jakarta/velocity/tools/trunk/examples/struts/WEB-INF/src/examples/app4/MyTileController.java
What's up with this? Shouldn't that have been expanded?
+ * $Id$
WILL
On 11/3/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: henning
Date: Fri Nov 3 08:52:38 2006
New Revision: 470900
URL: http://svn.apache.org/viewvc?view=revrev=470900
Log:
move iso umlauts - utf-8, silencing the Java 1.5 compiler
Modified:
jakarta/velocity/tools/trunk/examples/struts/WEB-INF/src/examples/app4/MyTileController.java
Modified:
jakarta/velocity/tools/trunk/examples/struts/WEB-INF/src/examples/app4/MyTileController.java
URL:
http://svn.apache.org/viewvc/jakarta/velocity/tools/trunk/examples/struts/WEB-INF/src/examples/app4/MyTileController.java?view=diffrev=470900r1=470899r2=470900
==
---
jakarta/velocity/tools/trunk/examples/struts/WEB-INF/src/examples/app4/MyTileController.java
(original)
+++
jakarta/velocity/tools/trunk/examples/struts/WEB-INF/src/examples/app4/MyTileController.java
Fri Nov 3 08:52:38 2006
@@ -13,7 +13,7 @@
* See the License for the specific language governing permissions and
* limitations under the License.
*
- * $Id: MyTileController.java,v 1.3 2004/03/12 19:41:06 marino Exp $
+ * $Id$
*/
package examples.app4;
@@ -30,8 +30,8 @@
* pA simple tile-controller that puts a string into the request scope.
* Check out the tiles-defs to see the definition that uses the
controller/p
*
- * @author a href=mailto:[EMAIL PROTECTED]/Marinó A. Jónsson/a
- * @version $Id: MyTileController.java,v 1.3 2004/03/12 19:41:06 marino Exp $
+ * @author a href=mailto:[EMAIL PROTECTED]/Marinó A. Jónsson/a
+ * @version $Id$
*/
public class MyTileController extends ControllerSupport {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Forio Business Simulations
Will Glass-Husain
[EMAIL PROTECTED]
www.forio.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-413) DVSL doesn't appear to work with Velocity 1.5
[ http://issues.apache.org/jira/browse/VELOCITY-413?page=comments#action_12446747 ] Will Glass-Husain commented on VELOCITY-413: Well that's good to know. Bug mysteriously appears, bug goes away. Does this mean this issue is no longer required to be resolved for Velocity 1.5? (e.g. it becomes a separate DVSL related issue)? DVSL doesn't appear to work with Velocity 1.5 - Key: VELOCITY-413 URL: http://issues.apache.org/jira/browse/VELOCITY-413 Project: Velocity Issue Type: Bug Components: DVSL, Source Affects Versions: 1.5 Environment: WinXP Pro Reporter: Nathan Bubna Fix For: 1.5 I tried to generate the docs for VelocityTools (which are generated via DVSL) using a recent build of Velocity-1.5-dev, and the files DVSL generated were empty. No error messages were sent to std out and Ant considered the build successful. Also, DVSL only appears to work with older versions of Dom4j (such as 1.1). If used with Dom4j 1.6.1, then NoClassDefFoundErrors pop up. It might be good to upgrade DVSL, if possible. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Javadoc issues
Thanks, That's what happens when you keep tinkering with the code before committing. Anyone suggest a good plugin (or setting) in Eclipse to catch these javadoc issues ahead of time? On a separate topic, I was going to write an email about beta2. Shall we call for a vote soon? What else do we want to fix before then? (be nice to highlight this when we launch the TLP site). WILL On 11/1/06, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Hi, excuse me for being anal but while starting to think about preparing beta2, I noticed that we introduced quite a number of problems in the javadocs. (Nathan: As you were asking whether the large amount of formal javadoc fixes had any real impact: Yes. Due to these fixes, it was now easy to spot that the number of problems went up. That wasn't possible when the number to start with was already very large because then the real issues would have been lost in the noise.) I've reopened VELOCITY-423 and opened VELOCITY-475 to deal with these problems (Will, I'm afraid that will be mostly work for you...) Best regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Social behaviour: Bavarians can be extremely egalitarian and folksy. -- http://en.wikipedia.org/wiki/Bavaria Most Franconians do not like to be called Bavarians. -- http://en.wikipedia.org/wiki/Franconia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
POLL - release beta 2?
Hi, I think we should release a beta 2 version of Velocity allowing users to test out the recent spurt of bug fixes and improvements. You can see a report on improvements made during the recent Hackathon at these links: http://www.mail-archive.com/velocity-dev@jakarta.apache.org/msg15131.html http://wiki.apache.org/jakarta-velocity/HackaThon2006 Opinions? [ ] +1 Let's do Beta Two [ ] 0 I don't care. [ ] -1 No go I'll collect votes till Saturday. WILL - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Javadoc issues
Incidentally, (in case anyone else is interested). It turns out there's a setting in Eclipse under Compiler/Javadoc that flags a warning for every Javadoc problem. You can set this by project so that your code without the rigid Velocity style scrutiny can stay in more relaxed form. WILL v^- On 11/1/06, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Hi, excuse me for being anal but while starting to think about preparing beta2, I noticed that we introduced quite a number of problems in the javadocs. (Nathan: As you were asking whether the large amount of formal javadoc fixes had any real impact: Yes. Due to these fixes, it was now easy to spot that the number of problems went up. That wasn't possible when the number to start with was already very large because then the real issues would have been lost in the noise.) I've reopened VELOCITY-423 and opened VELOCITY-475 to deal with these problems (Will, I'm afraid that will be mostly work for you...) Best regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Social behaviour: Bavarians can be extremely egalitarian and folksy. -- http://en.wikipedia.org/wiki/Bavaria Most Franconians do not like to be called Bavarians. -- http://en.wikipedia.org/wiki/Franconia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VELOCITY-475) Javadocs for SecureUberspector are not correct.
[ http://issues.apache.org/jira/browse/VELOCITY-475?page=all ] Will Glass-Husain resolved VELOCITY-475. Resolution: Fixed fixed Javadocs for SecureUberspector are not correct. --- Key: VELOCITY-475 URL: http://issues.apache.org/jira/browse/VELOCITY-475 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.5 beta1 Reporter: Henning Schmiedehausen Priority: Trivial Fix For: 1.5 [javadoc] /home/scratch/velocity/engine/bin/src/org/apache/velocity/util/introspection/SecureIntrospectorControl.java:39: warning - @param argument o is not a parameter name. has been introduced by the latest patch to include the SecureUberspector. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VELOCITY-423) Report invalid references
[ http://issues.apache.org/jira/browse/VELOCITY-423?page=all ] Will Glass-Husain resolved VELOCITY-423. Resolution: Fixed excellent point. cleaned them all up. Report invalid references - Key: VELOCITY-423 URL: http://issues.apache.org/jira/browse/VELOCITY-423 Project: Velocity Issue Type: New Feature Components: Source Reporter: Will Glass-Husain Assigned To: Will Glass-Husain Fix For: 1.5 Attachments: invalidreference.txt I've made a new patch that includes a ReferenceInsertionEventHandler (InvalidReferenceHandler) that collects a list of all invalid references in a Velocity page. To see how it works, look at the test code (the last two methods) in BuiltInEventHandlerTestCase. To make this work, I had to make some changes to the internals. So I thought I'd hold off a couple days before committing, let any interested parties comment. There's a couple of interesting new pieces for plugin writers. (1) In any user-defined plugin (event handlers, uberspectors, etc) you can now throw a subclass of VelocityRuntimeException (new exception). to signal unrecoverable states to the calling application. This runtime exception requires no change to the interface signature and is passed through the Velocity parsing process. (In the past, all Exceptions were caught and logged). Example use: a custom uberspector or event handler that wishes to stop page processing. For example, the InvalidReferenceHandler can be configured to throw an exception at the first reference error. (2) Event handlers can now receive information on the template name, line number, and column by implementing InfoAware. This only works for Local event handlers attached to a context (as opposed to the new Global type defined in Velocity properties). Example use: InvalidReferenceHandler reports out the line,column, and template name of each reference error. Everything is completely backwards compatible. It'd be simpler if it wasn't of course as they we could just redo the interfaces. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELTOOLS-66) Velocity Tools gives access exception with $request reference under Tomcat security manager
[
http://issues.apache.org/jira/browse/VELTOOLS-66?page=comments#action_12445511
]
Will Glass-Husain commented on VELTOOLS-66:
---
This would be interesting to try. There's been zero response to my bug report
in Tomcat-land.
Velocity Tools gives access exception with $request reference under Tomcat
security manager
---
Key: VELTOOLS-66
URL: http://issues.apache.org/jira/browse/VELTOOLS-66
Project: VelocityTools
Issue Type: New Feature
Components: VelocityView
Affects Versions: 1.2
Reporter: Will Glass-Husain
I'm labeling this as a bug, though it's arguable whether the fault is of
Tomcat or Velocity. Regardless, we should apply a workaround. I've
replicated this issue with Velocity 1.4 / Tools 1.2 / JDK 1.5 / Tomcat 5.5
The problem. When the Tomcat is run under the default security manager
settings, it prohibits reflection on org.catalina classes. This means that
the reference $request.session.id fails with an access violation
INFO: Velocity [error] PROGRAMMER ERROR : PropertyExector() :
java.security.AccessControlException: access denied
(java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina.connector)
sometimes the package given is org.apache.catalina.core, somtimes
org.apache.catalina.session, depending on various factors.
Users can alter their security policy to allow this access. But this is an
obscure procedure and may not be feasible if you do not control your hosting
environment. For the record, the settings for catalina.policy are (change
the path to suit your webapp)
grant codeBase
file:${catalina.home}/webapps/simple/WEB-INF/lib/velocity-1.4.jar
{
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina.connector;
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina.session;
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina.core;
};
grant codeBase
file:${catalina.home}/webapps/simple/WEB-INF/lib/velocity-tools-view-1.2.jar
{
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina.connector;
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina.session;
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina.core;
};
As an alternative, I propose that the Velocity Tools project solve this by
create a wrapper object for HttpServletRequest. (presumably the problem also
exists for $response, though I haven't tried it). This object would simply
pass through all calls to the server-provided HttpServletRequest. Obviously,
there would need to be a parallel wrapper for HttpSession,
HttpServletContext, and similar objects available from HttpServletRequest
methods. The result would be that the Velocity page would never apply
reflection to a Catalina class. (and hence never generate this security
error).
This issue is in reference to a problem encountered and described on the user
list by Robin Mannering.
http://www.mail-archive.com/velocity-user@jakarta.apache.org/msg17060.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VELOCITY-469) Spaces in velocimacro.library hard to troubleshoot
[ http://issues.apache.org/jira/browse/VELOCITY-469?page=all ]
Will Glass-Husain resolved VELOCITY-469.
Fix Version/s: 1.5
Resolution: Duplicate
Fixed in upcoming version 1.5. See VELOCITY-274.
Spaces in velocimacro.library hard to troubleshoot
--
Key: VELOCITY-469
URL: http://issues.apache.org/jira/browse/VELOCITY-469
Project: Velocity
Issue Type: Bug
Components: Engine
Affects Versions: 1.4
Environment: N/A
Reporter: Petter Måhlén
Priority: Minor
Fix For: 1.5
With the following velocity.properties file (note the spaces after
'TypeConversions.vm'):
-
resource.loader = classpath
# this configuration allows you to supply template files somewhere on the
classpath
classpath.resource.loader.description = Velocity Classpath Resource Loader
classpath.resource.loader.class =
org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader
velocimacro.library=TypeConversions.vm
-
One gets the following log entries:
Fri Oct 27 10:42:39 CEST 2006 [info] Velocimacro : adding VMs from VM
library template : TypeConversions.vm
Fri Oct 27 10:42:39 CEST 2006 [error] ResourceManager : unable to find
resource 'TypeConversions.vm ' in any resource loader.
Fri Oct 27 10:42:39 CEST 2006 [info] Velocimacro : error using VM library
template TypeConversions.vm :
org.apache.velocity.exception.ResourceNotFoundException: Unable to find
resource 'TypeConversions.vm '
It took me a few hours to notice that there were spaces after the '.vm' - it
would maybe be better to add a trim() to
VelocimacroFactory.initVelocimacro(), about line 164:
if (lib != null !lib.equals())
{
/*
* let the VMManager know that the following is
coming
* from libraries - need to know for auto-load
*/
lib = lib.trim(); // NEW
vmManager.setRegisterFromLib( true );
logVMMessageInfo(Velocimacro : adding VMs from +
VM library template : + lib );
---
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Velocity goes TLP
Thanks for the announcement. Congrats to all of us! And to Henning, our new PMC Chair. We should come up with a migration 'todo' list, maybe on the Wiki. WILL On 10/26/06, Henning Schmiedehausen [EMAIL PROTECTED] wrote: Hi, the Board has passed the resolution to turn the Velocity project into Apache Velocity, i.e. we are leaving the Jakarta Umbrella to become a TLP in our own right. The transition to velocity.apache.org will take a while until all the infrastructure needs are in place, please be patient with us while the dust settles. Thanks to all that helped making this move possibly, especially Nathan who drafted the resolution. Best regards Henning (just appointed Apache Velocity chair. :-) ) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Velocity 1.5 Cayenne compatablity
Fabulous. We're closing in little by little. Thanks for checking this. WILL On 10/26/06, Malcolm Edgar [EMAIL PROTECTED] wrote: Hi All, Just reporting in that I have observed no computability problems with the latest Velocity 1.5-dev build (SVN revision 467179) and Cayenne (1.2.1). For the Cayenne community, Velocity 1.5 is working up to a RC build. regards Malcolm Edgar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-468) Allowing putting objects into control context from VTL
[ http://issues.apache.org/jira/browse/VELOCITY-468?page=all ] Will Glass-Husain updated VELOCITY-468: --- Fix Version/s: 1.6 Just trying to figure out, why is this needed? (1) You can create your own context and pass it in to the parse (String inputTemplate, String outputFile) method or (2) You can fill the context with a hashtable. fillContextHash (Context context, Hashtable objs) (yes, this really should be a Map -- it's old code). WILL Allowing putting objects into control context from VTL -- Key: VELOCITY-468 URL: http://issues.apache.org/jira/browse/VELOCITY-468 Project: Velocity Issue Type: Improvement Components: Texen Affects Versions: 1.4 Reporter: Mojmir Hanes Priority: Minor Fix For: 1.6 Attachments: Generator.java.diff I think it would be nice to allow putting objects into control context in VTL. The motivation is straightforward - in some cases you need to put more than one object into context before parsing particular template, so method org.apache.velocity.texen.parse(String inputTemplate, String outputFile, String objectID,Object object) doesn't match your need. What do you think ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-468) Allowing putting objects into control context from VTL
[ http://issues.apache.org/jira/browse/VELOCITY-468?page=comments#action_12444050 ] Will Glass-Husain commented on VELOCITY-468: Hi, I'm not a big texen user, so, could you explain wouldn't this work? You could subclass Generator and call getContext. Or just do the following in calling code. Context context = new VelocityContext(); context.put(a,zz); context.put(b,zz); context.put(c,zz); generator.parse(template1.vm,context); generator.parse(template2.vm,context); generator.parse(template3.vm,context); Allowing putting objects into control context from VTL -- Key: VELOCITY-468 URL: http://issues.apache.org/jira/browse/VELOCITY-468 Project: Velocity Issue Type: Improvement Components: Texen Affects Versions: 1.4 Reporter: Mojmir Hanes Priority: Minor Fix For: 1.6 Attachments: Generator.java.diff I think it would be nice to allow putting objects into control context in VTL. The motivation is straightforward - in some cases you need to put more than one object into context before parsing particular template, so method org.apache.velocity.texen.parse(String inputTemplate, String outputFile, String objectID,Object object) doesn't match your need. What do you think ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELTOOLS-66) Velocity Tools gives access exception with $request reference under Tomcat security manager
[
http://issues.apache.org/jira/browse/VELTOOLS-66?page=comments#action_12442670
]
Will Glass-Husain commented on VELTOOLS-66:
---
submitted bug to Tomcat bugzilla
http://issues.apache.org/bugzilla/show_bug.cgi?id=40770
Velocity Tools gives access exception with $request reference under Tomcat
security manager
---
Key: VELTOOLS-66
URL: http://issues.apache.org/jira/browse/VELTOOLS-66
Project: VelocityTools
Issue Type: New Feature
Components: VelocityView
Affects Versions: 1.2
Reporter: Will Glass-Husain
I'm labeling this as a bug, though it's arguable whether the fault is of
Tomcat or Velocity. Regardless, we should apply a workaround. I've
replicated this issue with Velocity 1.4 / Tools 1.2 / JDK 1.5 / Tomcat 5.5
The problem. When the Tomcat is run under the default security manager
settings, it prohibits reflection on org.catalina classes. This means that
the reference $request.session.id fails with an access violation
INFO: Velocity [error] PROGRAMMER ERROR : PropertyExector() :
java.security.AccessControlException: access denied
(java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina.connector)
sometimes the package given is org.apache.catalina.core, somtimes
org.apache.catalina.session, depending on various factors.
Users can alter their security policy to allow this access. But this is an
obscure procedure and may not be feasible if you do not control your hosting
environment. For the record, the settings for catalina.policy are (change
the path to suit your webapp)
grant codeBase
file:${catalina.home}/webapps/simple/WEB-INF/lib/velocity-1.4.jar
{
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina.connector;
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina.session;
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina.core;
};
grant codeBase
file:${catalina.home}/webapps/simple/WEB-INF/lib/velocity-tools-view-1.2.jar
{
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina.connector;
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina.session;
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina.core;
};
As an alternative, I propose that the Velocity Tools project solve this by
create a wrapper object for HttpServletRequest. (presumably the problem also
exists for $response, though I haven't tried it). This object would simply
pass through all calls to the server-provided HttpServletRequest. Obviously,
there would need to be a parallel wrapper for HttpSession,
HttpServletContext, and similar objects available from HttpServletRequest
methods. The result would be that the Velocity page would never apply
reflection to a Catalina class. (and hence never generate this security
error).
This issue is in reference to a problem encountered and described on the user
list by Robin Mannering.
http://www.mail-archive.com/velocity-user@jakarta.apache.org/msg17060.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (VELTOOLS-66) Velocity Tools gives access exception with $request reference under Tomcat security manager
Velocity Tools gives access exception with $request reference under Tomcat
security manager
---
Key: VELTOOLS-66
URL: http://issues.apache.org/jira/browse/VELTOOLS-66
Project: VelocityTools
Issue Type: Bug
Components: VelocityView
Affects Versions: 1.2
Reporter: Will Glass-Husain
I'm labeling this as a bug, though it's arguable whether the fault is of Tomcat
or Velocity. Regardless, we should apply a workaround. I've replicated this
issue with Velocity 1.4 / Tools 1.2 / JDK 1.5 / Tomcat 5.5
The problem. When the Tomcat is run under the default security manager
settings, it prohibits reflection on org.catalina classes. This means that the
reference $request.session.id fails with an access violation
INFO: Velocity [error] PROGRAMMER ERROR : PropertyExector() :
java.security.AccessControlException: access denied
(java.lang.RuntimePermission accessClassInPackage.org.apache.catalina.connector)
sometimes the package given is org.apache.catalina.core, somtimes
org.apache.catalina.session, depending on various factors.
Users can alter their security policy to allow this access. But this is an
obscure procedure and may not be feasible if you do not control your hosting
environment. For the record, the settings for catalina.policy are (change the
path to suit your webapp)
grant codeBase
file:${catalina.home}/webapps/simple/WEB-INF/lib/velocity-1.4.jar
{
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina.connector;
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina.session;
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina.core;
};
grant codeBase
file:${catalina.home}/webapps/simple/WEB-INF/lib/velocity-tools-view-1.2.jar
{
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina.connector;
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina.session;
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina.core;
};
As an alternative, I propose that the Velocity Tools project solve this by
create a wrapper object for HttpServletRequest. (presumably the problem also
exists for $response, though I haven't tried it). This object would simply
pass through all calls to the server-provided HttpServletRequest. Obviously,
there would need to be a parallel wrapper for HttpSession, HttpServletContext,
and similar objects available from HttpServletRequest methods. The result
would be that the Velocity page would never apply reflection to a Catalina
class. (and hence never generate this security error).
This issue is in reference to a problem encountered and described on the user
list by Robin Mannering.
http://www.mail-archive.com/velocity-user@jakarta.apache.org/msg17060.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (VELOCITY-467) Throw more exceptions and log less errors
Throw more exceptions and log less errors - Key: VELOCITY-467 URL: http://issues.apache.org/jira/browse/VELOCITY-467 Project: Velocity Issue Type: Improvement Components: Source Affects Versions: 1.5 beta1 Reporter: Will Glass-Husain Priority: Minor Now that Velocity application exceptions are based on RuntimeException, we have more opportunity to use exceptions to signal application level problems. I'm particularly concerned about initialization problems that are logged and may be missed. We need to review all logged error messages and see if it would be more appropriate to throw an exception instead. Some of these places we may need to leave as is for backwards compatibility reasons. (e.g. macro in the global macro library doesn't parse properly). Llewellyn Falco made a good case for this on the dev list recently: http://www.mail-archive.com/velocity-dev@jakarta.apache.org/msg15067.html # I still would like to put in my vote that sending error's to the log is an incredibly BAD idea. If something is not working, it should be LOUDLY shown as an exception. If it is working I don't really need a log. The (velocity) log should be there for velocity developers (those programming the actual velocity code) not users. I don't ever care to see tomcat's log, I care to see the things I log while in tomcat. Most of all, many many many people do not check the log at all, let alone frequently. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
report on Velocity Hackathon 2006
Hi, Just a quick report on Hackathon 2006 for Velocity. As you can see from the wiki page (http://wiki.apache.org/jakarta-velocity/HackaThon2006) we put a significant dent in the list of open issues. I'm particularly pleased to have gotten some new functionality committed: my (in)famous secure uberspector which prevents dangerous classloader related methods from being called (when configured), and a new event handler that will report out all invalid references in a page. We also nailed some subtle bugs in the uberspector and macros, boldly changed the application-level exceptions to be subclasses of runtime exception, and got rid of the infamous velocity.log file except when explicitly configured. Nathan fixed up the StandardOutLog system to be a bit more consistent about stdout vs. stderr. Also worth mentioning is a nasty little SQL injection vulnerability in the DatasourceResourceLoader that Henning fixed a couple of weeks ago. I had a chance to take a look at the work that Henning is doing on the documentation. I really hadn't appreciated how revolutionary this is. He's single-handedly converting all our xdocs for the software into a new DocBook format. (not the site-- that stays xdocs). DocBook is an industry standard, has a free WYSIWYG editor, and is stored in XML format. Henning gave a well-regard lightening talk at ApacheCon advocating all projects follow the same approach. What's next? I'd like to see a beta 2 capturing these new items released ASAP. Then there's more bugs to fix, and the new docs to finish. We'll see how it goes. As a sidenote, it was a treat to work on these issues surrounded by other committers on the many ASF projects which use Velocity. Good feedback and enthusiasm all around. The word is out about the move to TLP and people approve of our new momentum. Henning and I attended an excellent session run by Sally Khudari on Promoting your Open Source Project. When the time comes to announce a new release, I think we should try to make a splash. best, WILL - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VELOCITY-457) documentation mistake? order of Velocimacros in template
[ http://issues.apache.org/jira/browse/VELOCITY-457?page=all ] Will Glass-Husain resolved VELOCITY-457. Resolution: Invalid it has to do with caching. The macro is never loaded the first time, but if the page is cached will be available the second time the page is rendered. documentation mistake? order of Velocimacros in template Key: VELOCITY-457 URL: http://issues.apache.org/jira/browse/VELOCITY-457 Project: Velocity Issue Type: Bug Components: Documentation Affects Versions: 1.4 Reporter: Will Glass-Husain Priority: Minor Fix For: 1.5 from mailing list. (need to confirm) -- Forwarded message -- From: sun davy [EMAIL PROTECTED] Date: Sep 11, 2006 3:51 AM Subject: i encounter some mistakes in User Guide. To: velocity-user@jakarta.apache.org hi Velocity team: I am an user of Velocity from China. Thanks for your perfect production. Through your creative and hard work, we have such Convenience and Powerful tools in our toolbox. ... 3) Velocimacro Trivia Currently, Velocimacros must be defined before they are first used in a template. This means that your #macro() declarations should come before using the Velocimacros. i defined VM after they are first used in a template, it also work. i don't know why. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELTOOLS-66) Velocity Tools gives access exception with $request reference under Tomcat security manager
[
http://issues.apache.org/jira/browse/VELTOOLS-66?page=comments#action_12442456
]
Will Glass-Husain commented on VELTOOLS-66:
---
Nathan, you make some good points.
Though I'm not a Tools user, I don't mind making a patch for if you think it
would be appropriate. But I'll hold off for the moment. Let me try posting an
issue on the Tomcat site, see if there's any interest in handling this over
there.
If there does not seem to be progress at Tomcat I'd like to push again to just
handle it on our side. I've struggled with webapps on Tomcat with security
policies -- undocumented permission needs (which are frequent in Tomcat and
libraries) are very frustrating.Velocity is confusing enough to new users
without having an incomprehensible error that occurs in VelocityViewServlet but
not JSP.
Can we leave the issue open for the time being?
Velocity Tools gives access exception with $request reference under Tomcat
security manager
---
Key: VELTOOLS-66
URL: http://issues.apache.org/jira/browse/VELTOOLS-66
Project: VelocityTools
Issue Type: New Feature
Components: VelocityView
Affects Versions: 1.2
Reporter: Will Glass-Husain
I'm labeling this as a bug, though it's arguable whether the fault is of
Tomcat or Velocity. Regardless, we should apply a workaround. I've
replicated this issue with Velocity 1.4 / Tools 1.2 / JDK 1.5 / Tomcat 5.5
The problem. When the Tomcat is run under the default security manager
settings, it prohibits reflection on org.catalina classes. This means that
the reference $request.session.id fails with an access violation
INFO: Velocity [error] PROGRAMMER ERROR : PropertyExector() :
java.security.AccessControlException: access denied
(java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina.connector)
sometimes the package given is org.apache.catalina.core, somtimes
org.apache.catalina.session, depending on various factors.
Users can alter their security policy to allow this access. But this is an
obscure procedure and may not be feasible if you do not control your hosting
environment. For the record, the settings for catalina.policy are (change
the path to suit your webapp)
grant codeBase
file:${catalina.home}/webapps/simple/WEB-INF/lib/velocity-1.4.jar
{
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina.connector;
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina.session;
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina.core;
};
grant codeBase
file:${catalina.home}/webapps/simple/WEB-INF/lib/velocity-tools-view-1.2.jar
{
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina.connector;
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina.session;
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.catalina.core;
};
As an alternative, I propose that the Velocity Tools project solve this by
create a wrapper object for HttpServletRequest. (presumably the problem also
exists for $response, though I haven't tried it). This object would simply
pass through all calls to the server-provided HttpServletRequest. Obviously,
there would need to be a parallel wrapper for HttpSession,
HttpServletContext, and similar objects available from HttpServletRequest
methods. The result would be that the Velocity page would never apply
reflection to a Catalina class. (and hence never generate this security
error).
This issue is in reference to a problem encountered and described on the user
list by Robin Mannering.
http://www.mail-archive.com/velocity-user@jakarta.apache.org/msg17060.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VELOCITY-423) Report invalid references
[ http://issues.apache.org/jira/browse/VELOCITY-423?page=all ] Will Glass-Husain resolved VELOCITY-423. Resolution: Fixed I've added a new event handler InvalidReferenceEventHandler to address this. It's a little experimental -- may need some tweaking, but should be quite useful. Going to resolve this issue in the meantime. Please feel free to ask questions on the lists. Report invalid references - Key: VELOCITY-423 URL: http://issues.apache.org/jira/browse/VELOCITY-423 Project: Velocity Issue Type: New Feature Components: Source Reporter: Will Glass-Husain Assigned To: Will Glass-Husain Fix For: 1.5 Attachments: invalidreference.txt I've made a new patch that includes a ReferenceInsertionEventHandler (InvalidReferenceHandler) that collects a list of all invalid references in a Velocity page. To see how it works, look at the test code (the last two methods) in BuiltInEventHandlerTestCase. To make this work, I had to make some changes to the internals. So I thought I'd hold off a couple days before committing, let any interested parties comment. There's a couple of interesting new pieces for plugin writers. (1) In any user-defined plugin (event handlers, uberspectors, etc) you can now throw a subclass of VelocityRuntimeException (new exception). to signal unrecoverable states to the calling application. This runtime exception requires no change to the interface signature and is passed through the Velocity parsing process. (In the past, all Exceptions were caught and logged). Example use: a custom uberspector or event handler that wishes to stop page processing. For example, the InvalidReferenceHandler can be configured to throw an exception at the first reference error. (2) Event handlers can now receive information on the template name, line number, and column by implementing InfoAware. This only works for Local event handlers attached to a context (as opposed to the new Global type defined in Velocity properties). Example use: InvalidReferenceHandler reports out the line,column, and template name of each reference error. Everything is completely backwards compatible. It'd be simpler if it wasn't of course as they we could just redo the interfaces. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (VELOCITY-462) Change headers in source files to comply with new license header policy
Change headers in source files to comply with new license header policy --- Key: VELOCITY-462 URL: http://issues.apache.org/jira/browse/VELOCITY-462 Project: Velocity Issue Type: Improvement Reporter: Will Glass-Husain The text at the top of every source file must be changed according to new ASF rules adopted this Spring. The changes are intended to improve cliarity and make the files easier to maintain. According to the new policy, this must be implemented for any release after November 1, 2006. Archived old releases do not need to be changed. There's some scripts available to help out. More info at: http://www.apache.org/legal/src-headers.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-462) Change headers in source files to comply with new license header policy
[ http://issues.apache.org/jira/browse/VELOCITY-462?page=all ] Will Glass-Husain updated VELOCITY-462: --- Component/s: Source Fix Version/s: 1.5 Affects Version/s: 1.5 beta1 Change headers in source files to comply with new license header policy --- Key: VELOCITY-462 URL: http://issues.apache.org/jira/browse/VELOCITY-462 Project: Velocity Issue Type: Improvement Components: Source Affects Versions: 1.5 beta1 Reporter: Will Glass-Husain Fix For: 1.5 The text at the top of every source file must be changed according to new ASF rules adopted this Spring. The changes are intended to improve cliarity and make the files easier to maintain. According to the new policy, this must be implemented for any release after November 1, 2006. Archived old releases do not need to be changed. There's some scripts available to help out. More info at: http://www.apache.org/legal/src-headers.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
query - default logging behavior
Hi, As you can see with the log messages, we're making some headway on a variety of Velocity issues this week. One quick item for discussion. The default logging behavior is to create a file velocity.log in the current directory. This is really quite annoying in a webapp or integrated app. One of my colleagues built a quick email routine using Velocity in a webapp. Now, I see a velocity.log file created on my Linux server in whatever directory I happened to be in when I started Tomcat! Here's the suggestion. Switch the default logging to StdErr. I'd suggested something similar in VELOCITY-403, but there was no resolution. STDERR is preferred to STDOUT so that it doesn't mess up existing log files if out is redirected. Consequence... happier web developers. Possible problem - command line apps which depend on Velocity.log being created don't see it. Any comments? WILL -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: query - default logging behavior
So - if a user deploys this without the Avalong LogKit there's no velocity.log automatically created? That seems ok to me. WILL On 10/10/06, Nathan Bubna [EMAIL PROTECTED] wrote: I haven't much time for this today, but here's my initial thoughts: - As it is, my last bought of logging upgrades made the default lookup order: LogKit, Log4j, JDK logging, and StandardOutLogChute (which sends error to Std.out and error to Std.err). This still seems appropriate for me and will already not create a velocity.log file unless Avalon LogKit or Log4j are available and a runtime.log property is set. - So killing the velocity.log file is as easy as not using velocity-dep.jar and/or setting runtime.log = - I know this only sort of a B.C. concern, but it isn't really a trivial change either. - I'm of the view that Std.err is for errors (and maybe warnings), and is Std.out really redirected that often? And when it is, is that really our concern? Seems to me anyone redirecting Std.out should be prepared for surprises or least they shouldn't be critical. So, all that is to say that i currently am: -0 on removing Log4j and LogKit from the default lookup order in 1.5 -1 on punting trace/info/debug messages to Std.err +0 on punting warning messsages to Std.err -1 on putting StandardOutLogChute or kin before JdkLogChute in the lookup order +1 for tweaking this later on when we drop LogSystem support et al On 10/10/06, Will Glass-Husain [EMAIL PROTECTED] wrote: Hi, As you can see with the log messages, we're making some headway on a variety of Velocity issues this week. One quick item for discussion. The default logging behavior is to create a file velocity.log in the current directory. This is really quite annoying in a webapp or integrated app. One of my colleagues built a quick email routine using Velocity in a webapp. Now, I see a velocity.log file created on my Linux server in whatever directory I happened to be in when I started Tomcat! Here's the suggestion. Switch the default logging to StdErr. I'd suggested something similar in VELOCITY-403, but there was no resolution. STDERR is preferred to STDOUT so that it doesn't mess up existing log files if out is redirected. Consequence... happier web developers. Possible problem - command line apps which depend on Velocity.log being created don't see it. Any comments? WILL -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - 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] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: query - default logging behavior
Quick followup on this, then. Maybe we should leave the Avalon Log Kit out of the velocity dependency jar? My objective is to make this simpler for casual or new users. I'd think at this point the Avalon approach doesn't add a lot of value for that crowd. Those who want it can copy it into their classpath explicitly. WILL On 10/10/06, Will Glass-Husain [EMAIL PROTECTED] wrote: So - if a user deploys this without the Avalong LogKit there's no velocity.log automatically created? That seems ok to me. WILL On 10/10/06, Nathan Bubna [EMAIL PROTECTED] wrote: I haven't much time for this today, but here's my initial thoughts: - As it is, my last bought of logging upgrades made the default lookup order: LogKit, Log4j, JDK logging, and StandardOutLogChute (which sends error to Std.out and error to Std.err). This still seems appropriate for me and will already not create a velocity.log file unless Avalon LogKit or Log4j are available and a runtime.log property is set. - So killing the velocity.log file is as easy as not using velocity-dep.jar and/or setting runtime.log = - I know this only sort of a B.C. concern, but it isn't really a trivial change either. - I'm of the view that Std.err is for errors (and maybe warnings), and is Std.out really redirected that often? And when it is, is that really our concern? Seems to me anyone redirecting Std.out should be prepared for surprises or least they shouldn't be critical. So, all that is to say that i currently am: -0 on removing Log4j and LogKit from the default lookup order in 1.5 -1 on punting trace/info/debug messages to Std.err +0 on punting warning messsages to Std.err -1 on putting StandardOutLogChute or kin before JdkLogChute in the lookup order +1 for tweaking this later on when we drop LogSystem support et al On 10/10/06, Will Glass-Husain [EMAIL PROTECTED] wrote: Hi, As you can see with the log messages, we're making some headway on a variety of Velocity issues this week. One quick item for discussion. The default logging behavior is to create a file velocity.log in the current directory. This is really quite annoying in a webapp or integrated app. One of my colleagues built a quick email routine using Velocity in a webapp. Now, I see a velocity.log file created on my Linux server in whatever directory I happened to be in when I started Tomcat! Here's the suggestion. Switch the default logging to StdErr. I'd suggested something similar in VELOCITY-403, but there was no resolution. STDERR is preferred to STDOUT so that it doesn't mess up existing log files if out is redirected. Consequence... happier web developers. Possible problem - command line apps which depend on Velocity.log being created don't see it. Any comments? WILL -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - 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] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: query - default logging behavior
Alright, Nathan! Hack away! WILL On 10/10/06, Nathan Bubna [EMAIL PROTECTED] wrote: On 10/10/06, Nathan Bubna [EMAIL PROTECTED] wrote: On 10/10/06, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Nathan Bubna [EMAIL PROTECTED] writes: lookup order: LogKit, Log4j, JDK logging, and StandardOutLogChute (which sends error to Std.out and error to Std.err). This still This is IMHO not a good decision. If you want to have an application that writes to stdout, you get logging messages intermixed. I'd very much appreciate if we send all the logging to stderr. hmm. then let's punt the decision to users. we should have both StandardOut and StandardErr LogChutes, or a StandardLogChute that can be configured to direct output either way. choose whichever you wish for the default, i pretty much always manually configure logging anyway, so it won't bother me. actually, this was quick. so i took 5 minutes to write it. testing now... will check in shortly. by default all messages with level trace or higher will print to System.err - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: query - default logging behavior
Hi Llewellyn! Good input. You're probably right in many cases. I did a quick scan looking for Log.error. Many of them are initialization-related errors -- perhaps those should be exceptions instead. We just moved the app-level exceptions to be RuntimeExceptions which gives us more freedom to throw exceptions without changing the API. (this was one of the obstacles in the past). I disagree a bit about reference errors -- I think we should make it optional whether or not they log a warning or stop page execution. Right now they always do the former, but I'm working on a event handler to allow the latter. I think we've addressed your patches around the uberspector in svn head at this point. WILL On 10/10/06, Llewellyn Falco [EMAIL PROTECTED] wrote: I still would like to put in my vote that sending error's to the log is an incredibly BAD idea. If something is not working, it should be LOUDLY shown as an exception. If it is working I don't really need a log. The (velocity) log should be there for velocity developers (those programming the actual velocity code) not users. I don't ever care to see tomcat's log, I care to see the things I log while in tomcat. Most of all, many many many people do not check the log at all, let alone frequently. personally I swapped out the logging uberspect over 2 years ago, in favor of code that actually worked, rather than code that didn't appear broken, but actually was. but i know the default uberspect is still the logger, i believe the TestableUberspect is still in the test branch, and a regular user is probably just confused as to why something isn't working, double or triple so if the something is in an if or for loop. Llewellyn. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VELOCITY-132) IllegalArgumentException while calling an overloaded method
[ http://issues.apache.org/jira/browse/VELOCITY-132?page=all ]
Will Glass-Husain resolved VELOCITY-132.
Resolution: Invalid
Hi, thanks for reporting this and commenting.
I'm marketing this issue as invalid. There's two different issues here-- one
has been previously fixed and one is as desired.
The first issue concerns the IllegalArgumentException when the provided example
is included with #parse. I was unable to reproduce this. I've added unit
tests to verify this is working properly.I believe it was fixed between 1.4
and 1.5. Mike comments above that in the nightly source his example returns:
$testobj.foo( $param )
String
this is the correct response. Calling $testobj.foo(null) could return either
of two possible method calls. Since it's impossible to tell which to call,
Velocity returns neither. (there's an error message in the log noting the
ambiguity).
The second issue is when Llewellyn argues above that this is incorrect
behavior, that if a method call is ambiguous, Velocity should pick one. I
disagree. It's hard to know which one to pick. There's a clear message in the
log listing the method call and stating it's ambiguous. Thus it's the
developer's responsibility to provide a context object with methods that are
not ambiguous.
Resolved - marking as invalid, but adding unit tests to confirm. Thanks again.
IllegalArgumentException while calling an overloaded method
---
Key: VELOCITY-132
URL: http://issues.apache.org/jira/browse/VELOCITY-132
Project: Velocity
Issue Type: Bug
Components: Source
Affects Versions: 1.3-rc1
Environment: Operating System: All
Platform: All
Reporter: MySign
Fix For: 1.5
Attachments: includecall.vm, velocity_patch.patch, velocitybug.vm,
VelocityCachingBug.java
If there are two methods with the same name and different parameters like:
public class myClass
{
public String foo ( Integer intObj );
public String foo ( String str );
}
and a velocity template like this
$myObj.foo( $someObj.getNull() )
$myObj.foo( $str )
while $someObj.getNull() returns null and $str is a java.lang.String object
with a String like 'test'. Because velocity caches the first method with the
Integer argument on calling with the parameter null (which isn't of course of
any type/class) the call fails with the String argument, because velocity
tries
to call the foo( Integer intObj )!
In the velocity log appears a IllegalArgumentException which is right, but
velocity should call the right method!
mike
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VELOCITY-179) prevent execution of methods on Class, ClassLoader and related classes
[ http://issues.apache.org/jira/browse/VELOCITY-179?page=all ] Will Glass-Husain resolved VELOCITY-179. Fix Version/s: 1.5 (was: 1.6) Resolution: Fixed Committed a cleaned up version of this. r454595. To use, add the following line to velocity.properties: runtime.introspector.uberspect = org.apache.velocity.util.introspection.SecureUberspector The specific list of packages and classes for which methods are blocked is configurable in velocity.properties. (though the defaults should be sufficient). prevent execution of methods on Class, ClassLoader and related classes -- Key: VELOCITY-179 URL: http://issues.apache.org/jira/browse/VELOCITY-179 Project: Velocity Issue Type: Improvement Components: Source Affects Versions: 1.4 Environment: Operating System: All Platform: All Reporter: Will Glass-Husain Assigned To: Will Glass-Husain Priority: Minor Fix For: 1.5 Attachments: IntrospectorTestCase4.java, patch1.txt, patch2.txt, patch2b.txt, testcases.xml.patch Template designers currently have the capability to acquire a ClassLoader, instantiate an arbitrary class, and call an arbitrary method. (Example: [1], although more compact examples exist). This is a drastic break with the MVC model, as template designers can execute any arbitary code. It gets worse if you have untrusted template designers who might call methods that erase files, execute arbitrary SQL code, or shut down the VM. This has been discussed on the dev list [2]. This patch prevents any method from being called on objects of a class that has reflection, classloader, or runtime capabilities. (List at the end of the report [4]). It's configurable with a property, but the default is ON, as security restrictions, IMHO, should be strict by default. An alternate solution to this issue would be to prohibit the ClassLoader through the Java Security Manager, as proposed here [4]. I believe this solution to be too difficult for the typical developer. It's complex, and requires knowledge of the Velocity source code. Essentially, you have to split the files that execute the methods on the Java classes into a separate JAR file, then designate that jar file as not have permission to call getClassLoader. This requires that you (A) know what those Velocity classes are (B) understand how to work with the security manager, which is quite complex, and (C) have to modify the Velocity package every time there is a new release. I think it would be better if this is handled natively within Velocity. Finally, this patch does not include docs or test cases. I'd be willing to write both, if a committer is willing to put in the patch. [1] Example of VTL to call arbitray method http://nagoya.apache.org/eyebrowse/ReadMsg?listName=velocity- [EMAIL PROTECTED]msgNo=6114 [2] Related discussion http://nagoya.apache.org/eyebrowse/ReadMsg?listId=102msgNo=5980 http://nagoya.apache.org/eyebrowse/ReadMsg?listName=velocity- [EMAIL PROTECTED]msgNo=10444 [3] Classes affected java.lang.Class java.lang.ClassLoader java.lang.Compiler java.lang.Package java.lang.Process java.lang.InheritableThreadLocal java.lang.Runtime java.lang.RuntimePermission java.lang.SecurityManager java.lang.System java.lang.Thread java.lang.ThreadGroup java.lang.ThreadLocal java.lang.reflect.* [4] Java security manager proposal http://nagoya.apache.org/eyebrowse/ReadMsg?listName=velocity- [EMAIL PROTECTED]msgNo=6012 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Velocity Hackathon - October 9/10
All the known bugs, of course.
We might release if a couple of bugs remain stubbornly unfixed, but I'd like
to get most done. We've fixed dozens since 1.4. It'll be a pleasure to stop
telling users who report the same problem for the umpteenth time use the
source control head, it's fixed or this is a known issue, we'll get to it
eventually.
WILL
On 9/30/06, Nathan Bubna [EMAIL PROTECTED] wrote:
On 9/29/06, Will Glass-Husain [EMAIL PROTECTED] wrote:
Hi Malcolm,
I think we'll be close. (But I'll confess I've gotten in trouble
every time I've made a prediction).
My current feeling is that at ApacheCon we can work together to update
the docs, put the outstanding enhancement issues in, and fix a bunch
of the bugs. Then we can issue a feature-complete beta2 right in
mid-October.
I've got this perfectionist zeal to fix all the bugs before releasing.
I count 17 without patches right now. If other community members
could step up and tackle one or two each, we could get them all done.
All the bugs? or all the known bugs? :)
Once those are fixed, we would do a Release Candidate 1, wait a
couple of weeks, and if all is well issue Velocity 1.5.
(one key criteria for success of RC1 would be backwards-compatibility
with other frameworks like Click and Cayenne-- look forward to your
feedback on that).
Henning, Nathan, seem about right?
Yeah, i'd like to see these all fixed too. But for the record, if we
fail to squash some of the obscure ones that have been around for a
few releases already, i'd still like to see a release happen. There
have been too many improvements to hold this back much longer.
WILL
On 9/29/06, Malcolm Edgar [EMAIL PROTECTED] wrote:
Hi Will,
do you think a 1.5 release is achievable in mid October. I reason I
ask is Click Framework 1.0 is about to be release, but it would be
worth delaying a few weeks to include Velocity 1.5.
regards Malcolm Edgar
On 9/30/06, Will Glass-Husain [EMAIL PROTECTED] wrote:
Hi,
We're holding a mini 'hackathon' for Velocity at ApacheCon October 9
10. Henning and I will be there, though we welcome participation
from
others at the con or remotely. I'm looking forward to the focused
time together.
I'd like to challenge us to ready ourselvesfor a release right after
ApacheCon. I've grouped the open items below. I'll take personal
responsibility to see that issue below with a submitted patch that
is
ready (or almost ready) makes it in. Many of those are mine,
anyway.
The remaining bugs are all fairly subtle. They seem to be grouped
around escaping issues, macro issues, and error reporting issues.
With a little luck we can work through most of them. If anyone
wants
to dive into the code and work through a few, that'd be fabulous.
Two specific items we could use help on. Anyone a Texen or DVSL
guru?
VELOCITY-413 (DVSL) really needs to be fixed. And there's a nice
Texen patch (VELOCITY-422) waiting to be added.
Cheers,
WILL
Bugs (has patch/partial patch)
---
VELOCITY-132IllegalArgumentException while calling an overloaded
method
(needs a little work)
Bugs (no patches)
---
VELOCITY-449Velocity Uberspector behaves differently for
get(String)
and put(String, Object) methods
VELOCITY-456Uberspector chokes on a number of corner cases
VELOCITY-458InternalContextBase defines non-serializable
non-transient fields
VELOCITY-71 False positive error condition parsing
VM_global_library.vm
VELOCITY-82 VM libs will not autoreload if unparseable at
Velocity startup
VELOCITY-214References to non-public members (inner classes,
fields,
etc.) should log a warning rather than failing silently
VELOCITY-251$\!{foo} doesn't render as expected
VELOCITY-264Escaping in form of $\!{foo} does not work
VELOCITY-280Parsing of braces after a reference fails
VELOCITY-209Encountered ) Was expecting one of: )
VELOCITY-24 calls to local macros not always made when template
caching is off
VELOCITY-262#set not parsed in #macro
VELOCITY-285reference within macro and foreach is incorrect
VELOCITY-435ParseErrorException not thrown with #macro parse
error
VELOCITY-455Error in chapter Escaping VTL Directives in the
User Guide
VELOCITY-457documentation mistake? order of Velocimacros in
template
VELOCITY-413DVSL doesn't appear to work with Velocity 1.5
Enhancements (with patches/partial patches)
---
VELOCITY-405 Document new Event Handler features (needs work from
WGH)
VELOCITY-423 Report invalid references (needs work from WGH)
VELOCITY-179 Prevent execution of methods on Class, ClassLoader and
related classes (needs work from WGH)
VELOCITY-422Add support for property and propertyset nested
elements to TexenTask.
VELOCITY-414Extend
Re: MethodCacheKey patch (was: svn commit: r449347)
That's a good idea. I think I'll leave it as it is though, there's a convenience to having all the tests in one directory right now. On 9/29/06, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Will Glass-Husain [EMAIL PROTECTED] writes: Thanks for the note. I made MethodCacheKey a public inner class so that we could access it from the unit test. Couldn't figure out a better way to do this, though suggestions are welcome. Package private and the unit tests in the same package (though in another source directory). Best regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Social behaviour: Bavarians can be extremely egalitarian and folksy. -- http://en.wikipedia.org/wiki/Bavaria Most Franconians do not like to be called Bavarians. -- http://en.wikipedia.org/wiki/Franconia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Velocity Hackathon - October 9/10
Hi,
We're holding a mini 'hackathon' for Velocity at ApacheCon October 9
10. Henning and I will be there, though we welcome participation from
others at the con or remotely. I'm looking forward to the focused
time together.
I'd like to challenge us to ready ourselvesfor a release right after
ApacheCon. I've grouped the open items below. I'll take personal
responsibility to see that issue below with a submitted patch that is
ready (or almost ready) makes it in. Many of those are mine, anyway.
The remaining bugs are all fairly subtle. They seem to be grouped
around escaping issues, macro issues, and error reporting issues.
With a little luck we can work through most of them. If anyone wants
to dive into the code and work through a few, that'd be fabulous.
Two specific items we could use help on. Anyone a Texen or DVSL guru?
VELOCITY-413 (DVSL) really needs to be fixed. And there's a nice
Texen patch (VELOCITY-422) waiting to be added.
Cheers,
WILL
Bugs (has patch/partial patch)
---
VELOCITY-132IllegalArgumentException while calling an overloaded method
(needs a little work)
Bugs (no patches)
---
VELOCITY-449Velocity Uberspector behaves differently for get(String)
and put(String, Object) methods
VELOCITY-456Uberspector chokes on a number of corner cases
VELOCITY-458InternalContextBase defines non-serializable non-transient
fields
VELOCITY-71 False positive error condition parsing VM_global_library.vm
VELOCITY-82 VM libs will not autoreload if unparseable at Velocity startup
VELOCITY-214References to non-public members (inner classes, fields,
etc.) should log a warning rather than failing silently
VELOCITY-251$\!{foo} doesn't render as expected
VELOCITY-264Escaping in form of $\!{foo} does not work
VELOCITY-280Parsing of braces after a reference fails
VELOCITY-209Encountered ) Was expecting one of: )
VELOCITY-24 calls to local macros not always made when template caching is
off
VELOCITY-262#set not parsed in #macro
VELOCITY-285reference within macro and foreach is incorrect
VELOCITY-435ParseErrorException not thrown with #macro parse error
VELOCITY-455Error in chapter Escaping VTL Directives in the User Guide
VELOCITY-457documentation mistake? order of Velocimacros in template
VELOCITY-413DVSL doesn't appear to work with Velocity 1.5
Enhancements (with patches/partial patches)
---
VELOCITY-405 Document new Event Handler features (needs work from WGH)
VELOCITY-423 Report invalid references (needs work from WGH)
VELOCITY-179 Prevent execution of methods on Class, ClassLoader and
related classes (needs work from WGH)
VELOCITY-422Add support for property and propertyset nested
elements to TexenTask.
VELOCITY-414Extend the MethodInvocation exception to be able to give
the velocity macro writer a usefull error page
(needs work)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
MethodCacheKey patch (was: svn commit: r449347)
FYI.
* I applied Alexey's modified patch. (much appreciated)
* I applied Alexey's new hashCode routine. seems reasonable to me.
* I added NPE checks to equals and hash code. While Alexey's point
these are never needed is a good one, I worry about the consequence of
adding code in the future that uses this class in a new way.
* Similarly, I changed == to equals() in the equals() method. (or
rather, != to !equals)
* Finally, I added a version of Hennings' equals() unit test.
Normally I'd argue a unit test for equals() is overkill. But here,
the equals() method is the main point of MethodCacheKey (and is the
feature that was incorrect in the previous version).
Best, WILL
On 9/28/06, Henning Schmiedehausen [EMAIL PROTECTED] wrote:
Hi Alexey,
thanks a lot for your patch. I like it and we should apply it. I very
much appreciate that you understood my mail as peer review and not
critique per se.
[...]
This is just waste of processor cycles.
The Class does not override the equals().
Hm. It does not for the Sun JDK and I'm pretty sure that it will not be
overridden by any other JDK, but this is IMHO not guaranteed.
One of my Java memes is thou shalt never compare two objects with ==
or !=. A class object is definitely an object. Yes, the default
implementation of equals() inside Object is '=='.
However, it is the job of the compiler to optimize that away, not of the
developer to second guess it. So for the sake of being anal, I'd like to
see equals() here. :-)
And it never be overriden.
Sure? /me thinks of weird class loader things and runtime byte code
'improvements'... :-) But again, I'm splitting hairs here...
mainly because I don't like the implementation of
the methods and don't believe in the handwaving that this is faster
than using EqualsBuilder and HashCodeBuilder because of Object
creation. I haven't seen any numbers to prove or disprove that claim.
You want to compare the speed of
[... HCB vs. hand-rolled code removed ...]
Yes, because I wouldn't use the Reflection code but add the attributes
explicitly and again, I will not second guess the compiler. I'll try to
get some numbers tonight...
[...]
An unit test draft could look like this:
...
public void testHashCode()
{
Class [] e1 = new Class [] { String.class, String.class };
Class [] e2 = new Class [] { Object.class, Object.class };
ASTMethod m1 = new ASTMethod(23);
MethodCacheKey mck1 = m1.new MethodCacheKey(e1);
MethodCacheKey mck2 = m1.new MethodCacheKey(e2);
assertTrue(mck1.hashCode() != mck2.hashCode());
}
I do not agree with this test. It is not required (and is not always
possible) that different objects return different hashcodes.
Yes, you are right. That is a leftover and should not be there. As I
said, this was a draft. (I do know that the smallest legal
implementation of hashCode() is public int hashCode() { return 42; } ;-) )
Best regards
Henning
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Forio Business Simulations
Will Glass-Husain
[EMAIL PROTECTED]
www.forio.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: MethodCacheKey patch (was: svn commit: r449347)
Hi Alexey,
Thanks for the note. I made MethodCacheKey a public inner class so
that we could access it from the unit test. Couldn't figure out a
better way to do this, though suggestions are welcome.
I know, the NPE checks seem a little silly. Still, the checks are
cheap. I worry that the code may be reused in the future and the
caveats forgotten. I'm fine with checking them in the constructor,
not a bad idea.
Best,
WILL
On 9/28/06, Alexey Panchenko [EMAIL PROTECTED] wrote:
Will Glass-Husain wrote:
* I applied Alexey's modified patch. (much appreciated)
You missed one point - MethodCacheKey is a static class in my patch.
The methodName is copied from the ASTMethod into the MethodCacheKey,
so the MethodCacheKey doesn't need access to it's parent class.
* I applied Alexey's new hashCode routine. seems reasonable to me.
* I added NPE checks to equals and hash code. While Alexey's point
these are never needed is a good one, I worry about the consequence of
adding code in the future that uses this class in a new way.
Your added if (methodName != null) in hashCode(), however there is
no such check in equals(). This is inconsistent.
Btw, methodName is never null - it is parsed from the template and I
can't imagine such a template.
And actually, I don't quite understand your concerns about the nulls.
- The assert() is a standard and compact way to express the
requirements for the variable values. If somebody starts using this
class the way it's not supposed to be used - the asserts would fail.
This class is internal to Velocity, so somebody == Velocity developers
only.
- If you believe null should be accepted as a parameter the simplier
way is to check it in the constructor:
this.methodName = methodName != null ? methodName : StringUtils.EMPTY;
this.params = params != null ? params : ArrayUtils.EMPTY_CLASS_ARRAY;
So the rest of the code could be much simplier.
* Similarly, I changed == to equals() in the equals() method. (or
rather, != to !equals)
* Finally, I added a version of Hennings' equals() unit test.
Normally I'd argue a unit test for equals() is overkill. But here,
the equals() method is the main point of MethodCacheKey (and is the
feature that was incorrect in the previous version).
Best, WILL
On 9/28/06, Henning Schmiedehausen [EMAIL PROTECTED] wrote:
Hi Alexey,
thanks a lot for your patch. I like it and we should apply it. I very
much appreciate that you understood my mail as peer review and not
critique per se.
[...]
This is just waste of processor cycles.
The Class does not override the equals().
Hm. It does not for the Sun JDK and I'm pretty sure that it will not be
overridden by any other JDK, but this is IMHO not guaranteed.
One of my Java memes is thou shalt never compare two objects with ==
or !=. A class object is definitely an object. Yes, the default
implementation of equals() inside Object is '=='.
However, it is the job of the compiler to optimize that away, not of the
developer to second guess it. So for the sake of being anal, I'd like to
see equals() here. :-)
And it never be overriden.
Sure? /me thinks of weird class loader things and runtime byte code
'improvements'... :-) But again, I'm splitting hairs here...
mainly because I don't like the implementation of
the methods and don't believe in the handwaving that this is faster
than using EqualsBuilder and HashCodeBuilder because of Object
creation. I haven't seen any numbers to prove or disprove that claim.
You want to compare the speed of
[... HCB vs. hand-rolled code removed ...]
Yes, because I wouldn't use the Reflection code but add the attributes
explicitly and again, I will not second guess the compiler. I'll try to
get some numbers tonight...
[...]
An unit test draft could look like this:
...
public void testHashCode()
{
Class [] e1 = new Class [] { String.class, String.class };
Class [] e2 = new Class [] { Object.class, Object.class };
ASTMethod m1 = new ASTMethod(23);
MethodCacheKey mck1 = m1.new MethodCacheKey(e1);
MethodCacheKey mck2 = m1.new MethodCacheKey(e2);
assertTrue(mck1.hashCode() != mck2.hashCode());
}
I do not agree with this test. It is not required (and is not always
possible) that different objects return different hashcodes.
Yes, you are right. That is a leftover and should not be there. As I
said, this was a draft. (I do know that the smallest legal
implementation of hashCode() is public int hashCode() { return 42; } ;-) )
Best regards
Henning
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Best regards,
Alexeymailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail
[jira] Commented: (VELOCITY-461) Class loading issue
[ http://issues.apache.org/jira/browse/VELOCITY-461?page=comments#action_12438233 ] Will Glass-Husain commented on VELOCITY-461: That is fixed as well in Velocity-1.5-beta. Anything that comes from the class path is first searched for in the ContextClassLoader, then via getClassLoader. Further questions? Please take them to the user list and we'll be happy to answer them there. Class loading issue --- Key: VELOCITY-461 URL: http://issues.apache.org/jira/browse/VELOCITY-461 Project: Velocity Issue Type: Bug Affects Versions: 1.4 Environment: any java env Reporter: Vladimir Goncharov Priority: Blocker Fix For: 1.5 If Velocity.jar is loaded from the WL classpath then it cannot load resources from the war or ear. This applies to both template resources as well as to the loader of the resources loaders themselves e.g. custom ClasspathResourceLoader couldn't be loaded when velocity.jar was loaded from the WL app claspath and the custom class was loaded from the ear. In my view all appearances of this.getClass().getClassLoader() should be replaced by Thred.currentThread.getContextClassLoader() Thanks -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r449347 - in /jakarta/velocity/engine/trunk:
Wow. That's a lot of comments, all good ones. I'd hate to see you
sad, Henning, your cheery disposition lights up this project. :-)
One quick point. I want to re-iterate what I said in the JIRA note.
This is a bug that's been in Velocity a long time, in a fundamental
part of the caching routine. Nice job, Alexey, on finding this,
fixing it, and jumping through all the hoops to get the patch in.
Hope to see more.
I'll take responsibility to work with Alexey in cleaning this up.
Though to be fair, you are holding the patch to a higher standard than
the original. Of course the original had a bug.
And the typo in the copyright date is my fault. Legal issues are
really the responsibility of the committers :-)
WILL
On 9/27/06, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] writes:
(This mail might sound a bit hash. It is not intended as such, but I
want to make sure that we do get peer review with code going in, even
if it is just a small fix. So I intend to use this as an example
case. Sorry 'bout that. This message is intended to criticize the
code, not you or Alexey).
-private String methodName = ;
+protected String methodName = ;
[...]
+if (params.length == other.params.length
methodName.equals(other.getASTMethod().methodName))
I'm -0.5 on that patch. That coding style is not good (private is
there for a reason), the change to protected is not even needed,
because if you are an object of class Foo, you can look at the
private fields of every other Foo, too:
public class Foo {
private final int value;
public Foo(final int value) { this.value = value; }
public void report(final Foo foo) {
System.out.println(foo.value);
}
}
public class Bar {
public static void main(String[] args) {
Foo foo1 = new Foo(23);
Foo foo2 = new Foo(42);
foo2.report(foo1);
}
}
Run Bar and you will get 23 as the result. foo2 is allowed to look
at the private value field of foo1.
If we need to look at member fields of any class, we add getters and
setters, not change the visibility of the member fields. It is the job
of the Java compiler (which does a very good job here) to optimize
that.
I don't like the fact that there is object comparing (the Class
elements of params should be compared using equals, not != ) in the
code.
The code doesn't adhere to our indent rules and the year date in the
copyright notice is wrong (should be 2006). I freely admit that I'm
picking nits here, mainly because I don't like the implementation of
the methods and don't believe in the handwaving that this is faster
than using EqualsBuilder and HashCodeBuilder because of Object
creation. I haven't seen any numbers to prove or disprove that claim.
The hash method uses the ^= method to add the parameters. This is a
really bad idea, because it detoriates the hash value. Consider two
arrays:
Class [] e1 = new Class [] { String.class, String.class };
Class [] e2 = new Class [] { Object.class, Object.class };
int result = 0;
for (int i = 0; i params.length; ++i)
{
final Class param = params[i];
if (param != null)
{
result ^= param.hashCode();
}
}
That loop returns the same value for both arrays: 0 (The reason why is
left for the reader as an exercise :-) ).
Yes, it *is* hard to write a good hash function. That is why there is
so much literature about it.
E.g. http://java.sun.com/developer/Books/effectivejava/Chapter3.pdf
(In Hard Core Java, the methods in the Jakarta commons are
explicitly mentioned as examples for a good hash code function. There
is a reason for this).
I know that this is private code (if it is, why is MethodCacheKey
package protected and not private?) and it can never be called with
params == null. However, if you do, you get an NPE. If it is possible
to make that code robust, why not do it?
An unit test draft could look like this:
--- cut ---
package org.apache.velocity.runtime.parser.node;
import junit.framework.Test;
import junit.framework.TestSuite;
import org.apache.commons.lang.ArrayUtils;
import org.apache.velocity.runtime.parser.node.ASTMethod.MethodCacheKey;
import org.apache.velocity.test.BaseTestCase;
/*
* Copyright 2006 The Apache Software Foundation.
*
* Licensed 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.
*/
/**
* Test ASTMethod equals() and hashCode()
*
* @author a href=mailto:[EMAIL PROTECTED]Will Glass-Husain/a
* @version $Id: ResourceCachingTestCase.java 447969 2006-09
Re: projects under TLP umbrella
I agree with Geir about the advantages of working with nVelocity. While there wouldn't be a lot of cross-code collaboration (might be wrong) it'd be great to work on design and conceptual issues, make sure that templates could be moved back and forth. WILL On 9/27/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Henning P. Schmiedehausen wrote: Will Glass-Husain [EMAIL PROTECTED] writes: Starting a new thread... First, project characteristics. I'd argue that a good project for the TLP would have -- developers who are part of the Velocity community (either active on the mailing lists, and better yet those who have contributed patches or bug reprots) Yes. There might also be some discussion whether we will start new Velocity projects inside the TLP at all. I don't see any problem with that, as long as it's not unrelated, like Maven was inside Turbine. -- strong or growing community of its own +1 -- the integration of Velocity is a key part of the project +1 Second... project content... What are some typical kinds of projects that might fall under the TLP umbrella, and why? -- A way of making Velocity accessible for new use? (e.g. Texen, Anakia, DVSL, a JSP tag library based on Velocity expressions) Not sure here. Why? -- Port of Velocity to another platform? (e.g. nVelocity) That is the usual Language/Tool clash. If there were a (hypothetical) Apache .NET TLP, would nVelocity go there or to us? Us. I'd fight against a .NET TLP. Putting that aside, we'd want nVelocity to be in lock-step with us as much as possible, so things like configuration files and templates were portable. -- Web framework closely tied to Velocity (Click, Turbine?) Click: yes. Turbine: no. Reason: Click is built intimately around Velocity. Turbine just happens to treat Velocity as a first class citizen but there is no reason why you couldn't use any other templating solution or JSP with Turbine. And the templating is just a very small part of Turbine at all. Not saying all of the above are candidates. But would they fit our desired umbrella? My € 0.02 :-) Best regards Henning - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-460) the IncludeRelativePath handler should treat paths beginning with a slash as absolute paths
[ http://issues.apache.org/jira/browse/VELOCITY-460?page=comments#action_12437902 ] Will Glass-Husain commented on VELOCITY-460: Hi Claude, are you sure? would you mind doing cd root svn up cd build ant clean ant test It appears there's an overlap of test files. For some reason, BuiltInEventHandlerTestCase uses file test2.vm and so does IncludeEventHandlingTestCase. Since you changed test2.vm, this broke BuiltInEventHandlerTestCase. What also puzzles me is the two test cases seem to overlap. Did you move it from one to another? the IncludeRelativePath handler should treat paths beginning with a slash as absolute paths --- Key: VELOCITY-460 URL: http://issues.apache.org/jira/browse/VELOCITY-460 Project: Velocity Issue Type: Improvement Components: Source Affects Versions: 1.5 beta1 Reporter: Claude Brisson Priority: Minor Attachments: IncludeRelativePath.patch, IncludeRelativePath.patch.v2 The most widely spread convention about systems supporting relative paths is that paths that begin with '/' (or '\') are absolute while others are relative. The IncludeRelativePath event handler should follow the same convention. The corrective patch is attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-460) the IncludeRelativePath handler should treat paths beginning with a slash as absolute paths
[ http://issues.apache.org/jira/browse/VELOCITY-460?page=comments#action_12437903 ] Will Glass-Husain commented on VELOCITY-460: maybe do a svn status as well to double-check which files have changed. thanks. the IncludeRelativePath handler should treat paths beginning with a slash as absolute paths --- Key: VELOCITY-460 URL: http://issues.apache.org/jira/browse/VELOCITY-460 Project: Velocity Issue Type: Improvement Components: Source Affects Versions: 1.5 beta1 Reporter: Claude Brisson Priority: Minor Attachments: IncludeRelativePath.patch, IncludeRelativePath.patch.v2 The most widely spread convention about systems supporting relative paths is that paths that begin with '/' (or '\') are absolute while others are relative. The IncludeRelativePath event handler should follow the same convention. The corrective patch is attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VELOCITY-460) the IncludeRelativePath handler should treat paths beginning with a slash as absolute paths
[ http://issues.apache.org/jira/browse/VELOCITY-460?page=all ] Will Glass-Husain resolved VELOCITY-460. Resolution: Fixed Turned out there was an extra newline at the end of test/includeevent/include-c.vm. removing this solved the issue and the tests passed. Thanks for this useful patch. Applied r450163. the IncludeRelativePath handler should treat paths beginning with a slash as absolute paths --- Key: VELOCITY-460 URL: http://issues.apache.org/jira/browse/VELOCITY-460 Project: Velocity Issue Type: Improvement Components: Source Affects Versions: 1.5 beta1 Reporter: Claude Brisson Priority: Minor Attachments: IncludeRelativePath.patch, IncludeRelativePath.patch.v2 The most widely spread convention about systems supporting relative paths is that paths that begin with '/' (or '\') are absolute while others are relative. The IncludeRelativePath event handler should follow the same convention. The corrective patch is attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-460) the IncludeRelativePath handler should treat paths beginning with a slash as absolute paths
[ http://issues.apache.org/jira/browse/VELOCITY-460?page=comments#action_12437670 ] Will Glass-Husain commented on VELOCITY-460: Ant test failed. Did you forget to include BuiltInEventHandlerTestCase? Testsuite: org.apache.velocity.test.BuiltInEventHandlerTestCase Tests run: 9, Failures: 1, Errors: 0, Time elapsed: 0.672 sec Testcase: testEscapeHtml took 0.062 sec Testcase: testEscapeXml took 0 sec Testcase: testEscapeSql took 0.016 sec Testcase: testEscapeJavaScript took 0 sec Testcase: testEscapeReferenceMatchAll took 0.203 sec Testcase: testEscapeReferenceMatch took 0.078 sec Testcase: testPrintExceptionHandler took 0.141 sec Testcase: testIncludeNotFound took 0.062 sec Testcase: testIncludeRelativePath took 0.078 sec FAILED Output incorrect. junit.framework.AssertionFailedError: Output incorrect. at org.apache.velocity.test.BuiltInEventHandlerTestCase.testIncludeRelativePath(BuiltInEventHandlerTestCase.java:317) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) the IncludeRelativePath handler should treat paths beginning with a slash as absolute paths --- Key: VELOCITY-460 URL: http://issues.apache.org/jira/browse/VELOCITY-460 Project: Velocity Issue Type: Improvement Components: Source Affects Versions: 1.5 beta1 Reporter: Claude Brisson Priority: Minor Attachments: IncludeRelativePath.patch, IncludeRelativePath.patch.v2 The most widely spread convention about systems supporting relative paths is that paths that begin with '/' (or '\') are absolute while others are relative. The IncludeRelativePath event handler should follow the same convention. The corrective patch is attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] Move Velocity to TLP
Great. I've a message in draft on the charter, but will send that after this one. So there's no confusion, Nathan - maybe you should resend the vote count to general noting the TLP vote is really closed and all -1's are resolved? Cheers, WILL On 9/25/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: To me, the vote to go TLP is done. I appreciate the respect and deference though. As for the -1, that's about the charter we'd propose to the board, and we still have a month, so I'm sure we'll come to consensus easily. geir Nathan Bubna wrote: On 9/23/06, Will Glass-Husain [EMAIL PROTECTED] wrote: Wow. Skip email for a day and there's a blizzard. I take Geir's comments pretty seriously though. To me, the most important part of this is the opportunity to grow the developer community. That's easy to say, of course. Technically, any committer in Jakarta now has svn commit rights to Velocity, and it hasn't seemed to make a difference. But by encouraging carefully selected projects to join the Velocity TLP, I think we'd see more energy and effort around Velocity core itself. What are those projects - how do we grow them - worthy of a separate thread. Process point -- should we put the vote on hold for a few days until we can discuss this and resolve Geir's -1? Not sure what it means to put a vote on hold and discuss it if that isn't what we're already doing. I guess it's worth stating officially though... ;-) Best, WILL Maybe we can On 9/23/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Right - moving to TLP doesn't make a difference there, other than the plan to bring in velocity related things into the project, which grows the commiter base. geir Nathan Bubna wrote: No, that is not basically the reason. On 9/22/06, Daniel Dekany [EMAIL PROTECTED] wrote: Saturday, September 23, 2006, 1:02:35 AM, Geir Magnusson Jr wrote: This vote closed sooner than expected. I was traveling and there was no stated deadline. [snip] So, Velocity will be TLP. Now, somebody correct me if I get it wrong, but is the reason basically that its developer community was not active enough, and being TLP would help to fix this situation? -- Best regards, Daniel Dekany - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-460) the IncludeRelativePath handler should treat paths beginning with a slash as absolute paths
[ http://issues.apache.org/jira/browse/VELOCITY-460?page=comments#action_12437702 ] Will Glass-Husain commented on VELOCITY-460: I'm on Windows. Let me tinker with this tonight. the IncludeRelativePath handler should treat paths beginning with a slash as absolute paths --- Key: VELOCITY-460 URL: http://issues.apache.org/jira/browse/VELOCITY-460 Project: Velocity Issue Type: Improvement Components: Source Affects Versions: 1.5 beta1 Reporter: Claude Brisson Priority: Minor Attachments: IncludeRelativePath.patch, IncludeRelativePath.patch.v2 The most widely spread convention about systems supporting relative paths is that paths that begin with '/' (or '\') are absolute while others are relative. The IncludeRelativePath event handler should follow the same convention. The corrective patch is attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] Move Velocity to TLP
no lasting interest and investment in the health and development of the core Velocity codebase. That's hard to measure. If that's known as a criterion, people will just say the right things. True. Let me try a rephrase of it: - To the exclusion of projects whose developer communities have not demonstrated consistent interest and investment in the continuing maintenance and development of the core Velocity codebase. To me that calls for some evidence like bug reports, patches, participation on dev@, etc. How's that sound? If there are projects that aren't template engines that want to come to Apache, the door is open and they are welcome. And template engines are welcome too, right? The question is whether being here would be just about them having the foundation and infrastructure support or if there is a community aspect too. If community matters, then it matters where they fit in Apache organizationally. So rather than a blanket statement that any Velocity-related projects are welcome or not welcome, i prefer having the freedom to individually vet the merits and fit of project interested in joining the Velocity TLP. And you, as a Velocity PMC member, would be very, very welcome to join in those discussions and decisions. Sure - I think thought that the project charter should be clearer. I would love it to be. Please help! But putting anything that uses Velocity into a TLP is like using things that use log4j into the same TLP (which would re-create Jakarta... :) Yep, good thing that's not the plan! :) That's not obvious to me. Hopefully you mean that wasn't obvious to you. I've gone to some pains to explain this... :) I'm slow. funny, and here i thought you were just busy... is Harmony not taking much time anymore? ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-460) the IncludeRelativePath handler should treat paths beginning with a slash as absolute paths
[ http://issues.apache.org/jira/browse/VELOCITY-460?page=comments#action_12437452 ] Will Glass-Husain commented on VELOCITY-460: nice catch! would you mind fixing the unit test to check this case as well? if you have time to do this, I'll apply it immediately. the IncludeRelativePath handler should treat paths beginning with a slash as absolute paths --- Key: VELOCITY-460 URL: http://issues.apache.org/jira/browse/VELOCITY-460 Project: Velocity Issue Type: Improvement Components: Source Affects Versions: 1.5 beta1 Reporter: Claude Brisson Priority: Minor Attachments: IncludeRelativePath.patch The most widely spread convention about systems supporting relative paths is that paths that begin with '/' (or '\') are absolute while others are relative. The IncludeRelativePath event handler should follow the same convention. The corrective patch is attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: [EMAIL PROTECTED]: Project jakarta-velocity-test (in module jakarta-velocity) failed
: cannot find symbol [javac] symbol : class jdbcDriver [javac] location: class org.apache.velocity.test.sql.HsqlDataSource [javac] Class.forName(jdbcDriver.class.getName()); [javac] ^ [javac] Note: /x1/gump/public/workspace/jakarta-velocity/bin/test-src/org/apache/velocity/test/VelocityServletTestCase.java uses or overrides a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. [javac] 4 errors BUILD FAILED /x1/gump/public/workspace/jakarta-velocity/build/build.xml:271: Compile failed; see the compiler error output for details. Total time: 5 seconds - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/jakarta-velocity/jakarta-velocity-test/rss.xml - Atom: http://vmgump.apache.org/gump/public/jakarta-velocity/jakarta-velocity-test/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2024092006, vmgump.apache.org:vmgump-public:2024092006 Gump E-mail Identifier (unique within run) #20. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] Move Velocity to TLP
Wow. Skip email for a day and there's a blizzard. I take Geir's comments pretty seriously though. To me, the most important part of this is the opportunity to grow the developer community. That's easy to say, of course. Technically, any committer in Jakarta now has svn commit rights to Velocity, and it hasn't seemed to make a difference. But by encouraging carefully selected projects to join the Velocity TLP, I think we'd see more energy and effort around Velocity core itself. What are those projects - how do we grow them - worthy of a separate thread. Process point -- should we put the vote on hold for a few days until we can discuss this and resolve Geir's -1? Best, WILL Maybe we can On 9/23/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Right - moving to TLP doesn't make a difference there, other than the plan to bring in velocity related things into the project, which grows the commiter base. geir Nathan Bubna wrote: No, that is not basically the reason. On 9/22/06, Daniel Dekany [EMAIL PROTECTED] wrote: Saturday, September 23, 2006, 1:02:35 AM, Geir Magnusson Jr wrote: This vote closed sooner than expected. I was traveling and there was no stated deadline. [snip] So, Velocity will be TLP. Now, somebody correct me if I get it wrong, but is the reason basically that its developer community was not active enough, and being TLP would help to fix this situation? -- Best regards, Daniel Dekany - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VELOCITY-459) localscope doesn't allow get to leak
[ http://issues.apache.org/jira/browse/VELOCITY-459?page=all ] Will Glass-Husain resolved VELOCITY-459. Resolution: Fixed patch applied. thanks again. revision #449333. localscope doesn't allow get to leak Key: VELOCITY-459 URL: http://issues.apache.org/jira/browse/VELOCITY-459 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.5 Reporter: Stephen Haberman Assigned To: Will Glass-Husain Priority: Minor Fix For: 1.5 Attachments: localscopeGetFix.diff In short, we wanted localscope on for macros due to some recursion. However, this meant that both puts /and/ gets only use the localscope. For gets this seems overly restrictive--if I set foo=bar in my base VelocityContext, and then get into my macro, it should be able to reach that foo even if it can't overwrite it. The attached patch relaxes the VMContext.get to let it check first the local scope and then the inner scope. Included is a test that makes sure an outsideVar is accessible from VMContext even if localscope is on. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VELOCITY-453) [PATCH] Fix IntrospectionCacheData caching
[ http://issues.apache.org/jira/browse/VELOCITY-453?page=all ] Will Glass-Husain resolved VELOCITY-453. Resolution: Fixed applied this patch. I'm a little shocked that this was broken. Though a subtle bug, it's a fundamental part of template processing. Many thanks for catching this and contributing a patch and unit test. Nicely done. r449347 [PATCH] Fix IntrospectionCacheData caching -- Key: VELOCITY-453 URL: http://issues.apache.org/jira/browse/VELOCITY-453 Project: Velocity Issue Type: Bug Components: Source Affects Versions: 1.5 Reporter: Alexey Panchenko Assigned To: Will Glass-Husain Fix For: 1.5 Attachments: ASTMethod_IntrospectionCacheData_cache, ASTMethod_IntrospectionCacheData_cache-v2-retry.patch, ASTMethod_IntrospectionCacheData_cache-v2.patch, IntrospectionCacheDataTest-no-copyright.java, IntrospectionCacheDataTest-no-copyright.java, IntrospectionCacheDataTest-v4.java, IntrospectionCacheDataTest.java The old code used Class[].hashCode() in MethodCacheKey.hashCode() implementation. hashCode() is not overriden for arrays so it returns different value for each array instance. The attached is the correct implementation and a test case to prove the caching actually works. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VELOCITY-122) 33 warnings when doing ant javadocs
[ http://issues.apache.org/jira/browse/VELOCITY-122?page=all ] Will Glass-Husain resolved VELOCITY-122. Resolution: Fixed resolving this old issue. the build process is very different now, the javadocs have been updated to remove most inconsistencies and errors. 33 warnings when doing ant javadocs - Key: VELOCITY-122 URL: http://issues.apache.org/jira/browse/VELOCITY-122 Project: Velocity Issue Type: Bug Components: Documentation Affects Versions: 1.3-rc1 Environment: Operating System: All Platform: PC Reporter: Ralf Hauser Attachments: javadocs030110a.log will attach the output -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (VELOCITY-423) Report invalid references
[ http://issues.apache.org/jira/browse/VELOCITY-423?page=all ] Will Glass-Husain reassigned VELOCITY-423: -- Assignee: Will Glass-Husain Report invalid references - Key: VELOCITY-423 URL: http://issues.apache.org/jira/browse/VELOCITY-423 Project: Velocity Issue Type: New Feature Components: Source Reporter: Will Glass-Husain Assigned To: Will Glass-Husain Fix For: 1.5 Attachments: invalidreference.txt I've made a new patch that includes a ReferenceInsertionEventHandler (InvalidReferenceHandler) that collects a list of all invalid references in a Velocity page. To see how it works, look at the test code (the last two methods) in BuiltInEventHandlerTestCase. To make this work, I had to make some changes to the internals. So I thought I'd hold off a couple days before committing, let any interested parties comment. There's a couple of interesting new pieces for plugin writers. (1) In any user-defined plugin (event handlers, uberspectors, etc) you can now throw a subclass of VelocityRuntimeException (new exception). to signal unrecoverable states to the calling application. This runtime exception requires no change to the interface signature and is passed through the Velocity parsing process. (In the past, all Exceptions were caught and logged). Example use: a custom uberspector or event handler that wishes to stop page processing. For example, the InvalidReferenceHandler can be configured to throw an exception at the first reference error. (2) Event handlers can now receive information on the template name, line number, and column by implementing InfoAware. This only works for Local event handlers attached to a context (as opposed to the new Global type defined in Velocity properties). Example use: InvalidReferenceHandler reports out the line,column, and template name of each reference error. Everything is completely backwards compatible. It'd be simpler if it wasn't of course as they we could just redo the interfaces. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-459) localscope doesn't allow get to leak
[ http://issues.apache.org/jira/browse/VELOCITY-459?page=comments#action_12436445 ] Will Glass-Husain commented on VELOCITY-459: Thanks for reporting this and submitting a patch. Does ant test pass? We should get this into 1.5. Is this related to Velocity-262? localscope doesn't allow get to leak Key: VELOCITY-459 URL: http://issues.apache.org/jira/browse/VELOCITY-459 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.5 Reporter: Stephen Haberman Fix For: 1.5 Attachments: localscopeGetFix.diff In short, we wanted localscope on for macros due to some recursion. However, this meant that both puts /and/ gets only use the localscope. For gets this seems overly restrictive--if I set foo=bar in my base VelocityContext, and then get into my macro, it should be able to reach that foo even if it can't overwrite it. The attached patch relaxes the VMContext.get to let it check first the local scope and then the inner scope. Included is a test that makes sure an outsideVar is accessible from VMContext even if localscope is on. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VELOCITY-459) localscope doesn't allow get to leak
[ http://issues.apache.org/jira/browse/VELOCITY-459?page=all ] Will Glass-Husain updated VELOCITY-459: --- Fix Version/s: 1.5 Priority: Minor (was: Major) localscope doesn't allow get to leak Key: VELOCITY-459 URL: http://issues.apache.org/jira/browse/VELOCITY-459 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.5 Reporter: Stephen Haberman Priority: Minor Fix For: 1.5 Attachments: localscopeGetFix.diff In short, we wanted localscope on for macros due to some recursion. However, this meant that both puts /and/ gets only use the localscope. For gets this seems overly restrictive--if I set foo=bar in my base VelocityContext, and then get into my macro, it should be able to reach that foo even if it can't overwrite it. The attached patch relaxes the VMContext.get to let it check first the local scope and then the inner scope. Included is a test that makes sure an outsideVar is accessible from VMContext even if localscope is on. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (VELOCITY-459) localscope doesn't allow get to leak
[ http://issues.apache.org/jira/browse/VELOCITY-459?page=all ] Will Glass-Husain reassigned VELOCITY-459: -- Assignee: Will Glass-Husain localscope doesn't allow get to leak Key: VELOCITY-459 URL: http://issues.apache.org/jira/browse/VELOCITY-459 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.5 Reporter: Stephen Haberman Assigned To: Will Glass-Husain Priority: Minor Fix For: 1.5 Attachments: localscopeGetFix.diff In short, we wanted localscope on for macros due to some recursion. However, this meant that both puts /and/ gets only use the localscope. For gets this seems overly restrictive--if I set foo=bar in my base VelocityContext, and then get into my macro, it should be able to reach that foo even if it can't overwrite it. The attached patch relaxes the VMContext.get to let it check first the local scope and then the inner scope. Included is a test that makes sure an outsideVar is accessible from VMContext even if localscope is on. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-459) localscope doesn't allow get to leak
[ http://issues.apache.org/jira/browse/VELOCITY-459?page=comments#action_12436449 ] Will Glass-Husain commented on VELOCITY-459: Reviewed the patch. Looks fine to me. (Minor formatting issues with the braces in the unit test). Will apply. localscope doesn't allow get to leak Key: VELOCITY-459 URL: http://issues.apache.org/jira/browse/VELOCITY-459 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.5 Reporter: Stephen Haberman Assigned To: Will Glass-Husain Priority: Minor Fix For: 1.5 Attachments: localscopeGetFix.diff In short, we wanted localscope on for macros due to some recursion. However, this meant that both puts /and/ gets only use the localscope. For gets this seems overly restrictive--if I set foo=bar in my base VelocityContext, and then get into my macro, it should be able to reach that foo even if it can't overwrite it. The attached patch relaxes the VMContext.get to let it check first the local scope and then the inner scope. Included is a test that makes sure an outsideVar is accessible from VMContext even if localscope is on. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: release occurred?
Nice job writing this up. I'm impressed with the detail. WILL On 9/18/06, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Will Glass-Husain [EMAIL PROTECTED] writes: It's a beta and it is available from http://cvs.apache.org/dist/jakarta/velocity/ as described here: http://wiki.apache.org/jakarta-velocity/ReleaseProcess Yes, it is still missing from the announce / download pages. Sorry for that. Best regards Henning Hi, Has the Velocity release occurred or is it still in process? I looked in the obvious places for info... our home page, the downloads page, the Wiki news page. Am I right in assuming we're still in the middle of this? Just wondering. Best, Will -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Social behaviour: Bavarians can be extremely egalitarian and folksy. -- http://en.wikipedia.org/wiki/Bavaria Most Franconians do not like to be called Bavarians. -- http://en.wikipedia.org/wiki/Franconia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
release occurred?
Hi, Has the Velocity release occurred or is it still in process? I looked in the obvious places for info... our home page, the downloads page, the Wiki news page. Am I right in assuming we're still in the middle of this? Just wondering. Best, Will -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: release occurred?
Did we make a binary or just a source downloadable? Where can the files be downloaded from? I'm looking forward to no longer telling users that bug has been fixed in 1.5 unreleased, please download source control head. WILL On 9/17/06, Nathan Bubna [EMAIL PROTECTED] wrote: Since it is only a beta release, i don't believe we should mirror it. That is, unless we really think it will be a big hit on ASF infrastructure to not mirror it. So i don't think this should be on the download page. It should, however, probably be put up on the home page and the wiki news page... if no one beats me to it, i'll try to update at least the wiki tomorrow. Right now bed is calling... :) On 9/17/06, Will Glass-Husain [EMAIL PROTECTED] wrote: Hi, Has the Velocity release occurred or is it still in process? I looked in the obvious places for info... our home page, the downloads page, the Wiki news page. Am I right in assuming we're still in the middle of this? Just wondering. Best, Will -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - 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] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r446865 - /jakarta/velocity/engine/trunk/src/test/org/apache/velocity/test/AbsoluteFileResourceLoaderTestCase.java
Ouch! What was I thinking?
I think I must have been debugging the unit test and put the
System.exit line in to force a stop. (then forgotten to take it out).
WILL
On 9/16/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: henning
Date: Sat Sep 16 05:25:11 2006
New Revision: 446865
URL: http://svn.apache.org/viewvc?view=revrev=446865
Log:
System.exit(1) might be a bit harsh...
Modified:
jakarta/velocity/engine/trunk/src/test/org/apache/velocity/test/AbsoluteFileResourceLoaderTestCase.java
Modified:
jakarta/velocity/engine/trunk/src/test/org/apache/velocity/test/AbsoluteFileResourceLoaderTestCase.java
URL:
http://svn.apache.org/viewvc/jakarta/velocity/engine/trunk/src/test/org/apache/velocity/test/AbsoluteFileResourceLoaderTestCase.java?view=diffrev=446865r1=446864r2=446865
==
---
jakarta/velocity/engine/trunk/src/test/org/apache/velocity/test/AbsoluteFileResourceLoaderTestCase.java
(original)
+++
jakarta/velocity/engine/trunk/src/test/org/apache/velocity/test/AbsoluteFileResourceLoaderTestCase.java
Sat Sep 16 05:25:11 2006
@@ -87,9 +87,7 @@
}
catch (Exception e)
{
-System.err.println(Cannot setup AbsoluteFileResourceLoaderTest!);
-e.printStackTrace();
-System.exit(1);
+fail(Cannot setup AbsoluteFileResourceLoaderTest!);
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Forio Business Simulations
Will Glass-Husain
[EMAIL PROTECTED]
www.forio.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Move Velocity to TLP
[X] +1 I support the proposal [ ] +0 I don't care [ ] -1 I'm opposed to the proposal because... !! Best, WILL On 9/15/06, Nathan Bubna [EMAIL PROTECTED] wrote: The Velocity project has for some time now been making plans for a proposal to the board that the Velocity projects leave the Jakarta umbrella and become their own top level project. Martin has asked us to hold a vote on the proposal here before he passes it along to the board. So... The proposal is available for your perusal at: http://wiki.apache.org/jakarta/TLPVelocity For the interested, most of the discussion took place on the following thread: http://marc.theaimsgroup.com/?t=11553094014r=1w=2 And the vote happens here: [ ] +1 I support the proposal [ ] +0 I don't care [ ] -1 I'm opposed to the proposal because... Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r446850 - in /jakarta/velocity/engine/trunk/src/java/org/apache/velocity/runtime: directive/ log/ parser/node/
==
---
jakarta/velocity/engine/trunk/src/java/org/apache/velocity/runtime/parser/node/ASTOrNode.java
(original)
+++
jakarta/velocity/engine/trunk/src/java/org/apache/velocity/runtime/parser/node/ASTOrNode.java
Sat Sep 16 03:34:39 2006
@@ -57,7 +57,8 @@
public Object value(InternalContextAdapter context )
throws MethodInvocationException
{
-return new Boolean( evaluate( context ) );
+// TODO: JDK 1.4+ - valueOf()
+return new Boolean(evaluate(context));
}
/**
Modified:
jakarta/velocity/engine/trunk/src/java/org/apache/velocity/runtime/parser/node/MathUtils.java
URL:
http://svn.apache.org/viewvc/jakarta/velocity/engine/trunk/src/java/org/apache/velocity/runtime/parser/node/MathUtils.java?view=diffrev=446850r1=446849r2=446850
==
---
jakarta/velocity/engine/trunk/src/java/org/apache/velocity/runtime/parser/node/MathUtils.java
(original)
+++
jakarta/velocity/engine/trunk/src/java/org/apache/velocity/runtime/parser/node/MathUtils.java
Sat Sep 16 03:34:39 2006
@@ -170,6 +170,7 @@
}
else
{
+// TODO: JDK 1.4+ - valueOf()
return new Byte ((byte)value);
}
}
@@ -181,6 +182,7 @@
}
else
{
+// TODO: JDK 1.4+ - valueOf()
return new Short((short)value);
}
}
@@ -192,11 +194,13 @@
}
else
{
+// TODO: JDK 1.4+ - valueOf()
return new Integer ((int)value);
}
}
if (type == Long.class)
{
+// TODO: JDK 1.4+ - valueOf()
return new Long (value);
}
return BigInteger.valueOf( value);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Forio Business Simulations
Will Glass-Husain
[EMAIL PROTECTED]
www.forio.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-458) InternalContextBase defines non-serializable non-transient fields
[ http://issues.apache.org/jira/browse/VELOCITY-458?page=comments#action_12435242 ] Will Glass-Husain commented on VELOCITY-458: so what's the current behavior? If someone serializes a VelocityContext object does it throw an exception? Hard to see what's right here. Option c is terrible -- it's a hidden change to the context state. My preference is (a) make Resource/Event Cartridge serializable (recognizing this is a pain) (b) remove Serializable (since it doesn't work anyway) InternalContextBase defines non-serializable non-transient fields - Key: VELOCITY-458 URL: http://issues.apache.org/jira/browse/VELOCITY-458 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.5 beta1 Reporter: Henning Schmiedehausen Fix For: 1.5 According to Findbugs, org.apache.velocity.context.InternalContextBase defines currentResource and eventCartridge as non-serializable, non-transient in a serializable class. Possible solutions: a) make Resource and EventCartridge serializable (might drag a large number of classes along) b) remove Serializable from InternalContextBase (does the Context get serialized somewhere? Is it needed for e.g. Web Applications?) c) make the fields transient, losing their contents after serialization / de-serialization. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Move Velocity to TLP
I'd forgotten that. For the record, I think my prediction was that Henning would become an ASF officer sometime in the next year or two, which as VP of Velocity he will be. Anyway, the plan sounds great. We probably need a formal vote at some point. When is that? Nathan, I'll let you call for it at the right stage. I suggest we think about (informal) 6 month or 1 year terms and rotate among involved committers. That will allow us to share the workload a bit. My impression this mostly involves reports to the board, Velocity advocacy, and general community-building activities. Not that one needs to be a chair to do the last two. Best, WILL On 9/15/06, Nathan Bubna [EMAIL PROTECTED] wrote: Excellent! I wouldn't want Will to be wrong. :) I'll update the draft to propose you as our first chair. Now, since no one has made any other critiques/comments on it, i'm guessing it must be good to go. What's the next step? Martin, do you take this to the board for us? On 9/15/06, Henning Schmiedehausen [EMAIL PROTECTED] wrote: Ah well, why not? It would actually fulfill Wills' prediction from a few months ago. And as you said I have no time is not exactly a valid excuse around here... :-) Best regards Henning Nathan Bubna schrieb: Ok, thinking about where i want to put my time here... With Velocity 1.5 approaching and a Struts 1.3.5 being declared GA shortly (as well as all the Struts 2 work), i want to upgrade VelocityStruts and try to get a VelocityTools 1.3 out this winter (Marino, are you out there? Can you help?) So, Henning or Will, if either of you are willing to take the first stint as Velocity chair; that would free up a lot more time to get VelocityTools up to speed. If you're not, then i'll do it, and we might just have to wait a bit longer for VelocityTools 1.3. Whaddaya think? Either of you wanna volunteer? Henning, you started this TLP push; wanna take the reins first? :) On 9/13/06, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Will Glass-Husain [EMAIL PROTECTED] writes: Ha. Knew you were going to get in trouble for doing the legwork, Nathan. I'd definitely support that. Or Henning would be great too. +1 If Nathan wants to do it: More power to Nathan! Best regards Henning If we wanted to rotate it every 6 months, I'd be happy to take a turn. But maybe a little later rather than being first. WILL On 9/11/06, Martin van den Bemt [EMAIL PROTECTED] wrote: Hi Nathan, Looks ok and I would definitely let general know (although you did put this on the wiki). Also it would be nice to see a name of the chair. Any chance of your name being there ? (or you could have a vote on that) Mvgr, Martin Nathan Bubna wrote: Sorry this took so long... http://wiki.apache.org/jakarta/TLPVelocity Establish the Apache Velocity Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to the Velocity template engine, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Velocity PMC, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Velocity PMC be and hereby is responsible for the creation and maintenance of software related to the Velocity template engine; and be it further RESOLVED, that the office of Vice President, Velocity be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Velocity PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Velocity PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Velocity PMC: * Will Glass-Husain ([MAILTO] [MAILTO] [EMAIL PROTECTED]) * Geir Magnusson Jr. ([MAILTO] [MAILTO] [EMAIL PROTECTED]) * Daniel L. Rall ([MAILTO] [MAILTO] [EMAIL PROTECTED]) * Henning Schmiedehausen ([MAILTO] [MAILTO] [EMAIL PROTECTED]) * Nathan Bubna ([MAILTO] [MAILTO] [EMAIL PROTECTED]) * Marinó A. Jónsson ([MAILTO] [MAILTO] [EMAIL PROTECTED]) NOW, THEREFORE, BE IT FURTHER RESOLVED, that X be appointed to the office of Vice President, Velocity, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation
Re: [Proposal] Move Velocity to TLP
Sure, now seems the right time. Or sometime soon. On 9/15/06, Nathan Bubna [EMAIL PROTECTED] wrote: On 9/15/06, Will Glass-Husain [EMAIL PROTECTED] wrote: I'd forgotten that. For the record, I think my prediction was that Henning would become an ASF officer sometime in the next year or two, which as VP of Velocity he will be. Anyway, the plan sounds great. We probably need a formal vote at some point. When is that? Nathan, I'll let you call for it at the right stage. how should i know what the right stage is? :) i think the proposal is sound. is now the right time? more importantly, where should the formal vote take place? [EMAIL PROTECTED] I suggest we think about (informal) 6 month or 1 year terms and rotate among involved committers. That will allow us to share the workload a bit. My impression this mostly involves reports to the board, Velocity advocacy, and general community-building activities. Not that one needs to be a chair to do the last two. Best, WILL On 9/15/06, Nathan Bubna [EMAIL PROTECTED] wrote: Excellent! I wouldn't want Will to be wrong. :) I'll update the draft to propose you as our first chair. Now, since no one has made any other critiques/comments on it, i'm guessing it must be good to go. What's the next step? Martin, do you take this to the board for us? On 9/15/06, Henning Schmiedehausen [EMAIL PROTECTED] wrote: Ah well, why not? It would actually fulfill Wills' prediction from a few months ago. And as you said I have no time is not exactly a valid excuse around here... :-) Best regards Henning Nathan Bubna schrieb: Ok, thinking about where i want to put my time here... With Velocity 1.5 approaching and a Struts 1.3.5 being declared GA shortly (as well as all the Struts 2 work), i want to upgrade VelocityStruts and try to get a VelocityTools 1.3 out this winter (Marino, are you out there? Can you help?) So, Henning or Will, if either of you are willing to take the first stint as Velocity chair; that would free up a lot more time to get VelocityTools up to speed. If you're not, then i'll do it, and we might just have to wait a bit longer for VelocityTools 1.3. Whaddaya think? Either of you wanna volunteer? Henning, you started this TLP push; wanna take the reins first? :) On 9/13/06, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Will Glass-Husain [EMAIL PROTECTED] writes: Ha. Knew you were going to get in trouble for doing the legwork, Nathan. I'd definitely support that. Or Henning would be great too. +1 If Nathan wants to do it: More power to Nathan! Best regards Henning If we wanted to rotate it every 6 months, I'd be happy to take a turn. But maybe a little later rather than being first. WILL On 9/11/06, Martin van den Bemt [EMAIL PROTECTED] wrote: Hi Nathan, Looks ok and I would definitely let general know (although you did put this on the wiki). Also it would be nice to see a name of the chair. Any chance of your name being there ? (or you could have a vote on that) Mvgr, Martin Nathan Bubna wrote: Sorry this took so long... http://wiki.apache.org/jakarta/TLPVelocity Establish the Apache Velocity Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to the Velocity template engine, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Velocity PMC, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Velocity PMC be and hereby is responsible for the creation and maintenance of software related to the Velocity template engine; and be it further RESOLVED, that the office of Vice President, Velocity be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Velocity PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Velocity PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Velocity PMC: * Will Glass-Husain ([MAILTO] [MAILTO] [EMAIL PROTECTED]) * Geir Magnusson Jr. ([MAILTO] [MAILTO] [EMAIL PROTECTED
[jira] Commented: (VELOCITY-251) $\!{foo} doesn't render as expected
[
http://issues.apache.org/jira/browse/VELOCITY-251?page=comments#action_12434308
]
Will Glass-Husain commented on VELOCITY-251:
From the mailing list (excerpt)
-- Forwarded message --
From: sun davy [EMAIL PROTECTED]
Date: Sep 11, 2006 3:51 AM
Subject: i encounter some mistakes in User Guide.
To: velocity-user@jakarta.apache.org
hi Velocity team:
I am an user of Velocity from China. Thanks for your perfect production.
Through your creative and hard work, we have such Convenience and Powerful
tools in our toolbox.
...
2) Advanced Issues: Escaping and !
#set( $foo = bar )
$\!foo
$\!{foo}
$\\!foo
$\\\!foo
This renders as:
$!foo
$!{foo}
$\!foo
$\\!foo
My output is:
$!foo
$!{
$\!foo
$\\!foo
i was confused.
---
Contrast this with regular escaping, where \ precedes $:
\$foo
\$!foo
\$!{foo}
\\$!{foo}
This renders as:
\$foo
\$!foo
\$!{foo}
\bar
My output is:
$foo
$!foo
$!{foo}
\bar
it seems like clerical error.
...
$\!{foo} doesn't render as expected
---
Key: VELOCITY-251
URL: http://issues.apache.org/jira/browse/VELOCITY-251
Project: Velocity
Issue Type: Bug
Components: Source
Affects Versions: 1.5
Environment: Operating System: other
Platform: Other
Reporter: JiaYun
Fix For: 1.5
Aaccording to the User Guide, $\!{foo} should render as $!{foo}, but the
actual output is $!{ whether $foo was defined or not.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Move Velocity to TLP
Ha. Knew you were going to get in trouble for doing the legwork, Nathan. I'd definitely support that. Or Henning would be great too. If we wanted to rotate it every 6 months, I'd be happy to take a turn. But maybe a little later rather than being first. WILL On 9/11/06, Martin van den Bemt [EMAIL PROTECTED] wrote: Hi Nathan, Looks ok and I would definitely let general know (although you did put this on the wiki). Also it would be nice to see a name of the chair. Any chance of your name being there ? (or you could have a vote on that) Mvgr, Martin Nathan Bubna wrote: Sorry this took so long... http://wiki.apache.org/jakarta/TLPVelocity Establish the Apache Velocity Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to the Velocity template engine, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Velocity PMC, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Velocity PMC be and hereby is responsible for the creation and maintenance of software related to the Velocity template engine; and be it further RESOLVED, that the office of Vice President, Velocity be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Velocity PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Velocity PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Velocity PMC: * Will Glass-Husain ([MAILTO] [MAILTO] [EMAIL PROTECTED]) * Geir Magnusson Jr. ([MAILTO] [MAILTO] [EMAIL PROTECTED]) * Daniel L. Rall ([MAILTO] [MAILTO] [EMAIL PROTECTED]) * Henning Schmiedehausen ([MAILTO] [MAILTO] [EMAIL PROTECTED]) * Nathan Bubna ([MAILTO] [MAILTO] [EMAIL PROTECTED]) * Marinó A. Jónsson ([MAILTO] [MAILTO] [EMAIL PROTECTED]) NOW, THEREFORE, BE IT FURTHER RESOLVED, that X be appointed to the office of Vice President, Velocity, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Velocity PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Velocity Project; and be it further RESOLVED, that the initial Velocity PMC be and hereby is tasked with the migration and rationalization of the Apache Jakarta Velocity, Velocity Tools and DVSL subprojects; and be it further RESOLVED, that all responsibility pertaining to the Jakarta Velocity, Velocity Tools, and DVSL subprojects and encumbered upon the Apache Jakarta PMC are hereafter discharged. How's it look? Did i miss anything? Should we ping [EMAIL PROTECTED] to let anyone who wants to join the initial PMC get on board? Since all Jakarta committers have perms for Velocity now, i don't want to inadvertently exclude anyone who wanted to work on Velocity but hadn't yet. On 8/31/06, Martin van den Bemt [EMAIL PROTECTED] wrote: I assume you already saw the proposals on the jakarta wiki (for slide testing), so you can use those as a template :) Mvgr, Martin Nathan Bubna wrote: Yeah, it is. My apologies. I ran out of free time with family in town and getting my house ready to be painted. :) I'll try to get this moving again by early next week. On 8/26/06, Martin van den Bemt [EMAIL PROTECTED] wrote: Maybe it's time to summarize and create the official proposal ? Mvgr, Martin Martin van den Bemt wrote: Apologies for totally missing / ignoring / forgetting the word may... Mvgr, Martin Nathan Bubna wrote: On 8/26/06, Martin van den Bemt [EMAIL PROTECTED] wrote: Huh?? The only related statement of mine was not in my initial proposal and is really not far from what you're saying. I quote (with key words emphasized), - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
Re: Re[2]: How can I get commit access?
FYI. We're having a discussion on [EMAIL PROTECTED] about the JIRA system. No news on that yet. WILL On 9/7/06, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Alexey Panchenko [EMAIL PROTECTED] writes: Will Glass-Husain wrote: It's also a big plus if you are active on the user list helping people out. Is it the mandatory requirement ? No. If you want to contribute to Velocity (or to any other Apache project), you should understand, that Apache works in the way of a meritocracy, see http://www.apache.org/foundation/how-it-works.html#meritocracy Joining the user list and helping users out is a way to show the community that you are interested in a long-term contribution to Velocity and know your way around. Which builds merit... ...you get the picture. :-) Velocity is a special case here, because all of us are very reluctant to apply patches just so. If a patch sits in the Tracker for a long time, chances are that there is a reason why it wasn't applied and the original author wasn't interested to amend the original contribution. A week is not a long time, BTW. Here is, what IMHO helps you to convince a committer to apply your patch (at least that's what works for me): - Describe the issue. Give a test case where a problem is and how your patch changes the problem - Give unit tests - Make sure that your patch adheres to the Velocity coding guidelines (which are basically non-existent but we do have some at http://wiki.apache.org/jakarta-velocity/CodeStandards - Give unit tests - Show that your patch doesn't only scratch your need but helps everyone. Understand, that the current committers are very reluctant to apply patches to Velocity because we care a lot about backwards compatibility. - Make sure that all existing Unit test still pass with your patch applied. - And last, but not least, give unit tests. Best is a test that fails before you applied the patch and passes afterwards. Best regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Social behaviour: Bavarians can be extremely egalitarian and folksy. -- http://en.wikipedia.org/wiki/Bavaria Most Franconians do not like to be called Bavarians. -- http://en.wikipedia.org/wiki/Franconia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-284) MethodInvocationException is handled inconsistently
[
http://issues.apache.org/jira/browse/VELOCITY-284?page=comments#action_12432847
]
Will Glass-Husain commented on VELOCITY-284:
Question
-- are there any good backwards-compatibility arguments against making
VelocityException based on a RuntimeException?
MethodInvocationException is handled inconsistently
---
Key: VELOCITY-284
URL: http://issues.apache.org/jira/browse/VELOCITY-284
Project: Velocity
Issue Type: Improvement
Components: Source
Affects Versions: 1.4, 1.5
Environment: Operating System: All
Platform: Other
Reporter: Mike Rettig
Priority: Minor
Fix For: 2.0, 1.6
Attachments: swallowed_exception.txt
It appears that the exception handling is different depending on whether the
method is invoked as a passed parameter to a velocimacro or just in a
template.
Ex.
#doTextLink( ${myObj.exception})
${myObj.exception}
The first #doTextLink macro will throw an exception, but it will be logged and
ignored. However, the second invocation will throw the exception properly.
I have a patch that should fix this behavior. The exception just needs to be
rethrown up the call stack. A small signature change to a couple of methods.
Thanks,
Mike Rettig
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-179) prevent execution of methods on Class, ClassLoader and related classes
[ http://issues.apache.org/jira/browse/VELOCITY-179?page=comments#action_12432854 ] Will Glass-Husain commented on VELOCITY-179: Actually, I've recently cleaned this up a bit. Maybe we can even just include it as an alternate uberspector. Patch coming later today. prevent execution of methods on Class, ClassLoader and related classes -- Key: VELOCITY-179 URL: http://issues.apache.org/jira/browse/VELOCITY-179 Project: Velocity Issue Type: Improvement Components: Source Affects Versions: 1.4 Environment: Operating System: All Platform: All Reporter: Will Glass-Husain Assigned To: Will Glass-Husain Priority: Minor Fix For: 1.6 Attachments: IntrospectorTestCase4.java, patch1.txt, patch2.txt, patch2b.txt, testcases.xml.patch Template designers currently have the capability to acquire a ClassLoader, instantiate an arbitrary class, and call an arbitrary method. (Example: [1], although more compact examples exist). This is a drastic break with the MVC model, as template designers can execute any arbitary code. It gets worse if you have untrusted template designers who might call methods that erase files, execute arbitrary SQL code, or shut down the VM. This has been discussed on the dev list [2]. This patch prevents any method from being called on objects of a class that has reflection, classloader, or runtime capabilities. (List at the end of the report [4]). It's configurable with a property, but the default is ON, as security restrictions, IMHO, should be strict by default. An alternate solution to this issue would be to prohibit the ClassLoader through the Java Security Manager, as proposed here [4]. I believe this solution to be too difficult for the typical developer. It's complex, and requires knowledge of the Velocity source code. Essentially, you have to split the files that execute the methods on the Java classes into a separate JAR file, then designate that jar file as not have permission to call getClassLoader. This requires that you (A) know what those Velocity classes are (B) understand how to work with the security manager, which is quite complex, and (C) have to modify the Velocity package every time there is a new release. I think it would be better if this is handled natively within Velocity. Finally, this patch does not include docs or test cases. I'd be willing to write both, if a committer is willing to put in the patch. [1] Example of VTL to call arbitray method http://nagoya.apache.org/eyebrowse/ReadMsg?listName=velocity- [EMAIL PROTECTED]msgNo=6114 [2] Related discussion http://nagoya.apache.org/eyebrowse/ReadMsg?listId=102msgNo=5980 http://nagoya.apache.org/eyebrowse/ReadMsg?listName=velocity- [EMAIL PROTECTED]msgNo=10444 [3] Classes affected java.lang.Class java.lang.ClassLoader java.lang.Compiler java.lang.Package java.lang.Process java.lang.InheritableThreadLocal java.lang.Runtime java.lang.RuntimePermission java.lang.SecurityManager java.lang.System java.lang.Thread java.lang.ThreadGroup java.lang.ThreadLocal java.lang.reflect.* [4] Java security manager proposal http://nagoya.apache.org/eyebrowse/ReadMsg?listName=velocity- [EMAIL PROTECTED]msgNo=6012 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-453) [PATCH] Fix IntrospectionCacheData caching
[ http://issues.apache.org/jira/browse/VELOCITY-453?page=comments#action_12432856 ] Will Glass-Husain commented on VELOCITY-453: Hi Alexey, Looks great, thanks for submitting. Appreciate your attention to detail with code conventions as well, makes it easier to read. Two minor comments. (1) in the equals method, shouldn't the line if (params[i] != other.params[i]) use the equals method instead? (2) Sorry to bug you on this, but we need you to resubmit IntrospectionCacheDataTest.java without the copyright notice. You still retain ownership of the code, but copyright notices need to go in a project-wide NOTICES file. (more info at: http://www.apache.org/legal/src-headers.html) When you have a chance to resubmit, I'll commit. [PATCH] Fix IntrospectionCacheData caching -- Key: VELOCITY-453 URL: http://issues.apache.org/jira/browse/VELOCITY-453 Project: Velocity Issue Type: Bug Components: Source Affects Versions: 1.5 Reporter: Alexey Panchenko Assigned To: Will Glass-Husain Fix For: 1.5 Attachments: ASTMethod_IntrospectionCacheData_cache, ASTMethod_IntrospectionCacheData_cache-v2-retry.patch, ASTMethod_IntrospectionCacheData_cache-v2.patch, IntrospectionCacheDataTest.java The old code used Class[].hashCode() in MethodCacheKey.hashCode() implementation. hashCode() is not overriden for arrays so it returns different value for each array instance. The attached is the correct implementation and a test case to prove the caching actually works. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Opinion poll: Build an RC
Hi, Just back from vacation, see a blizzard of JIRA activity. Go, Henning! I think we should do a release, but do not think we should call it Release Candidate / RC. To me, a RC is ready to go, no open bugs, no missing docs. We're close but not there. Let's do a release and call it a beta. We had a discussion about doing this a long time ago. Maybe set a date for final tweaks, i.e. Friday the 15th? Could provide a little incentive to commit VELOCITY-422 (has patch), VELOCITY-453 (has patch, needs tweak), VELOCITY-132 (has patch, needs tweak). So, -1 to RC. But a counter proposal of Velocity 1.5-beta occurring shortly after 9/15. WILL On 9/5/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Just do an RC, and then add more things, and then do 1.6... Just do it. geir Henning P. Schmiedehausen wrote: Hi, as we are dragging the 1.5 release out: How about cutting an RC? A version that is basically code complete but some docs missing. Are there any pending JIRA issues that absolutely should be in? [ ] +1 RC is cool. [ ] 0 I don't care. [ ] -1 No we still have show stoppers (please elaborate). I'll collect votes till thursday. Best regards Henning - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-449) Velocity Uberspector behaves differently for get(String) and put(String, Object) methods
[
http://issues.apache.org/jira/browse/VELOCITY-449?page=comments#action_12432863
]
Will Glass-Husain commented on VELOCITY-449:
ah, forgot that get(string) is not a javabean semantic.
ok, makes sense. in general, I agree that we should keep things easy for users
rather than force rules on them. I withdraw my objection.
Velocity Uberspector behaves differently for get(String) and put(String,
Object) methods
Key: VELOCITY-449
URL: http://issues.apache.org/jira/browse/VELOCITY-449
Project: Velocity
Issue Type: Bug
Affects Versions: 1.5
Reporter: Henning Schmiedehausen
Fix For: 1.5
Consider an Object
public class Test {
private Object foo;
public Object get(String dummy) { return foo; }
public void put(String dummy, Object foo) { this.foo = foo };
}
Put this object into a Velocity Context as $test, add a HashMap as $map.
Use the following template:
$map.put(key, val1)
$test.put(key, val1)
$map.get(key) -- Returns val1
$test.get(key) -- Returns val1
$map.key -- Returns val1
$test.key -- Returns val1
#set ($map.key = val2)
#set ($test.key = val2)
$map.key -- Returns val2
$test.key -- Returns val1 !!
The reason for this is, that the UberspectorImpl, in getPropertySet tests in
line 247 whether the passed object is assignable to a Map. This test is no in
the getPropertyGet
and seems to have no reason because the following method lookup for put
will succeed anyway.
I'd suggest the removal of this test.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
