[EMAIL PROTECTED]: Project jakarta-velocity-test (in module jakarta-velocity) failed

2006-10-10 Thread Velocity Gump
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project jakarta-velocity-test has an issue affecting its community integration. This

query - default logging behavior

2006-10-10 Thread Will Glass-Husain
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.

Re: query - default logging behavior

2006-10-10 Thread Nathan Bubna
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

Re: query - default logging behavior

2006-10-10 Thread Will Glass-Husain
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

Re: query - default logging behavior

2006-10-10 Thread Will Glass-Husain
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

Re: query - default logging behavior

2006-10-10 Thread Nathan Bubna
Yes, if neither LogKit (which is in velocity-dep, IIRC) nor Log4j are available to Velocity, then there is no velocity.log automatically created. Formerly, if neither were available, Velocity would panic and quit. Now it will fall back to first looking for JDK logging, and if it can't find that,

Re: query - default logging behavior

2006-10-10 Thread Nathan Bubna
+1 On 10/10/06, Will Glass-Husain [EMAIL PROTECTED] wrote: 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

svn commit: r462510 - /jakarta/velocity/engine/trunk/build/build.xml

2006-10-10 Thread henning
Author: henning Date: Tue Oct 10 12:27:09 2006 New Revision: 462510 URL: http://svn.apache.org/viewvc?view=revrev=462510 Log: Remove the avalon log kit from the dependency jar. JDKs 1.4 and above will now use JDK Logging by default. JDK 1.3 will use the Stdout logging. Bye bye velocity.log

svn commit: r462516 - in /jakarta/velocity/engine/trunk/src/java/org/apache/velocity/runtime/log: Log.java LogDisplayWrapper.java

2006-10-10 Thread henning
Author: henning Date: Tue Oct 10 12:32:03 2006 New Revision: 462516 URL: http://svn.apache.org/viewvc?view=revrev=462516 Log: Add a wrapper to be able to prefix and control the output of log messages on a finer grained base than just global logging. VelocityMacroFactory did this internally for a

svn commit: r462537 - /jakarta/velocity/engine/trunk/src/java/org/apache/velocity/runtime/VelocimacroFactory.java

2006-10-10 Thread henning
Author: henning Date: Tue Oct 10 13:03:29 2006 New Revision: 462537 URL: http://svn.apache.org/viewvc?view=revrev=462537 Log: Factor out the logging and prefixing, cleaning up the code for the Factory. Starting to work on VELOCITY-71... Modified:

Re: query - default logging behavior

2006-10-10 Thread Nathan Bubna
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

Re: query - default logging behavior

2006-10-10 Thread Will Glass-Husain
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

svn commit: r462549 - /jakarta/velocity/engine/trunk/src/java/org/apache/velocity/app/FieldMethodizer.java

2006-10-10 Thread nbubna
Author: nbubna Date: Tue Oct 10 13:35:24 2006 New Revision: 462549 URL: http://svn.apache.org/viewvc?view=revrev=462549 Log: remove reference to obsolete constant Modified: jakarta/velocity/engine/trunk/src/java/org/apache/velocity/app/FieldMethodizer.java Modified:

svn commit: r462551 - in /jakarta/velocity/engine/trunk/src/java/org/apache/velocity/runtime/log: LogManager.java StandardOutLogChute.java SystemLogChute.java

2006-10-10 Thread nbubna
Author: nbubna Date: Tue Oct 10 13:40:04 2006 New Revision: 462551 URL: http://svn.apache.org/viewvc?view=revrev=462551 Log: replace inflexible and possibly problematic StandardOutLogChute with SystemLogChute that can by default prints to System.err but can be configured to split or wholly

svn commit: r462552 - /jakarta/velocity/engine/trunk/src/java/org/apache/velocity/runtime/log/SystemLogChute.java

2006-10-10 Thread nbubna
Author: nbubna Date: Tue Oct 10 13:42:04 2006 New Revision: 462552 URL: http://svn.apache.org/viewvc?view=revrev=462552 Log: fix copy/paste typo Modified: jakarta/velocity/engine/trunk/src/java/org/apache/velocity/runtime/log/SystemLogChute.java Modified:

svn commit: r462604 - in /jakarta/velocity/engine/trunk/src/java/org/apache/velocity: app/ exception/ runtime/directive/ runtime/exception/ runtime/parser/ runtime/parser/node/ util/introspection/

2006-10-10 Thread wglass
Author: wglass Date: Tue Oct 10 15:17:37 2006 New Revision: 462604 URL: http://svn.apache.org/viewvc?view=revrev=462604 Log: Bold commit moving application-level exceptions to be based on RuntimeException. Modified: jakarta/velocity/engine/trunk/src/java/org/apache/velocity/app/Velocity.java

svn commit: r462624 - in /jakarta/velocity/engine/trunk/src/java/org/apache/velocity/runtime/parser/node: ASTDirective.java SimpleNode.java

2006-10-10 Thread henning
Author: henning Date: Tue Oct 10 15:51:49 2006 New Revision: 462624 URL: http://svn.apache.org/viewvc?view=revrev=462624 Log: add toString() methods to allow inspection of the AST using a debugger (buuh!) and get some readable results. Modified:

svn commit: r462627 - /jakarta/velocity/engine/trunk/src/java/org/apache/velocity/runtime/directive/VelocimacroProxy.java

2006-10-10 Thread henning
Author: henning Date: Tue Oct 10 15:53:30 2006 New Revision: 462627 URL: http://svn.apache.org/viewvc?view=revrev=462627 Log: Check whether the current macro test is not actually a macro invocation but a reference inside another macro definition. If yes, do not report an error about the size of

[Jakarta-velocity Wiki] Update of HackaThon2006 by HenningSchmiedehausen

2006-10-10 Thread Apache Wiki
Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta-velocity Wiki for change notification. The following page has been changed by HenningSchmiedehausen: http://wiki.apache.org/jakarta-velocity/HackaThon2006

[jira] Resolved: (VELOCITY-71) False positive error condition parsing VM_global_library.vm

2006-10-10 Thread Henning Schmiedehausen (JIRA)
[ http://issues.apache.org/jira/browse/VELOCITY-71?page=all ] Henning Schmiedehausen resolved VELOCITY-71. Resolution: Fixed This is more of a reporting issue than an actual but. Fixed in 1.5. False positive error condition parsing

Re: query - default logging behavior

2006-10-10 Thread Will Glass-Husain
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

Re: query - default logging behavior

2006-10-10 Thread Llewellyn Falco
hey, so you're sort of right about the reference errors, there are times for both logging and erroring. and those times break down to development / deploy. But as such, i still believe the default should be loud errors. because if you are going to be silent, it's best to happen when