You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Nathan Bubna <nb...@gmail.com> on 2007/04/28 06:08:32 UTC
[veltools] status of 2.x branch
hey folks,
so, i thought i'd give a heads up that VelocityTools 2.x has come
along quickly. at this point, the new code can be used to build apps
with much less configuration and much greater flexibility and power
than the previous version. it is also almost completely backwards
compatible. if you checkout and build the 2.x branch, you can run the
simple and showcase examples with no changes and only two minor
problems (having an issue with the IteratorTool and RenderTool demos).
The VelocityStruts tools are not updated to work with the new system
yet, but i should get to those soon.
please feel free to check it out and give feedback. once i get 100%
(or maybe 99.5%) backwards compatibility with the examples as they
are, i will convert them to get rid of the deprecated config and such,
in order to demonstrate the new configuration method(s).
then we (probably i) can move on to bringing Veltag in (as
VelocityViewTag) and perhaps creating a VelocityViewFilter and other
such new possibilities.
cheers,
nathan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [veltools] status of 2.x branch
Posted by Nathan Bubna <nb...@gmail.com>.
Ok, the problem with init() not being called is fixed.
also, i changed VelocityView to not load the default tool configs when
an old toolbox.xml is in use. this means that people using the old
toolbox.xml can drop in the full jar (including VelocityStruts) and
not have configuration exceptions thrown at them. as things stand,
however, once they move to a tools.xml or tools.properties
configuration and/or add the
org.apache.velocity.tools.loadDefaults=true property to their web.xml
init params, they will get a exception on startup if they are using
the full VelocityStruts jar but do not have the Struts dependencies on
the classpath.
i did this for now, because it's easier. simply logging an error
message when dependencies are missing (as opposed to throwing an
exception) will actually be pretty difficult to pull off as things are
currently organized. i'll continue to think about ways to do that or
make it optional, but it's looking like quite the challenge at the
moment.
On 5/16/07, Nathan Bubna <nb...@gmail.com> wrote:
> On 5/16/07, Claude Brisson <cl...@renegat.net> wrote:
> > Le mercredi 16 mai 2007 à 19:50 -0700, Nathan Bubna a écrit :
> > > > On the next test I made, I ran into the first real problem, I think: the
> > > > init(Object) method seems to not be called at all on an old request
> > > > tool. If you've got an idea about this symptome, well "tant
> > > > mieux" (don't know the english equivalent...), otherwise I'll
> > > > investigate - it will make me more familiar with the new codebase :-)
> > >
> > > does the log description of the toolboxes say whether the tool in
> > > question is "Old" or not?
> >
> > Yes, "old" (which -just guessing, correct me if I'm wrong- is synonym to
> > the fact that it has a "void init(Object data)" method, the one we'd
> > like to see called).
>
> yeah, it means that we need to support init(Object). tools should be
> treated as "old" if they have an init(Object) method that is NOT
> deprecated. i'm glad it at least identified the tool as "old"
> correctly. now to make sure that init() gets called...
>
> > > i thought i had this case supported, but i could be wrong. i haven't
> > > tested it much yet.
> >
> > Somehow reassuring to see you leave a few bugs sometimes...
>
> heh.
>
> > Claude
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> > For additional commands, e-mail: dev-help@velocity.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [veltools] status of 2.x branch
Posted by Nathan Bubna <nb...@gmail.com>.
On 5/16/07, Claude Brisson <cl...@renegat.net> wrote:
> Le mercredi 16 mai 2007 à 19:50 -0700, Nathan Bubna a écrit :
> > > On the next test I made, I ran into the first real problem, I think: the
> > > init(Object) method seems to not be called at all on an old request
> > > tool. If you've got an idea about this symptome, well "tant
> > > mieux" (don't know the english equivalent...), otherwise I'll
> > > investigate - it will make me more familiar with the new codebase :-)
> >
> > does the log description of the toolboxes say whether the tool in
> > question is "Old" or not?
>
> Yes, "old" (which -just guessing, correct me if I'm wrong- is synonym to
> the fact that it has a "void init(Object data)" method, the one we'd
> like to see called).
yeah, it means that we need to support init(Object). tools should be
treated as "old" if they have an init(Object) method that is NOT
deprecated. i'm glad it at least identified the tool as "old"
correctly. now to make sure that init() gets called...
> > i thought i had this case supported, but i could be wrong. i haven't
> > tested it much yet.
>
> Somehow reassuring to see you leave a few bugs sometimes...
heh.
> Claude
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [veltools] status of 2.x branch
Posted by Claude Brisson <cl...@renegat.net>.
Le mercredi 16 mai 2007 à 19:50 -0700, Nathan Bubna a écrit :
> > On the next test I made, I ran into the first real problem, I think: the
> > init(Object) method seems to not be called at all on an old request
> > tool. If you've got an idea about this symptome, well "tant
> > mieux" (don't know the english equivalent...), otherwise I'll
> > investigate - it will make me more familiar with the new codebase :-)
>
> does the log description of the toolboxes say whether the tool in
> question is "Old" or not?
Yes, "old" (which -just guessing, correct me if I'm wrong- is synonym to
the fact that it has a "void init(Object data)" method, the one we'd
like to see called).
> i thought i had this case supported, but i could be wrong. i haven't
> tested it much yet.
Somehow reassuring to see you leave a few bugs sometimes...
Claude
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [veltools] status of 2.x branch
Posted by Nathan Bubna <nb...@gmail.com>.
On 5/16/07, Claude Brisson <cl...@renegat.net> wrote:
> Le mercredi 16 mai 2007 à 17:24 -0700, Nathan Bubna a écrit :
> > > I just tried a drop-in replacement, just to see what would happen. It
> > > failed in my case due to the fact that the ViewTool interface
> > > disappeared - after all the efforts you made to reach BC we should
> > > probably put it back, as deprecated...
> >
> > hmm. it's already deprecated and useless as of the 1.3 release. it
> > should be trivial to remove reference to it. that's all you need to
> > do...
>
> Yes - and I knew it... some old tool lying around...
>
> > > (shouldn't the library FIRST search for tools.xml THEN for toolbox.xml if tools.xml wasn't found?)
> >
> > no. newer should override older. since a tools.xml should always be
> > the newest configuration file, it should have the opportunity to
> > override any tool/toolbox/data definitions configured in the old
> > toolbox.xml.
>
> Ah. If overriding comes into play, it is of course the right order...
>
> > > [01:42:42.498] java.lang.NoClassDefFoundError: org/apache/struts/action/ActionForm
> > >
> > > (I don't use any struts, only jar.view... where does this reference to struts come from?)
> >
> > ah, this is interesting. i'm guessing you were actually using the
> > full velocity-tools jar, not just the velocity-tools-view jar. if
> > you are sure you were using the velocity-tools-view jar, then i'll
> > have to try it myself. this shouldn't have happened for that.
>
> Your guess was correct. I used 'jar' instead of 'jar.view' by
> inadvertence, and since jar == jar.struts...
thought so.
> > anyway, assuming my guess is correct, here's the explanation: since
> > VelocityView will now load all available tools by default, it is
> > trying to load the VelocityStruts tools. during the load process, we
> > still create an instance to be sure (as early as possible) that we are
> > able to do so. so, when it tries to create a struts tool instance,
> > the VM is trying to load all the classes that tool needs. since you
> > don't have the struts dependencies on the classpath, that fails.
this isn't quite right. i didn't look closely at the stack trace you
sent. turns out, this is happening when just trying to look for an
init() method in the tool. no new instance is being created yet.
worse still, the error happens during a call to
ToolConfiguration.toString(). that's definitely not ok. first i'm
going to clean that up...
> > i'll have to think of a way to fail more gracefully (or perhaps just
> > log an error) when this happens.
>
> Yes, logging an error with its stacktrace looks enough to me.
then i'll look into ways to shush errors when loading default tools...
> > in the meantime, you can add an init param to your VVS declaration in
> > your web.xml with the name:
> >
> > org.apache.velocity.tools.suppressDefaults
> >
> > and the value of:
> >
> > true
> >
> > that will let you get past this error and continue testing...
>
> or using the right jar...
>
> I really like the trace of the scoped tools in the log, BTW.
>
> On the next test I made, I ran into the first real problem, I think: the
> init(Object) method seems to not be called at all on an old request
> tool. If you've got an idea about this symptome, well "tant
> mieux" (don't know the english equivalent...), otherwise I'll
> investigate - it will make me more familiar with the new codebase :-)
does the log description of the toolboxes say whether the tool in
question is "Old" or not?
i thought i had this case supported, but i could be wrong. i haven't
tested it much yet.
>
> Claude
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [veltools] status of 2.x branch
Posted by Claude Brisson <cl...@renegat.net>.
Le mercredi 16 mai 2007 à 17:24 -0700, Nathan Bubna a écrit :
> > I just tried a drop-in replacement, just to see what would happen. It
> > failed in my case due to the fact that the ViewTool interface
> > disappeared - after all the efforts you made to reach BC we should
> > probably put it back, as deprecated...
>
> hmm. it's already deprecated and useless as of the 1.3 release. it
> should be trivial to remove reference to it. that's all you need to
> do...
Yes - and I knew it... some old tool lying around...
> > (shouldn't the library FIRST search for tools.xml THEN for toolbox.xml if tools.xml wasn't found?)
>
> no. newer should override older. since a tools.xml should always be
> the newest configuration file, it should have the opportunity to
> override any tool/toolbox/data definitions configured in the old
> toolbox.xml.
Ah. If overriding comes into play, it is of course the right order...
> > [01:42:42.498] java.lang.NoClassDefFoundError: org/apache/struts/action/ActionForm
> >
> > (I don't use any struts, only jar.view... where does this reference to struts come from?)
>
> ah, this is interesting. i'm guessing you were actually using the
> full velocity-tools jar, not just the velocity-tools-view jar. if
> you are sure you were using the velocity-tools-view jar, then i'll
> have to try it myself. this shouldn't have happened for that.
Your guess was correct. I used 'jar' instead of 'jar.view' by
inadvertence, and since jar == jar.struts...
> anyway, assuming my guess is correct, here's the explanation: since
> VelocityView will now load all available tools by default, it is
> trying to load the VelocityStruts tools. during the load process, we
> still create an instance to be sure (as early as possible) that we are
> able to do so. so, when it tries to create a struts tool instance,
> the VM is trying to load all the classes that tool needs. since you
> don't have the struts dependencies on the classpath, that fails.
>
> i'll have to think of a way to fail more gracefully (or perhaps just
> log an error) when this happens.
Yes, logging an error with its stacktrace looks enough to me.
> in the meantime, you can add an init param to your VVS declaration in
> your web.xml with the name:
>
> org.apache.velocity.tools.suppressDefaults
>
> and the value of:
>
> true
>
> that will let you get past this error and continue testing...
or using the right jar...
I really like the trace of the scoped tools in the log, BTW.
On the next test I made, I ran into the first real problem, I think: the
init(Object) method seems to not be called at all on an old request
tool. If you've got an idea about this symptome, well "tant
mieux" (don't know the english equivalent...), otherwise I'll
investigate - it will make me more familiar with the new codebase :-)
Claude
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [veltools] status of 2.x branch
Posted by Nathan Bubna <nb...@gmail.com>.
On 5/16/07, Claude Brisson <cl...@renegat.net> wrote:
> Le mercredi 16 mai 2007 à 15:41 -0700, Nathan Bubna a écrit :
> > i don't know if anyone else has taken the time to try out Tools 2.x or
> > cares about it yet, but i thought i'd give an update anyway...
>
> For now I just followed your updates. I'll try them soon (as soon as
> I'll end up fighting with maven 2...). I am positively impressed by your
> work, btw.
thanks :)
> > [...]
> > As this is a significant milestone, i thought i'd ask if anyone is
> > interested in having an alpha release or milestone build. I'd love to
> > get some feedback on the progress so far, as well as the backwards
> > compatibility of things. Would that help lower the barrier for some
> > of you to try it out?
>
> I just tried a drop-in replacement, just to see what would happen. It
> failed in my case due to the fact that the ViewTool interface
> disappeared - after all the efforts you made to reach BC we should
> probably put it back, as deprecated...
hmm. it's already deprecated and useless as of the 1.3 release. it
should be trivial to remove reference to it. that's all you need to
do...
> I'm too drunk tonight (an
> official site release at work...) to commit anything but after having
> added it back, I got :
>
> [01:42:42.321] Velocity [debug] Loading configuration from: /WEB-INF/toolbox.xml
> [01:42:42.364] Velocity [trace] Searching for configuration at: /WEB-INF/tools.xml
> [01:42:42.366] Velocity [debug] Could not find file at: /WEB-INF/tools.xml
>
> (shouldn't the library FIRST search for tools.xml THEN for toolbox.xml if tools.xml wasn't found?)
no. newer should override older. since a tools.xml should always be
the newest configuration file, it should have the opportunity to
override any tool/toolbox/data definitions configured in the old
toolbox.xml.
> [01:42:42.498] java.lang.NoClassDefFoundError: org/apache/struts/action/ActionForm
>
> (I don't use any struts, only jar.view... where does this reference to struts come from?)
ah, this is interesting. i'm guessing you were actually using the
full velocity-tools jar, not just the velocity-tools-view jar. if
you are sure you were using the velocity-tools-view jar, then i'll
have to try it myself. this shouldn't have happened for that.
anyway, assuming my guess is correct, here's the explanation: since
VelocityView will now load all available tools by default, it is
trying to load the VelocityStruts tools. during the load process, we
still create an instance to be sure (as early as possible) that we are
able to do so. so, when it tries to create a struts tool instance,
the VM is trying to load all the classes that tool needs. since you
don't have the struts dependencies on the classpath, that fails.
i'll have to think of a way to fail more gracefully (or perhaps just
log an error) when this happens.
in the meantime, you can add an init param to your VVS declaration in
your web.xml with the name:
org.apache.velocity.tools.suppressDefaults
and the value of:
true
that will let you get past this error and continue testing...
> [01:42:42.498] at java.lang.Class.getDeclaredMethods0(Native Method)
> [01:42:42.498] at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
> [01:42:42.498] at java.lang.Class.getMethod0(Class.java:2670)
> [01:42:42.498] at java.lang.Class.getMethod(Class.java:1603)
> [01:42:42.498] at org.apache.velocity.tools.config.ToolConfiguration.isOldTool(ToolConfiguration.java:134)
> [01:42:42.498] at org.apache.velocity.tools.config.ToolConfiguration.toString(ToolConfiguration.java:205)
> [01:42:42.498] at java.lang.String.valueOf(String.java:2827)
> [01:42:42.498] at java.lang.StringBuilder.append(StringBuilder.java:115)
> [01:42:42.498] at org.apache.velocity.tools.config.CompoundConfiguration.appendChildren(CompoundConfiguration.java:106)
> [01:42:42.498] at org.apache.velocity.tools.config.ToolboxConfiguration.toString(ToolboxConfiguration.java:154)
> [01:42:42.498] at java.lang.String.valueOf(String.java:2827)
> [01:42:42.498] at java.lang.StringBuilder.append(StringBuilder.java:115)
> [01:42:42.498] at org.apache.velocity.tools.config.CompoundConfiguration.appendChildren(CompoundConfiguration.java:106)
> [01:42:42.498] at org.apache.velocity.tools.config.FactoryConfiguration.toString(FactoryConfiguration.java:130)
> [01:42:42.498] at java.lang.String.valueOf(String.java:2827)
> [01:42:42.498] at java.lang.StringBuilder.append(StringBuilder.java:115)
> [01:42:42.498] at org.apache.velocity.tools.view.VelocityView.configure(VelocityView.java:496)
> [01:42:42.498] at org.apache.velocity.tools.view.VelocityView.init(VelocityView.java:356)
> [01:42:42.498] at org.apache.velocity.tools.view.VelocityView.init(VelocityView.java:291)
> [01:42:42.498] at org.apache.velocity.tools.view.VelocityView.<init>(VelocityView.java:189)
> [01:42:42.498] at org.apache.velocity.tools.view.VelocityView.<init>(VelocityView.java:181)
> [01:42:42.498] at org.apache.velocity.tools.view.ServletUtils.getVelocityView(ServletUtils.java:80)
> [01:42:42.498] at org.apache.velocity.tools.view.VelocityViewServlet.init(VelocityViewServlet.java:102)
>
> If you need any custom debug log to investigate this, just ask!
>
>
> Claude
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [veltools] status of 2.x branch
Posted by Claude Brisson <cl...@renegat.net>.
Le mercredi 16 mai 2007 à 15:41 -0700, Nathan Bubna a écrit :
> i don't know if anyone else has taken the time to try out Tools 2.x or
> cares about it yet, but i thought i'd give an update anyway...
For now I just followed your updates. I'll try them soon (as soon as
I'll end up fighting with maven 2...). I am positively impressed by your
work, btw.
> [...]
> As this is a significant milestone, i thought i'd ask if anyone is
> interested in having an alpha release or milestone build. I'd love to
> get some feedback on the progress so far, as well as the backwards
> compatibility of things. Would that help lower the barrier for some
> of you to try it out?
I just tried a drop-in replacement, just to see what would happen. It
failed in my case due to the fact that the ViewTool interface
disappeared - after all the efforts you made to reach BC we should
probably put it back, as deprecated... I'm too drunk tonight (an
official site release at work...) to commit anything but after having
added it back, I got :
[01:42:42.321] Velocity [debug] Loading configuration from: /WEB-INF/toolbox.xml
[01:42:42.364] Velocity [trace] Searching for configuration at: /WEB-INF/tools.xml
[01:42:42.366] Velocity [debug] Could not find file at: /WEB-INF/tools.xml
(shouldn't the library FIRST search for tools.xml THEN for toolbox.xml if tools.xml wasn't found?)
[01:42:42.498] java.lang.NoClassDefFoundError: org/apache/struts/action/ActionForm
(I don't use any struts, only jar.view... where does this reference to struts come from?)
[01:42:42.498] at java.lang.Class.getDeclaredMethods0(Native Method)
[01:42:42.498] at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
[01:42:42.498] at java.lang.Class.getMethod0(Class.java:2670)
[01:42:42.498] at java.lang.Class.getMethod(Class.java:1603)
[01:42:42.498] at org.apache.velocity.tools.config.ToolConfiguration.isOldTool(ToolConfiguration.java:134)
[01:42:42.498] at org.apache.velocity.tools.config.ToolConfiguration.toString(ToolConfiguration.java:205)
[01:42:42.498] at java.lang.String.valueOf(String.java:2827)
[01:42:42.498] at java.lang.StringBuilder.append(StringBuilder.java:115)
[01:42:42.498] at org.apache.velocity.tools.config.CompoundConfiguration.appendChildren(CompoundConfiguration.java:106)
[01:42:42.498] at org.apache.velocity.tools.config.ToolboxConfiguration.toString(ToolboxConfiguration.java:154)
[01:42:42.498] at java.lang.String.valueOf(String.java:2827)
[01:42:42.498] at java.lang.StringBuilder.append(StringBuilder.java:115)
[01:42:42.498] at org.apache.velocity.tools.config.CompoundConfiguration.appendChildren(CompoundConfiguration.java:106)
[01:42:42.498] at org.apache.velocity.tools.config.FactoryConfiguration.toString(FactoryConfiguration.java:130)
[01:42:42.498] at java.lang.String.valueOf(String.java:2827)
[01:42:42.498] at java.lang.StringBuilder.append(StringBuilder.java:115)
[01:42:42.498] at org.apache.velocity.tools.view.VelocityView.configure(VelocityView.java:496)
[01:42:42.498] at org.apache.velocity.tools.view.VelocityView.init(VelocityView.java:356)
[01:42:42.498] at org.apache.velocity.tools.view.VelocityView.init(VelocityView.java:291)
[01:42:42.498] at org.apache.velocity.tools.view.VelocityView.<init>(VelocityView.java:189)
[01:42:42.498] at org.apache.velocity.tools.view.VelocityView.<init>(VelocityView.java:181)
[01:42:42.498] at org.apache.velocity.tools.view.ServletUtils.getVelocityView(ServletUtils.java:80)
[01:42:42.498] at org.apache.velocity.tools.view.VelocityViewServlet.init(VelocityViewServlet.java:102)
If you need any custom debug log to investigate this, just ask!
Claude
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [veltools] status of 2.x branch
Posted by Nathan Bubna <nb...@gmail.com>.
i don't know if anyone else has taken the time to try out Tools 2.x or
cares about it yet, but i thought i'd give an update anyway...
- The minor issues with the IteratorTool and RenderTool demos have
been resolved.
- The VelocityStruts tools are fully up to date with the new infrastructure.
- All the tools have been massaged so they should work with either the
deprecated XMLToolboxManager and ServletToolboxManager or the new
ToolManager and VelocityView infrastructure.
Almost everything listed on the wiki planning page has been
accomplished. Overall, i think things are about as backwards
compatible as they are going to get. The current examples run on the
new tool management infrastructure without any modification or
problems. The only people likely to be bitten in an upgrade (not
counting the many, many deprecation notices) are those implementing
their own ViewContext or otherwise extending/overriding much of the
ToolboxManager cruft. If the user and dev lists are any indication,
such people are few and far between.
As this is a significant milestone, i thought i'd ask if anyone is
interested in having an alpha release or milestone build. I'd love to
get some feedback on the progress so far, as well as the backwards
compatibility of things. Would that help lower the barrier for some
of you to try it out?
As far as further development goes, these are what's next on my mind:
- the drudgery of adding the great amounts of missing javadoc and
updating the old stuff
- creating more parity (perhaps even inheritance) between ToolManager
(for non-webapp use) and VelocityView (for webapps). this idea is the
largest threat to the stability of the new tool management API.
- the possibility of more package shifting, specifically of the
actual tool classes
- updating and integrating Veltag (soon to be known as
VelocityViewTag). this is greatly hampered by the static repo issues
in Engine 1.5's StringResourceLoader, but i still want to move ahead
on it now, without waiting on Engine 1.6. I'm still debating whether
to forget about caching (leading to lousy performance) or include a
light StringResourceLoader impl specifically for Veltag's use.
- updating the example applications to be examples of the new
management API (rather than demonstrations of the new APIs backwards
compatibility)
- updating/adding website docs for the new stuff and the many changes
if anyone is interested in joining these efforts, that'd be swell. :)
otherwise, i'll continue to plug along and look forward to your bug
reports and patches once we actually get a release out.
On 4/27/07, Nathan Bubna <nb...@gmail.com> wrote:
> hey folks,
>
> so, i thought i'd give a heads up that VelocityTools 2.x has come
> along quickly. at this point, the new code can be used to build apps
> with much less configuration and much greater flexibility and power
> than the previous version. it is also almost completely backwards
> compatible. if you checkout and build the 2.x branch, you can run the
> simple and showcase examples with no changes and only two minor
> problems (having an issue with the IteratorTool and RenderTool demos).
> The VelocityStruts tools are not updated to work with the new system
> yet, but i should get to those soon.
>
> please feel free to check it out and give feedback. once i get 100%
> (or maybe 99.5%) backwards compatibility with the examples as they
> are, i will convert them to get rid of the deprecated config and such,
> in order to demonstrate the new configuration method(s).
>
> then we (probably i) can move on to bringing Veltag in (as
> VelocityViewTag) and perhaps creating a VelocityViewFilter and other
> such new possibilities.
>
> cheers,
> nathan
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org