Re: POLL - release beta 2?
+1 - Malcolm Edgar On 11/2/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 - 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]
Velocity 1.5 Cayenne compatablity
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]
Re: Velocity goes TLP
Well done :) On 10/27/06, Konstantin Priblouda [EMAIL PROTECTED] wrote: --- Will Glass-Husain [EMAIL PROTECTED] wrote: 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. Congratulations ;) NOw it would be even easier to sell velocity to customers. If I'm allowed to make suggestion, fresh dated snapshots ( or intermediate releases ) in maven repo ( with m2 poms ) would be most helpfull... regards, [ Konstantin Pribluda http://www.pribluda.de ] Still using XDoclet 1.x? XDoclet 2 is released and of production quality. check it out: http://xdoclet.codehaus.org __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.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]
Re: report on Velocity Hackathon 2006
That is great to hear Will. Thanks for giving everyone an update. regards Malcolm Edgar On 10/15/06, Will Glass-Husain [EMAIL PROTECTED] wrote: 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Velocity Hackathon - October 9/10
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 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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Velocity Hackathon - October 9/10
Hi Will,
thanks for the feedback. I will do Click Framework 1.0 release
soonish, and then do a Click 1.1 release to pickup the new Velocity
1.5 build when it goes final.
I will keep you posted on compatability issues with Click and Cayenne :)
regards Malcolm Edgar
On 9/30/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.
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?
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 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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Forio Business Simulations
Will Glass-Husain
[EMAIL PROTECTED]
www.forio.com
Re: projects under TLP umbrella
+1 for Click as a Web framework Then I can start work on my evil reverse take over plan, heh, heh heh.. Ops did I say that out loud. On 9/26/06, Will Glass-Husain [EMAIL PROTECTED] wrote: 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) -- strong or growing community of its own -- the integration of Velocity is a key part of the project 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) -- Port of Velocity to another platform? (e.g. nVelocity) -- Web framework closely tied to Velocity (Click, Turbine?) Not saying all of the above are candidates. But would they fit our desired umbrella? 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]
Re: [VOTE] Move Velocity to TLP
[X] +1 I support the proposal On 9/18/06, Daniel Rall [EMAIL PROTECTED] wrote: On Fri, 15 Sep 2006, Nathan Bubna 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: [X] +1 I support the proposal [ ] +0 I don't care [ ] -1 I'm opposed to the proposal because... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCE] Velocity 1.5 beta1
Great to see the Velocity 1.5 beta 1 is now available. regards Malcolm Edgar On 9/14/06, Henning Schmiedehausen [EMAIL PROTECTED] wrote: The Velocity developers are proud to announce the first beta version of Velocity 1.5. The vote thread is here: http://mail-archives.apache.org/mod_mbox/jakarta-velocity-dev/200609.mbox/[EMAIL PROTECTED] and the result is here: http://mail-archives.apache.org/mod_mbox/jakarta-velocity-dev/200609.mbox/[EMAIL PROTECTED] This is an unstable release and is intended as a preview of things to come. While it is feature-complete, we will apply a number of bug fixes and address the documentation issues before doing our final release push. Jakarta Velocity 1.5 beta 1 is available from http://people.apache.org/dist/jakarta/velocity/v1.5beta1/ Please report issues with this release on our bug tracker at https://issues.apache.org/jira/browse/VELOCITY using 1.5 beta1 as the version. For the Velocity Development Team Henning Schmiedehausen - 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]
Re: Opinion poll: Build an RC
+1 Yes I think this is a really good idea. regards Malcolm Edgar On 9/5/06, Henning P. Schmiedehausen [EMAIL PROTECTED] 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 -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Move Velocity to TLP
+1 again on the TLP move, With regard to finalizing the Velocity 1.5 release, I would love to see this patch applied. http://issues.apache.org/jira/browse/VELOCITY-438?page=all We have been using this patch since June this year without any issues. regards Malcolm Edgar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r434124 - in /jakarta/velocity/engine/trunk:
Thanks guys, regards Malcolm Edgar On 8/24/06, Will Glass-Husain [EMAIL PROTECTED] wrote: Oh! Should have remembered that. A little out of practice, perhaps. Thanks for the reminder. WILL On 8/23/06, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] writes: Author: wglass Date: Wed Aug 23 11:53:40 2006 New Revision: 434124 URL: http://svn.apache.org/viewvc?rev=434124view=rev Log: Stop calling object.toString() twice when evaluating references. Thanks to Stephen Haberman for the patch. Ah. If you put the VELOCITY-438 marker somewhere in the commit message, JIRA will pick up the commit and link it right back into the JIRA issue. Very cool. :-) 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Move Velocity to TLP
I think the TLP will be a good move for Velocity, raising its profile and getting its development moving again. So for what its worth +1 from me. I do acknowledge Ahmeds point, as I would love to see the 1.5-dev released. Its almost a bit unfair for people using 1.4 because its the production version where 1.5-dev addresses many of its problems. What is the Velocity Hackathon? regards Malcolm Edgar On 8/12/06, Nathan Bubna [EMAIL PROTECTED] wrote: I won't be at ApacheCon, but i may be able to plan to contribute some time during it to participate in a hackathon remotely. On 8/11/06, Will Glass-Husain [EMAIL PROTECTED] wrote: Hi, I'm a fan of the TLP idea, though I recognize the validity of Ahmed's concerns. Looking back at the project for a moment... We've got a mature product with a solid user base, some specific technological action steps we need to take but stalled development. User support is very good -- the mailing lists are active with three committers and 5-10 users actively supporting new users. The problem is that everyone currently involved has time for support but not development. Becoming a TLP won't do anything magical for us. But it'll provide us with an umbrella to invite other related projects to join Velocity. (via the Incubator, of course). Malcolm Edgar's Click framework, which has its own community and is a pretty innovative approach to web development, is the leading contender. I think a closer connection with such efforts may help us revitalize the core development. It'd be nice if we could pair the new TLP organization with a release of v. 1.5. Anyone want to join a Velocity Hackathon at ApacheCon US in early October and push this out? WILL On 8/11/06, Nathan Bubna [EMAIL PROTECTED] wrote: On 8/11/06, Ahmed Mohombe [EMAIL PROTECTED] wrote: I would like to propose that Velocity step out from the Jakarta umbrella and become a TLP at Apache. IMHO not the Velocity's position in the Apache tree is the problem, but the time invested by it's commiters. A SVN history can do everyone to see that. Hmm. Well, that's not really the problem that we're trying to solve with this proposed move. But, since you mention it, one of my main reasons for supporting this move is that it will allow us to make closer connections between Velocity-based projects and thus grow the immediate community. This may both 1) create renewed interest in past and current committers and contributers via more exposure to new, interesting Velocity-based projects (like Click) and/or 2) make it easier to bring in new committers and contributers for Velocity from those projects' communities. Of course, there are no guarantees, but when i combine the above with the fact that much of VelocityTools really doesn't fit with the direction Jakarta is heading--obstructing the desired path for both Jakarta and VelocityTools--then it seems very clear to me that this effort is worth some time on my part in the near future. So my vote (even if it doesn't count) would be -1 for a move. :( Better invest that very small time that you have for Velocity and bring out finally the 1.5 release. Many were expecting it last year's autumn and now have the fear that it won't be out not even this year's autumn. In contrast to my reasons above, it has been exceedingly hard to motivate myself (much less others, either contributers or committers) to hunt down and fix the remaining known bugs in 1.5-dev, since most are obscure, difficult to fix and already were present in the previous official releases. Many were even reported prior to those previous releases. Further, i'll admit that i've become increasingly comfortable using the unreleased 1.5-dev, having no personal policy against it and not currently needing it for my employer. I suspect the same is true of the other committers and many key contributers. This also affects how i prioritize the time i have to spend on Velocity stuff. All that said, I won't ask that you agree with my choice to spend time on this proposal prior to working on the bugs we wish to swat before releasing 1.5 (or even just releasing it as is), but considering that i've already decided this is where i wish to put my little time in the next month or so, i must ask, is it really the move to TLP that you oppose? Or is it just how i (and others supporting this) have chosen to prioritize our time? I will hear feedback on the latter, but i'd prefer to know what people think of the former, regardless of the latter. :) Thanks! Thank you, Ahmed. -- Click Framework: http://click.sourceforge.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
VELOCITY-438 patch
Hi All, Stephen Haberman submitted the patch: http://issues.apache.org/jira/browse/VELOCITY-438 Which optimises rendering of objects, i.e. toString() is only called once when rendering an object. This is very useful for Click which can create very large strings when rendering HTML Table and Form controls. I would really like to see this patch included in the 1.5-dev stream. regards Malcolm Edgar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: handling macro argument errors
Hi All, couple of comments on this issue. I think the default error handling behaviour in V1.4 is not good for development. I am seeing this currently in a project where developers are using V1.4 in a pipeline to generate XML which in turn will generate PDFs, when markup errors are made no PDF's come out the other end, and its time to trawl through the logs to find out what happened. Now I think the error logging is much improved in V1.5 with detailed information on the error location, and less debug messages in the log output. However the current V1.5 will still happily log errors such as making calling methods which do not exist on objects, e.g. [Velocity] [warn ] org.apache.velocity.runtime.exception.ReferenceException: reference : template = /action-demo.htm [line 14,column 1] : $link.noSuchMethod() is not a valid reference. This error handling behaviour should be configurable, i.e. flip the switch and it will throw an exception (ReferenceException should be made unchecked if we use this class). We (the royal we) should make this very easy to configure. I am probably +1 on the 1.4 support by default, but it would be very good to document the error handling behaviour and how to configure this easily. I think all the points raised by Max is his blog are very relevant: http://blog.hibernate.org/cgi-bin/blosxom.cgi/2006/02/03#a_story_about_freemarker_and_velocity I think many of these issues have been addressed, but there is still opportunity to improve Velocity with more descriptive error messages and easier configuration API. regards Malcolm Edgar On 3/22/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Nathan Bubna wrote: If i may be forgiven one last push... :) Let's keep the story straight--you wouldn't have to edit the old apps to make them work with 1.5. You just have to set the config property, not really a great burden. We could even make the message with the thrown exception point out the new config property, so that those who don't read change logs or release notes will have no problem figuring out what's going on. That means you can't just upgrade and have things work. You have to upgrade and reconfigure. I'd make it work like 1.4 by default, turn on new behavior w/ a switch, and fix it in 2.0 geir On 3/21/06, Will Glass-Husain [EMAIL PROTECTED] wrote: I feel strongly about this. I've personally got hundreds of templates in production and support users with hundreds more. Say 5% of those templates have this error. (It's not hard to make -- note that the Velocity test suite for Anakia contains this error). All of a sudden I have tens of templates, scattered all over the place that suddenly cause errors. All of those apps work right now- why do I want them to fail? Anything that requires me to edit old apps to make Velocity 1.5 work is not backwards compatible. (and will retard adoption of 1.5). It would have been nicer if this had always generated an error. For new apps this is better. But for old apps it is actively harmful to change this. So let's make this a config option and turn it on by default for 2.0 . WILL On 3/21/06, Nathan Bubna [EMAIL PROTECTED] wrote: On 3/21/06, Will Glass-Husain [EMAIL PROTECTED] wrote: I'm starting to agree with you, Llwellyn. Though I don't think we should change the behavior of the templates for existing users. even if the behavior is buggy/broken? it's not like the extra or missing arguments were doing anything functionally. throwing an exception, however, will add functionality (as Malcom demonstrated. we already warned that their macro call was broken in the logs, i think it is fair to escalate that to an exception, especially if we provide a config option to log instead of throw an exception. of course, if you feel strongly about this, i won't -1 a log-only default, and i'll let them that do the work implement it the way they want :). it's just my opinion; i won't be dogmatic on it. :) WILL On 3/21/06, Llewellyn Falco [EMAIL PROTECTED] wrote: Personally, i feel that templates whose macro calls don't match up to the macro definitions are *already* broken. this is my general thought on the whole thing too. and as we deal in financial transactions, I take a general view of it is better not to show something than to show something wrong. however, I can understand that in an entertainment situation you might have the exact opposite view. again though, I think this goes back to a 2 modes of running. development - always halt on errors - someone's there to fix them. deployment - do the best you can - log what goes wrong and see a setting much more in this idea. btw: this is also why I always develop with the UberspectTestImpl and rather think that it should be default Uberspect, while currently it is only in the test classes. Llewellyn
Re: handling macro argument errors
I am not feeling all that creative at the moment, so I am +1 on option 1. In fact i think there should be a strict all mode config option which covers all the errors: invalid references, invalid macros, null #set strict.all.mode = true I think a lot of people would use this option, would be simple to configure, and I think is a more Java centric way of working. If you stuff something up in your template, it breaks and you work through your errors. regards Malcolm Edgar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-435) ParseErrorException not thrown with #macro parse error
[
http://issues.apache.org/jira/browse/VELOCITY-435?page=comments#action_12371026
]
Malcolm Edgar commented on VELOCITY-435:
Hi Will,
I have run up your test case against Velocity 1.4.
I am afraid my error description was actually mis leading, the cause of the
error was not a second argument:
#foo('test1' 'test2')
But adding a comma between the arguments. This causes a ParseErrorException in
1.4 and previous versions of 1.5-dev, but not in the latest 1.5-dev code.
#foo('test1,' 'test2')
regards Malcolm Edgar
ParseErrorException not thrown with #macro parse error
--
Key: VELOCITY-435
URL: http://issues.apache.org/jira/browse/VELOCITY-435
Project: Velocity
Type: Bug
Versions: 1.5
Environment: Windows XP, JDK 1.4.2_09
Reporter: Malcolm Edgar
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] Commented: (VELOCITY-435) ParseErrorException not thrown with #macro parse error
[ http://issues.apache.org/jira/browse/VELOCITY-435?page=comments#action_12371027 ] Malcolm Edgar commented on VELOCITY-435: The strict mode parameter is an excellent idea. regards Malcolm ParseErrorException not thrown with #macro parse error -- Key: VELOCITY-435 URL: http://issues.apache.org/jira/browse/VELOCITY-435 Project: Velocity Type: Bug Versions: 1.5 Environment: Windows XP, JDK 1.4.2_09 Reporter: Malcolm Edgar 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] Commented: (VELOCITY-85) Logging too verbose when used with Log4J
[ http://issues.apache.org/jira/browse/VELOCITY-85?page=comments#action_12369013 ] Malcolm Edgar commented on VELOCITY-85: --- +1 on this. To avoid this excessive Velocity logging in Click, after the Velocity engine has been initialized it sets the Velocity logging level to WARN to avoid these debug messages. regards Malcolm Edgar Logging too verbose when used with Log4J Key: VELOCITY-85 URL: http://issues.apache.org/jira/browse/VELOCITY-85 Project: Velocity Type: Bug Components: Build Versions: 1.3-rc1 Environment: Operating System: other Platform: All Reporter: Andy Riedel Assignee: Velocity-Dev List Priority: Minor When using using Log4J to handle Velocity logging, many of the internal logging messages generated by the VelocityEngine are too verbose. Below is some sample output when logging to Log4J. It seems that much of this information should be at DEBUG prioriry and not INFO priority. In fact, it's arguable that all of these messages (except for the ERROR one) should be at DEBUG priority. Andy Riedel [EMAIL PROTECTED] 2002-06-17 18:26:02,312 [main] INFO VelocityEngine - ** 2002-06-17 18:26:02,322 [main] INFO VelocityEngine - Starting Jakarta Velocity v1.3-rc1 2002-06-17 18:26:02,332 [main] INFO VelocityEngine - RuntimeInstance initializing. 2002-06-17 18:26:02,342 [main] INFO VelocityEngine - Default Properties File: org\apache\velocity\runtime\defaults\velocity.properties 2002-06-17 18:26:02,352 [main] INFO VelocityEngine - Trying to use logger class org.apache.velocity.runtime.log.SimpleLog4JLogSystem 2002-06-17 18:26:02,362 [main] INFO VelocityEngine - Using logger class org.apache.velocity.runtime.log.SimpleLog4JLogSystem 2002-06-17 18:26:02,382 [main] INFO VelocityEngine - Default ResourceManager initializing. (class org.apache.velocity.runtime.resource.ResourceManagerImpl) 2002-06-17 18:26:02,402 [main] INFO VelocityEngine - Resource Loader Instantiated: org.apache.velocity.runtime.resource.loader.FileResourceLoader 2002-06-17 18:26:02,412 [main] INFO VelocityEngine - FileResourceLoader : initialization starting. 2002-06-17 18:26:02,422 [main] INFO VelocityEngine - FileResourceLoader : adding path '../../skins/default' 2002-06-17 18:26:02,432 [main] INFO VelocityEngine - FileResourceLoader : initialization complete. 2002-06-17 18:26:02,452 [main] INFO VelocityEngine - ResourceCache : initialized. (class org.apache.velocity.runtime.resource.ResourceCacheImpl) 2002-06-17 18:26:02,462 [main] INFO VelocityEngine - Default ResourceManager initialization complete. 2002-06-17 18:26:02,472 [main] INFO VelocityEngine - Loaded System Directive: org.apache.velocity.runtime.directive.Literal 2002-06-17 18:26:02,492 [main] INFO VelocityEngine - Loaded System Directive: org.apache.velocity.runtime.directive.Macro 2002-06-17 18:26:02,502 [main] INFO VelocityEngine - Loaded System Directive: org.apache.velocity.runtime.directive.Parse 2002-06-17 18:26:02,522 [main] INFO VelocityEngine - Loaded System Directive: org.apache.velocity.runtime.directive.Include 2002-06-17 18:26:02,532 [main] INFO VelocityEngine - Loaded System Directive: org.apache.velocity.runtime.directive.Foreach 2002-06-17 18:26:02,712 [main] INFO VelocityEngine - Created: 20 parsers. 2002-06-17 18:26:02,722 [main] INFO VelocityEngine - Velocimacro : initialization starting. 2002-06-17 18:26:02,732 [main] INFO VelocityEngine - Velocimacro : adding VMs from VM library template : VM_global_library.vm 2002-06-17 18:26:02,753 [main] ERROR VelocityEngine - ResourceManager : unable to find resource 'VM_global_library.vm' in any resource loader. 2002-06-17 18:26:02,763 [main] INFO VelocityEngine - Velocimacro : error using VM library template VM_global_library.vm : org.apache.velocity.exception.ResourceNotFou ndException: Unable to find resource 'VM_global_library.vm' 2002-06-17 18:26:02,783 [main] INFO VelocityEngine - Velocimacro : VM library template macro registration complete. 2002-06-17 18:26:02,793 [main] INFO VelocityEngine - Velocimacro : allowInline = true : VMs can be defined inline in templates 2002-06-17 18:26:02,823 [main] INFO VelocityEngine - Velocimacro : allowInlineToOverride = false : VMs defined inline may NOT replace previous VM definitions 2002-06-17 18:26:02,823 [main] INFO VelocityEngine - Velocimacro : allowInlineLocal = false : VMs defined inline will be global in scope if allowed. 2002-06-17 18:26:02,833 [main] INFO VelocityEngine - Velocimacro : messages on : VM system will output logging messages 2002-06-17 18:26:02,853 [main] INFO VelocityEngine - Velocimacro : autoload off : VM system will not automatically reload global library macros 2002
Error handling with
Hi All, 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (VELOCITY-435) ParseErrorException not thrown with #macro parse error
ParseErrorException not thrown with #macro parse error -- Key: VELOCITY-435 URL: http://issues.apache.org/jira/browse/VELOCITY-435 Project: Velocity Type: Bug Versions: 1.5 Environment: Windows XP, JDK 1.4.2_09 Reporter: Malcolm Edgar 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]
Re: Velocity 1.5 roadmap
Ok sounds good. I have an outstanding tasks to test Cayenne 1.2 compatiblity with the latest Velocity 1.5-dev trunc, and test how the revised error handling works. Have just checked out the latest source from new engine svn location. Are we now at a code freeze point? regards Malcolm Edgar On 3/3/06, Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Will Glass-Husain [EMAIL PROTECTED] writes: The immediate next steps are to launch the revised web site (on Henning's plate) and to finish the event handler docs (on mine). I've gotten a littl= e side tracked with a 3 week old baby and too much paying work but let me wor= k on this. Henning, any news from you? I was on holidays for two weeks and forgot about the perils of snow. I slipped yesterday on the way to work and tore some ligaments in my ankle. While this is bad news for me, it is good news for Velocity because I now have some free time to finish up the docs. :-/ 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 4 - 8 - 15 - 16 - 23 - 42 - 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]
Re: Velocity error handling / integration
Hi Will, Yes the error handling issue is pretty well nailed now in 1.5. The issue of configuration is valid in that FM is much easier to setup, principally because they default alot of configuration. Possibly Vel could have some default setups, to help people get jump started. On a completely unrelated issue, I have been working with JSTL for the last month or so. I had the impression that JSP had finally caught up to Velocity with JSTL and EL. Well I was wrong, Velocity is still head and sholders easier to use than JSTL. regards Malcolm Edgar On 2/5/06, Will Glass-Husain [EMAIL PROTECTED] wrote: Hi, Just wanted to highlight this article for members of the Velocity dev community http://blog.hibernate.org/cgi-bin/blosxom.cgi/2006/02/03#a_story_about_freemarker_and_velocity This article describes why the author of the Hibernate Tools is moving from Velocity to FreeMarker. Makes some good points about error handling and application integration. Some of the concerns will be alleviated with 1.5 but it's interesting to ponder his various points. Cheers, Will - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Caching / OutOfMemoryException
Are you using the Velocity singleton pattern or VelocityEngine? There
can be memory leaking issues if you are continually reloading the
Velocity singleton instance.
regards Malcolm
On 1/12/06, Fredrik Andersson [EMAIL PROTECTED] wrote:
Thanks Daniel.
You don't have to change the documentation, I just had a hard time googling
it for some reason. Lazy coder syndrome, sorry.
We have done some extensive testing and thinking the last couple of days,
and it seems our OOM Exception surfaces when frequently updating the
WAR-files (containing Velocity servlets) in the Tomcat, not exclusively by
heavy load. This would rather suggest that it's our Tomcat and/or Java
version not working well with Velocity 1.5. I've never had any problems with
other template/servlet systems so I still suspect Velocity to be the culprit
in some way. This bug/phenomena is too critical to not have been noticed
before by other users of Velocity, so it has to be some common denominator
that all our developers use (which leads to the combination of JRE and/or
Tomcat and Velocity).
Even if the Tomcat is somehow caching/serializing some parts of the Velocity
offspring between updates of the WAR files, it should in not way lead to
OOM Exception. Definately not by the LRU map, since it has an upper bound
for how much it can grow. But this is probably a question for the tomcat-dev
list, so I'll stop ranting now.
Though this is slightly off-topic, if anyone else is using the very latest
JRE, Tomcat and Velocity 1.5, it'd be swell to hear if you encounter this
problem when frequently updating the webapps.
I'll drop a line when and if we resolve this issue.
Fredrik
On 1/12/06, Daniel Rall [EMAIL PROTECTED] wrote:
On Tue, 10 Jan 2006, Fredrik Andersson wrote:
I'll try the resource.manager.defaultcache setting. I seem to remember
that
I stumbled upon a forum thread or mailinglist some weeks ago arguing
that
this setting was limitless unless you set it explicitly.
http://mail-archives.apache.org/mod_mbox/jakarta-velocity-dev/200310.mbox/[EMAIL
PROTECTED]
Even not setting this property should create a (non-greedy) LRUMap by
default:
public class ResourceCacheImpl implements ResourceCache
{
...
public void initialize( RuntimeServices rs )
{
rsvc = rs;
int maxSize =
rsvc.getInt(
RuntimeConstants.RESOURCE_MANAGER_DEFAULTCACHE_SIZE, 89);
if (maxSize 0)
{
// Create a whole new Map here to avoid hanging on to a
// handle to the unsynch'd LRUMap for our lifetime.
Map lruCache = Collections.synchronizedMap(new
LRUMap(maxSize));
lruCache.putAll(cache);
cache = lruCache;
}
rsvc.getLog().info(ResourceCache: initialized
(+this.getClass()+')');
}
...
This setting isn't very documented, by the way! I'll just browse the
source and see what it does.
Here's what I found:
--- snip ---
resource.manager.cache.class Declares the class to be used for
resource caching. The current default is
org.apache.velocity.runtime.resource.ResourceCacheImpl which uses a
LRU Map to prevent data from being held forever. You can set the size
of the LRU Map using the parameter
resource.manager.defaultcache.size. The dafault value of the default
cache size is currently 89.
resource.manager.defaultcache.size Sets the size of the default
implementation of the resource manager resource cache.
--- snip ---
Fredrik, how do you recommend we change that to improve things?
--
Daniel Rall
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: development status
Great to hear. regards Malcolm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: request for comments on Macro issues
+1 on the 1.5 macro release approach. I would also love to see the macro with nested content (I think we are talking about the same thing) brought in into a Velocity 1.6 release. In FM they are referred to as the nested directive file:///c:/java/freemarker-2.3.4/docs/docs/ref_directive_macro.html regards Malcolm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RuntimeExceptions
+1 on Option #3. I think this is now accepted as a best practice with Java error handling. regards Malcolm Edgar On 1/3/06, Will Glass-Husain [EMAIL PROTECTED] wrote: First, happy new year to the Velocity developer community... I've been pondering how Velocity handles exceptions. Right now, almost every call to a plugin has a catch-all Exception handler which does little more than log the Exception. There's been a couple of requests in the past few months to pass RuntimeExceptions or similar through. * In Velocity-424, Malcolm Edgar wanted NPEs from a call to toString to pass through a #parse. (we did this). * Llewelyn Falco created a TestableUberspect which interrupted processing upon an invalid method call. * There was someone else (can't find the reference) who wanted to interrupt processing when confronted with an invalid method call. I was wondering, why does Velocity intercept every exception? Isn't the point of a RuntimeException that it signals an application-level problem that should be returned to the calling code? In addition, we should allow plugins (event handlers, uberspectors, resource loaders) to interrupt processing for critical problems. To me, there seems three choices. (1) Catch every unexpected condition and do something with it (e.g. catch NPE from toString() and wrap it in a MethodInvocationException). Logging does not count as doing something. (2) Create a special VelocityRuntimeException that plugins can use to interrupt processing. Every generic catch (Exception E) wrapper would pass this through. (I've coded this though not applied the patch). (3) Remove all generic Exception catch's. (or if not feasible, always pass RuntimeException's through). To me, option #1 seems infeasible. (if we start wrapping toString, we'd need to wrap a lot of other little stuff). Option #2 is useful for plugins to interrupt processing. But I'm wondering, why not do option #3 and just pass through all RuntimeExceptions. Any reason why we *should* be catching unexpected RuntimeException's? Appreciate other thoughts... Best, WILL ___ Forio Business Simulations Will Glass-Husain phone (415) 440-7500 x89 mobile (415) 235-4293 [EMAIL PROTECTED] www.forio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RuntimeExceptions
Hi Will, +1 on Option #3. I think this is now accepted as a best practice with Java error handling. regards Malcolm Edgar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (VELOCITY-426) move of Node object broke compatibility with custom directives
Hi Will,
Yes I forwarded this message to the cayenne-dev list. I think it got
through.
Its great to see Velocity 1.5 moving forward. There is a lot of support out
there for Velocity.
regards Malcolm Edgar
On 12/15/05, Will Glass-Husain [EMAIL PROTECTED] wrote:
Hi Malcom,
Thanks for checking this. Will you be communicating this to the rest of
the
Cayenne community? When I tried to post to the cayenne-dev list my
message
bounced not a subscriber.
And appreciate again your raising this issue. The more users of the dev
tree we have, the better we will be able to keep our goals of incremental
improvement with 100% backwards compatibility.
Best, WILL
- Original Message -
From: Malcolm Edgar (JIRA) [EMAIL PROTECTED]
To: velocity-dev@jakarta.apache.org
Sent: Wednesday, December 14, 2005 5:01 AM
Subject: [jira] Commented: (VELOCITY-426) move of Node object broke
compatibility with custom directives
[
http://issues.apache.org/jira/browse/VELOCITY-426?page=comments#action_12360417]
Malcolm Edgar commented on VELOCITY-426:
Hi guys,
I have tested head stream against Cayenne 1.2M6 and confirm that this
change resolves this issue.
Thanks for your help.
regards Malcolm Edgar
move of Node object broke compatibility with custom directives
--
Key: VELOCITY-426
URL: http://issues.apache.org/jira/browse/VELOCITY-426
Project: Velocity
Type: Bug
Components: Source
Versions: 1.5
Reporter: Will Glass-Husain
Assignee: Henning Schmiedehausen
Fix For: 1.5
From Malcolm Edgar:
Hi Will company,
Regarding the cause of the problem.
This is the code from Cayenne class ResultDirective (Cayenne 1.2 M6):
import org.apache.velocity.runtime.parser.node.Node;
protected Object getChild(InternalContextAdapter context, Node
node,
int
i)
throws MethodInvocationException {
return (i = 0 i node.jjtGetNumChildren())
? node.jjtGetChild(i).value(context)
: null;
}
When running with Velocity 1.5-dev this throwing the exception:
Caused by: java.lang.NoSuchMethodError:
org.apache.velocity.runtime.parser.node.Node.jjtGetChild
(I)Lorg/apache/velocity/runtime/parser/node/Node;
at org.objectstyle.cayenne.access.jdbc.ResultDirective.getChild(
ResultDirective.java:190)
As the Node.jttGetChild(i) returns:
org.apache.velocity.runtime.parser.Node
rather than:
org.apache.velocity.runtime.parser.node.Node
This issue, plus another Velocity/Cayenne issue of a disappearing
object
reference in the velocity Context, is causing a lot of grief. We have
been
burning a lot of time over the last couple of weeks trying identify the
latter issue, plus having to rollback Velocity changes maintain Cayenne
compatability.
--
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-424) directive.Parse eating RuntimeException
[ http://issues.apache.org/jira/browse/VELOCITY-424?page=comments#action_12360416 ] Malcolm Edgar commented on VELOCITY-424: Hi guys, I have tested the patch it works well. regards Malcolm Edgar directive.Parse eating RuntimeException --- Key: VELOCITY-424 URL: http://issues.apache.org/jira/browse/VELOCITY-424 Project: Velocity Type: Bug Components: Source Versions: 1.5 Reporter: Malcolm Edgar Assignee: Henning Schmiedehausen Fix For: 1.5 Attachments: Parse_patch.txt The org.apache.velocity.runtime.directive.Parse class is eating RuntimeExceptions thrown by Nodes being rendered on line 195. These errors are logged, but are not rethrown. These types of errors are typically NPE being thrown by model objects trying to render themselves using their toString() method. It is better if any RuntimeExceptions are not caught by this method, as it allows the calling code to document/report the error. -- 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-426) move of Node object broke compatibility with custom directives
[
http://issues.apache.org/jira/browse/VELOCITY-426?page=comments#action_12360417
]
Malcolm Edgar commented on VELOCITY-426:
Hi guys,
I have tested head stream against Cayenne 1.2M6 and confirm that this change
resolves this issue.
Thanks for your help.
regards Malcolm Edgar
move of Node object broke compatibility with custom directives
--
Key: VELOCITY-426
URL: http://issues.apache.org/jira/browse/VELOCITY-426
Project: Velocity
Type: Bug
Components: Source
Versions: 1.5
Reporter: Will Glass-Husain
Assignee: Henning Schmiedehausen
Fix For: 1.5
From Malcolm Edgar:
Hi Will company,
Regarding the cause of the problem.
This is the code from Cayenne class ResultDirective (Cayenne 1.2 M6):
import org.apache.velocity.runtime.parser.node.Node;
protected Object getChild(InternalContextAdapter context, Node node, int
i)
throws MethodInvocationException {
return (i = 0 i node.jjtGetNumChildren())
? node.jjtGetChild(i).value(context)
: null;
}
When running with Velocity 1.5-dev this throwing the exception:
Caused by: java.lang.NoSuchMethodError:
org.apache.velocity.runtime.parser.node.Node.jjtGetChild
(I)Lorg/apache/velocity/runtime/parser/node/Node;
at org.objectstyle.cayenne.access.jdbc.ResultDirective.getChild(
ResultDirective.java:190)
As the Node.jttGetChild(i) returns:
org.apache.velocity.runtime.parser.Node
rather than:
org.apache.velocity.runtime.parser.node.Node
This issue, plus another Velocity/Cayenne issue of a disappearing object
reference in the velocity Context, is causing a lot of grief. We have been
burning a lot of time over the last couple of weeks trying identify the
latter issue, plus having to rollback Velocity changes maintain Cayenne
compatability.
--
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-424) directive.Parse eating RuntimeException
[ http://issues.apache.org/jira/browse/VELOCITY-424?page=comments#action_12360267 ] Malcolm Edgar commented on VELOCITY-424: A little more background on this issue, which is more of a change request than a Velocity bug. This use case is: A Click control is added to the Velocity context and merged with the template. The application control code has a bug in it and throws a NullPointerException when its toString() method is called by Velocity. Velocity catches this exception and logs the exception, and stops rendering. This can make the error difficult to find, as the application has no visibility of the RuntimeException it caused. The preferred behaviour is for RuntimeExceptions to be rethrown by Velocity. regards Malcolm Edgar directive.Parse eating RuntimeException --- Key: VELOCITY-424 URL: http://issues.apache.org/jira/browse/VELOCITY-424 Project: Velocity Type: Bug Components: Source Versions: 1.5 Reporter: Malcolm Edgar Attachments: Parse_patch.txt The org.apache.velocity.runtime.directive.Parse class is eating RuntimeExceptions thrown by Nodes being rendered on line 195. These errors are logged, but are not rethrown. These types of errors are typically NPE being thrown by model objects trying to render themselves using their toString() method. It is better if any RuntimeExceptions are not caught by this method, as it allows the calling code to document/report the error. -- 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: Parse refactoring
Hi Will company,
Regarding the cause of the problem.
This is the code from Cayenne class ResultDirective (Cayenne 1.2 M6):
import org.apache.velocity.runtime.parser.node.Node;
protected Object getChild(InternalContextAdapter context, Node node, int
i)
throws MethodInvocationException {
return (i = 0 i node.jjtGetNumChildren())
? node.jjtGetChild(i).value(context)
: null;
}
When running with Velocity 1.5-dev this throwing the exception:
Caused by: java.lang.NoSuchMethodError:
org.apache.velocity.runtime.parser.node.Node.jjtGetChild
(I)Lorg/apache/velocity/runtime/parser/node/Node;
at org.objectstyle.cayenne.access.jdbc.ResultDirective.getChild(
ResultDirective.java:190)
As the Node.jttGetChild(i) returns:
org.apache.velocity.runtime.parser.Node
rather than:
org.apache.velocity.runtime.parser.node.Node
This issue, plus another Velocity/Cayenne issue of a disappearing object
reference in the velocity Context, is causing a lot of grief. We have been
burning a lot of time over the last couple of weeks trying identify the
latter issue, plus having to rollback Velocity changes maintain Cayenne
compatability.
The Velocity stability issue is really hurting us, and we are at the point
of deciding whether to swap Velocity out for FreeMarker. This is not a fun
option, as I have invested a bunch of time into Velocity, and we have
applications out there which will need to be reworked if we do this.
I hope we can work out some solution
regards Malcolm Edgar
On 12/4/05, Will Glass-Husain [EMAIL PROTECTED] wrote:
Hmm..
This is awkward. Hard to improve a product when other apps rely on the
internal method calls.
Do you know the specific change in Velocity which broke Cayenne?
WILL
- Original Message -
From: Malcolm Edgar [EMAIL PROTECTED]
To: Velocity Developers List velocity-dev@jakarta.apache.org
Sent: Saturday, December 03, 2005 2:53 AM
Subject: Parse refactoring
Hi Guys,
Velocity parser was refactored a few weeks ago, the directory was changed
from memory. This is breaking compatablity with Cayenne which uses
Velocity
1.4.
Click has been using 1.5-dev up until now, but this change is leaving me
in
no mans land.
Is is possible that this change could be rolled back.
regards Malcolm Edgar
Stack trace:
java.lang.NoSuchMethodError:
org.apache.velocity.runtime.parser.node.Node.jjtGetChild
(I)Lorg/apache/velocity/runtime/parser/node/Node;
at org.objectstyle.cayenne.access.jdbc.ResultDirective.getChild(
ResultDirective.java:190)
at
org.objectstyle.cayenne.access.jdbc.ResultDirective.getChildAsString(
ResultDirective.java:202)
at org.objectstyle.cayenne.access.jdbc.ResultDirective.render(
ResultDirective.java:151)
at org.apache.velocity.runtime.parser.node.ASTDirective.render(
ASTDirective.java:117)
at org.apache.velocity.runtime.parser.node.SimpleNode.render(
SimpleNode.java:240)
at
org.objectstyle.cayenne.access.jdbc.SQLTemplateProcessor.buildStatement(
SQLTemplateProcessor.java:219)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Parse refactoring
Hi Guys, Velocity parser was refactored a few weeks ago, the directory was changed from memory. This is breaking compatablity with Cayenne which uses Velocity 1.4. Click has been using 1.5-dev up until now, but this change is leaving me in no mans land. Is is possible that this change could be rolled back. regards Malcolm Edgar Stack trace: java.lang.NoSuchMethodError: org.apache.velocity.runtime.parser.node.Node.jjtGetChild(I)Lorg/apache/velocity/runtime/parser/node/Node; at org.objectstyle.cayenne.access.jdbc.ResultDirective.getChild( ResultDirective.java:190) at org.objectstyle.cayenne.access.jdbc.ResultDirective.getChildAsString( ResultDirective.java:202) at org.objectstyle.cayenne.access.jdbc.ResultDirective.render( ResultDirective.java:151) at org.apache.velocity.runtime.parser.node.ASTDirective.render( ASTDirective.java:117) at org.apache.velocity.runtime.parser.node.SimpleNode.render( SimpleNode.java:240) at org.objectstyle.cayenne.access.jdbc.SQLTemplateProcessor.buildStatement( SQLTemplateProcessor.java:219)
Re: Exceptions
+1 This is a problem I have been seeing with Click, NPE not being available to application code http://issues.apache.org/jira/browse/VELOCITY-424 regards Malcolm Edgar On 12/2/05, Will Glass-Husain [EMAIL PROTECTED] wrote: (changing subject headers) I'm not worried about serialization issues. Let me look at NestableException. On a related topic, I'd like to introduce a VelocityRuntimeException that plugins can throw to signal application level errors. For example, an app that insists on having 100% correct references can introduce a custom Uberspect that throws an error for an invalid reference. Right now if a plugin throws an exception it is caught and logged -- there's no way to signal failure to the calling application. It'd make more sense if the engine would let through anything that subclasses VelocityRuntimeException. WILL - Original Message - From: Alexey Panchenko [EMAIL PROTECTED] To: Velocity Developers List velocity-dev@jakarta.apache.org Sent: Thursday, December 01, 2005 10:17 PM Subject: Re[4]: svn commit: r350188 - in /jakarta/velocity/core/trunk/src: java/org/apache/velocity/exception/ java/org/apache/velocity/runtime/log/ java/org/apache/velocity/runtime/resource/loader/ java/org/apache/velocity/util/ test/org/apache/velocity/ Nathan Bubna wrote: +1 NestableException is, IMHO, a temporary solution that may have been more reasonable several releases ago, but at this point would just create too much public API churn for what it is worth. Changing from VelocityException extends Exception to VelocityException extends NestableException does not change binary compatibility. Only serializable form is affected, though I do not see a point in saving serialized exceptions for long time on disk. -- Best regards, Alexeymailto:[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]
[jira] Created: (VELOCITY-424) directive.Parse eating RuntimeException
directive.Parse eating RuntimeException --- Key: VELOCITY-424 URL: http://issues.apache.org/jira/browse/VELOCITY-424 Project: Velocity Type: Bug Components: Source Versions: 1.5 Reporter: Malcolm Edgar The org.apache.velocity.runtime.directive.Parse class is eating RuntimeExceptions thrown by Nodes being rendered on line 195. These errors are logged, but are not rethrown. These types of errors are typically NPE being thrown by model objects trying to render themselves using their toString() method. It is better if any RuntimeExceptions are not caught by this method, as it allows the calling code to document/report the error. -- 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-424) directive.Parse eating RuntimeException
[ http://issues.apache.org/jira/browse/VELOCITY-424?page=all ] Malcolm Edgar updated VELOCITY-424: --- Attachment: Parse_patch.txt Fix for Parse eating runtime exceptions directive.Parse eating RuntimeException --- Key: VELOCITY-424 URL: http://issues.apache.org/jira/browse/VELOCITY-424 Project: Velocity Type: Bug Components: Source Versions: 1.5 Reporter: Malcolm Edgar Attachments: Parse_patch.txt The org.apache.velocity.runtime.directive.Parse class is eating RuntimeExceptions thrown by Nodes being rendered on line 195. These errors are logged, but are not rethrown. These types of errors are typically NPE being thrown by model objects trying to render themselves using their toString() method. It is better if any RuntimeExceptions are not caught by this method, as it allows the calling code to document/report the error. -- 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]
Release schedule?
Hi All, how is progress going for the Velocity 1.5 release? Do you think it will come out this year, or are we looking at next year. regards Malcolm Edgar http://click.sourceforge.net
[jira] Created: (VELOCITY-412) Enable access to application attributes
Enable access to application attributes --- Key: VELOCITY-412 URL: http://issues.apache.org/jira/browse/VELOCITY-412 Project: Velocity Type: Improvement Components: Source Versions: 1.5 Reporter: Malcolm Edgar Enable the getting of application attributes held by the RuntimeInstance. Currently you can set application attributes through the RuntimeServices interface, but you cannot get them. When Click starts up it initialises a custom Logger with Velocity and sets the logging level to INFO which produces useful initialisation debug information. Once initialisation has been completed it Click needs to turn down the Logger level to WARN, so that Velocity resource loading messages are not displayed. Please see the attached patches. 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-412) Enable access to application attributes
[ http://issues.apache.org/jira/browse/VELOCITY-412?page=all ] Malcolm Edgar updated VELOCITY-412: --- Attachment: VelocityEngine_patch.txt Enable access to application attributes --- Key: VELOCITY-412 URL: http://issues.apache.org/jira/browse/VELOCITY-412 Project: Velocity Type: Improvement Components: Source Versions: 1.5 Reporter: Malcolm Edgar Attachments: RuntimeServices_patch.txt, VelocityEngine_patch.txt Enable the getting of application attributes held by the RuntimeInstance. Currently you can set application attributes through the RuntimeServices interface, but you cannot get them. When Click starts up it initialises a custom Logger with Velocity and sets the logging level to INFO which produces useful initialisation debug information. Once initialisation has been completed it Click needs to turn down the Logger level to WARN, so that Velocity resource loading messages are not displayed. Please see the attached patches. 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-412) Enable access to application attributes
[ http://issues.apache.org/jira/browse/VELOCITY-412?page=all ] Malcolm Edgar updated VELOCITY-412: --- Attachment: RuntimeServices_patch.txt Enable access to application attributes --- Key: VELOCITY-412 URL: http://issues.apache.org/jira/browse/VELOCITY-412 Project: Velocity Type: Improvement Components: Source Versions: 1.5 Reporter: Malcolm Edgar Attachments: RuntimeServices_patch.txt, VelocityEngine_patch.txt Enable the getting of application attributes held by the RuntimeInstance. Currently you can set application attributes through the RuntimeServices interface, but you cannot get them. When Click starts up it initialises a custom Logger with Velocity and sets the logging level to INFO which produces useful initialisation debug information. Once initialisation has been completed it Click needs to turn down the Logger level to WARN, so that Velocity resource loading messages are not displayed. Please see the attached patches. 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]
Re: [jira] Resolved: (VELOCITY-412) Enable access to application attributes
Thanks Will. Hard to bet OS turn around time. regards Malcolm Edgar
Re: [jira] Resolved: (VELOCITY-373) Enhance ParseErrorException
Hi Will, thanks for getting this in. I want wait to pick it up :) On a side issue I dont think I will mention FreeMaker again on the Velocity dev list, this ends up generating a lot of noise. regards Malcolm Edgar
[jira] Updated: (VELOCITY-373) Enhance ParseErrorException
[ http://issues.apache.org/jira/browse/VELOCITY-373?page=all ] Malcolm Edgar updated VELOCITY-373: --- Attachment: Parser.jjt.txt Requested Parser.jjt Enhance ParseErrorException --- Key: VELOCITY-373 URL: http://issues.apache.org/jira/browse/VELOCITY-373 Project: Velocity Type: Improvement Components: Source Versions: 1.5 Environment: Operating System: other Platform: Other Reporter: Malcolm Edgar Priority: Minor Fix For: 1.5 Attachments: ParseErrorException.txt, ParseErrorException.txt, ParseException.txt, Parser.jjt.txt, Parser.txt, Template.txt Enhance the ParseErrorException to report: * template name (path) * error line * error column The Click framework attempts to render the template error highlighting the offending line. However when templates or macros are included in a page, the source of the error cannot be determined from the ParseErrorException message. If the additional properties could be added to the ParseErrorException the framework could accurately render the offending template error. This information should enable quicker debugging of usage errors by all Velocity users. -- 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: new ant build
Thats true, I was thinking of CVS regards Malcolm Edgar
Re: moving towards 1.5-beta release
+1 On 10/10/05, Will Glass-Husain [EMAIL PROTECTED] wrote: Hi, I just wanted to check in that we are ok for an October 31 feature freeze for 1.5, with a beta release shortly thereafter. The date's a little arbitrary (if we miss it, who cares?) but it's a useful target. I'd like to suggest that all user-visible changes be complete by 1.5-beta. (only bug fixes thereafter). To me, that includes documentation. Looking at JIRA, these issues need to be resolved. I'm assuming Nathan is overseeing VELOCITY-403 and Henning overseeing all build-related items ( e.g. VELOCITY-401). Malcom Edgar is revising his patch for 373. I'm working on 186 and 405 which means that 146 is up for grabs. VELOCITY-403 Enhance Velocity's LogSystem and internal use thereof VELOCITY-146 Macros not evaluated on the first attempt VELOCITY-373 Enhance ParseErrorException VELOCITY-401 remove all J2EE build tasks VELOCITY-186 #set does not allow to assign nulls---cannot it be changed? VELOCITY-405 Document new Event Handler features Henning, Nathan - is this a reasonable approach? I'm excited by the idea of letting the general user population to play with all the new features with a binary release. Best, WILL - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new ant build
Sounds good. Regarding the automatic downloads. I prefer dependencies to be bundled, sometimes you get stuck behind corporate firewalls gaining access to online resources becomes. regards Malcolm Edgar On 10/10/05, Will Glass-Husain [EMAIL PROTECTED] wrote: Great! This is a nice improvement. Just as a reminder, we should update the Building Velocity on the web page when this is all done with instructions. We should be sure to note ant 1.5 is required. I'd like to keep building Velocity as simple as possible. (making it easy for new people to get into the source code and to get not-yet-released versions). That's behind my thoughts on... 1) automatic downloads. not convinced. Will this work reliably? I don't see a big deal in just including the jar files, allowing Velocity to be built quickly and easily. 2 / 3) parser code. I like option 3 better. Again, thinking in terms of making the code easy to understand for less experienced developers. It helps to have all required source code in one tree. (therefore, please leave Parser.java in src/java). I'm ok with moving Parser.jjt out as long as this is documented in a readme file and the ant parser task automatically copies the files into the right spot. 4) Let's put reworking the examples into JIRA targeted at 1.6. I agree, this is a nice todo for some future volunteer. Best, WILL - Original Message - From: Henning P. Schmiedehausen [EMAIL PROTECTED] Newsgroups: hometree.jakarta.velocity.dev To: velocity-dev@jakarta.apache.org Sent: Sunday, October 09, 2005 12:52 PM Subject: new ant build Hi, I took some spare time this weekend to go over the build files for ant and reworking them according to the discussion that we had a few days ago. The ant build now builds only two targets: jar and jar-dep. Both jars contain all class files if built on an JDK 1.4+. It will report big warnings if either the JDBC or the logging dependency are missing. I also did the following things: * This is now ant 1.5+ only. No one should really use an older ant. * The parser part is still ant 1.6+ only * ant help is gone. Run ant -projecthelp * New default target: world. Builds the jar, the javadocs and the docs * Everything is built under bin/. Everything (*). If you nuke out the bin dir, your distribution is pristine again. Even better, run ant clean (*) Not really. The examples still put their class files into the examples directory. ant clean cleans that out, though. * ant package now builds .zip and .tar.gz distribution files. CAVEAT: .zip gets CRLF endings for DOS/Windows, .tar.gz gets LF endings for Unix/Linux. Please _TEST_! I know that all targets work independently for Linux using JDK 1.4.2 and JDK 1.5. Please test on Windows, on MacOS or whatever. Report problems! TODOs: 1) Add automatic download of the jar dependencies from ibiblio, thus allowing the .jar files to be removed from Subversion. Would reduce the download size for people pulling the tree from Subversion. (And if you can do that, you will also have a network connection to pull the jars from ibiblio.orghttp://ibiblio.org ). Similar to the download targets built by the maven-generated build.xml file 2) move the auto-generated parser tree (.../runtime/parser) out of the main source tree. This would allow a complete separation of the auto-generated code. Would also help the various maven reports 3) alternatively: Don't build the parser sources inside src/java. Build into bin/parser and require manual interaction to copy the changed files back. More work (however, the parser isn't changed that often... :-) ) but allows us to keep everything inside bin/ 4) Bikeshed painting: Rework the examples to compile and run from bin/examples I'd really like to put 1) in (if no one objects loudly I will anyway later this week), would like to see some discussion about 2)/3) whether this would be sensible and if yes what way to go. I let 4) to anyone who wants to start contributing to Velocity. This is an easy thing to do and will help you familiarize with the Velocity build system. 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 4 - 8 - 15 - 16 - 23 - 42 - 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]
Click web application framework
Hi All, I would like to introduce Click web application framework. Click is a J2EE web application framework created for commercial Java developers. Click highlights: * Very easy to learn * Event base programming model * Velocity page rendering * High performance Please see the online documentation at http://click.sourceforge.net Click is available for download at: http://sourceforge.net/project/showfiles.php?group_id=82095 I like to invite feedback, comments, bugs from anyone. regards Malcolm Edgar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
