Re: Why were Velocity Engine v2.4 and v2.4.1 never released?

[Nathan Bubna]

There were problems with the process and the developer driving the effort
has not prioritized another attempt since. See this thread and others:

https://lists.apache.org/list?d...@velocity.apache.org:2024-2

As usual, Velocity moves slow and in fits due to its stability and general
focused-on-other-things developer community. We would, of course, always
appreciate more volunteer help!

On Tue, Jun 25, 2024 at 5:47 PM Philip Schlesinger
 wrote:

> Hi folks,
>
>
> I went looking at the GitHub repo and there was a version 2.4 prepared:
>
> https://github.com/apache/velocity-engine/commit/5d9e48ca0f1776300f1cf07199eb79c34dbe9cb7
>
>
>
> …and week later a version 2.4.1 prepared as well:
>
>
> https://github.com/apache/velocity-engine/commit/3987078ad7af781d5e6e438b65da852d3e589ade
>
>
>
> Why were these never tagged as released – or mentioned in the User or
> General mailing lists – or mentioned in the Velocity news feed?
>
>
>
>
>
>
>
>
>
> *Philip Schlesinger*
> *Solution Architect – Core Systems*
>
>
>
> [image: Blue text on a black background Description automatically
> generated] 
>
> *­­*
>
> *Office:  *+1 (949) 681-2794
>
> *24/7/365 Support:  *+1 (949) 470-2305
>
>
>
> *Americas **•** EMEA **•* *APAC*
>
> *cryoport.com* 
>
>
>
> [image: A blue circle with white and black logo Description automatically
> generated] [image: A blue circle
> with white x in it Description automatically generated]
>  [image: A blue circle with a white play
> button Description automatically generated]
> 
>
> ­­
>
> The information contained in this e-mail message is privileged and
> confidential information and is intended only for the use of the individual
> and/or entity identified in the address of this message. If the reader of
> this message is not the intended recipient, or an employee or agent
> responsible to deliver it to the intended recipient, you are hereby
> notified that any disclosure, copying, distribution, or reliance upon the
> contents of this email is strictly prohibited. If you have received this
> communication in error, please notify us by return e-mail. In this
> circumstance, we request that you delete the original message from your
> system.
>
>
>

Re: Velocity EOL Versions?

[Nathan Bubna]

The direct answer is that there are no technically EOL versions of
Velocity. But that's not really a meaningful answer, as the question kind
of assumes that we're more organized/official than we are. We're just not
that big or fast moving of a project. Things change only very slowly around
here, as the project is stable and the team is small and busy with more
significant work. Moreover, support is volunteer-based, so if someone wants
to support you and answer your question, they do. If they're not up for it
or not interested, then your question may not soon be answered.

On Wed, Dec 16, 2020 at 11:18 AM Symphoni Bush - NOAA Affiliate
 wrote:

> I am trying to find out if there are any end-of-life versions for Velocity,
> and if so, when do these versions typically become EOL/unsupported? If this
> information is publicly stored anywhere please let me know. Thanks.
>

Re: Problems with commons-beanutils-1.9.4

[Nathan Bubna]

Thanks for drilling into that, Chris! I was reading, but have no time to
help with such things right now. I imagine the beanutils folks made that
change as a security fix. Probably time for us to deprecate/kill the
setClass option, if it's unreliable. Any chance you're up for that?

On Wed, Feb 5, 2020 at 9:55 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> All,
>
> This may be an uncommon configuration, but I just upgraded from
> velocity-tools-2.0 with commons-beanutils-1.9.3 to
> commons-beanutils-1.9.4 and all my stuff broke.
>
> I spent a few hours tracking it down and I happened to have my toolbox
> configured like this:
>
> 
>   
> 
> [...]
>   
> 
>
> I was getting a message on webapp start that looked like this:
>
> FactoryConfiguration from 4 sources  with 2 toolboxes:
>  Toolbox 'application' with 1 properties [scope -auto-> application; ]
> and 12 tools:
>   Tool 'null' => null
>
> and some other weird things like:
>
>   Tool 'dateFormat' => null with 1 properties [key -auto-> dateFormat; ]
>
> The problem is that I was using the "class" attribute in my XML config
> instead of "classname".
>
> velocity-tools uses commons-digester, which uses commons-beanutils to:
>
> 1. Create an instance of ToolConfiguration for each 
> 2. Set the properties on ToolConfiguration for each 
>
> Then velocity-tools tries to instantiate the class you specify, put it
> into the toolbox, etc. The problem is with step #2 above.
>
> ToolConfiguration has two relevant setters, here:
>
>public void setClass(Class);
>public void setClassname(String);
>
> Before commons-beanutils-1.9.4, setting the "class" attribute in the
> XML would:
>
> 1. Find the "class" property on ToolConfiguration
> 2. Use Class.forName() to get an instance of java.lang.Class
> representing whatever class you wanted to use
> 3. Call ToolConfiguration.setClass(Class) with that instance of
> java.lang.Class.
>
> With commons-beanutils-1.9.4, that process fails at one point or
> another because commons-beanutils is no longer willing to instantiate
> objects of type java.lang.Class (or no longer willing to assign
> properties of java.lang.Class, it doesn't really matter).
>
> But because ToolConfiguration is designed to accept class names and do
> it's own object instantiation, you can side-step the "problem"
> introduced by commons-beanutils-1.9.4 by simply using the other
> attribute: classname
>
> When you use "classname", commons-beanutils will:
>
> 1. Find the "classname" property on ToolConfiguration
> 2. Call ToolConfiguration.setClassname(String) with the String value
> obtained from the XML attribute
>
> ... and you are good to go.
>
> I hope nobody else gets bitten by this, but in case you do, there is a
> simple solution.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl47AWoACgkQHPApP6U8
> pFjVyBAAvdRdAdtXrprLTvb8yInxLeKv8YYOXIxEcY12VgEcr9bBozd1CIdADZxq
> bKZhHRyaCJTkmNZ0q9HOX7le8LGHkYhSLh//idcoFFvobvfXXBRvXxWhL1nosH8x
> xgia0X+LrvKYHYKdwf2fEkYPBRHAyL6VmoYl4b5TN8omKJfQS9c5FWTRSP1luBST
> DlyV0p17rTrkZq+sZiZt1ErH/sTqTJ8aay9W5uAiXyk7Er7xDlwYPlAibaAL/+Xv
> 73B5+kNty59PLmUOrCyG66bgxtaxsKMbNgup6XhL0nRz34IhMmWFhFaQ0WD0cuQq
> 6d2jLrSVogktjdW7mJl+vIvHNJXVi3ywhPSOKRL5zdFLckBVXTFfZu3Id5waCg7k
> dhftiU7TUXNHkPg8jTmSRJKr+30TIiV2TLvGzlmMvhAclMhQoXNrN5mkry3uvhtT
> TAcBUZMLxQvQ/vHmT+mPD746OfYrHAID0aExfTsnToM9txhC8svmZw+weGBRJJLY
> h2vXOSKJE8Uqe8snSLUaw8jzVoDWCWAo65RLgMWpbGSv2xpvYn/gfvG4GDmb7MHX
> 9IWU3LoFraSifOs39mtqMK/CCl6MFR7Pmp5MKO6p4jxw/17402flfEl0aPhFRRSi
> wk5Ap8CLg5UQbyUv8Va0j14SVTK7osl7OMCx6aKT2cql5z4+ba8=
> =GNJs
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
> For additional commands, e-mail: user-h...@velocity.apache.org
>
>

Re: OS

[Nathan Bubna]

It runs everywhere Java runs, and Java runs pretty much everywhere. I
haven't personally run it on Windows Server 2019, but i'm certain it does
run there.

On Wed, Apr 17, 2019 at 10:40 PM liname...@outlook.com <
liname...@outlook.com> wrote:

> Hello, I am doing an investigation.
> Does Windows Server 2019 support the following products:
>
> Apache Velocity  1.5
> Apache Velocity  1.6.3
> Apache Velocity  1.7
>
> Can it be installed on windows2019?
> Is the other version supported?
> Can you tell me, thank you very much.
>
>
>

Re: Online Velocity Template Tester

[Nathan Bubna]

I'm not aware of anything out there in the public like that, though that is
a great idea!

On Wed, Nov 1, 2017 at 5:45 AM, jmeter tea  wrote:

> I didn't find any Online Velocity Template Tester
>
> It should be useful also to check template from different velocity
> versions,
> Freemarker has such useful tool http://try.freemarker.org
>
> Is there a workaround to check velocity template without using/loading full
> environment?
>

Re: [tools 2.0] ValueParser.getStrings splits on comma?

[Nathan Bubna]

Yeah, that's not ideal. You can configure the string delimiter in your tool
config. But this seems like surprising behavior for a ParameterTool to
have. The dangers of inheritance, i think. ConversionTool and ValueParser
are both built with formats in mind where it makes sense to watch for
delimited lists. ParameterTool works with inputs where lists have multiple
entries of the same key, instead of delimited values for a single entry. It
is convenient to share the interface and conversion code, but we should
probably change ParameterTool to act as expected by default.

Care to open an issue for this? Or maybe even patch it? :) I may have time
this week, but can't be sure.

On Mon, Aug 21, 2017 at 6:00 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> All,
>
> I'm not sure if I've used ValueParser.getStrings before (really,
> ParameterParser.getStrings, in this case), but I'm surprised by what
> is happening. Is this expected?
>
> Request POST parameters:
> foo=bar=This, is a comment.
>
> Velocity template code:
>
> #set($comments = $parameterParser.getStrings('comment'))
> #if(0 < $comments.size())
> #foreach($comment in $comments)
>   
>  placeholder="$msg.label.optional_comments">#htmlEscape($comment) ea>
>   
> #end## foreach
> #end## if(comments)
>
> I would expect this to produce a single  element with the
> text "This, is a comment." in the text area. Instead, I get two
>  elements, one containing "This" and the other containing
> "is a comment.".
>
> That seems ... crazy to me. I'm sure I can just change:
>
> #set($comments = $parameterParser.getStrings('comment'))
> to
> #set($comments = $request.getParameterValues('comment'))
>
> ... but I figured that ParameterParser would do the same thing, no?
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJZm4ISAAoJEBzwKT+lPKRYKnUP+wQ0ZrGhe4R5X2tCi2nmrzJW
> mgb1fqmBOd5m7TPz9iJnfj6jtLlK2u2u0cPp3BHsFyu8Y4RX5heC1RZ6fJfOPFx1
> Tq5t3JXDoK0XmOL7/VI7R5eadQww9LDbdwR10Gl7Qch9IAfsgYNINIgZwGC1OawD
> kXTc6m8lwKlvBnI7biyncDVY3pOoojh7EQNI6/sh1/hR2n2R35Fa9mpK7Y0Tjk/K
> VkvhqLcuTqii3zlGTBTS0Zzn9XE5+jzFn7wNWmrdbmMYMKKyQCne7gvzH5j3RnK+
> S9jAO/WVazKp2qI7xcAqg1upjqVfP9Rtg/cZOf0hR3swbe5+kJJcP2uw7YEDPGI0
> orFGiIVRTI8+d1FwD4rsn6uoke43p/UVm/2McCkXTkWrvcZ29BLIyin6W+i4/Z6D
> iDciX12YPD/abFsGqMEgAw4CG6WkvlZQnsAtQAtHW5EiDR4DpQQsjeYWxCE+O6SH
> r0lUhGxzed9vBR1M4l5DbnbXRaLJ+kjjZRuDPDLlfXIisD9szdgGOOG8r1dWggaa
> yZXGD/jN6MdnGp12xx7x53+RNqwAPx6o3SJqhJFUxHmOmShIOesoGdv/OsHQk4ep
> tnnlJ8c7bE8oRsH4nT3VxSymY0GCIJFzWvUr2/2lw2wSHW6Om5JoampBamerhmdk
> Lcqksts97wZmYrx+idl4
> =w9Ic
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
> For additional commands, e-mail: user-h...@velocity.apache.org
>
>

Re: [tools] Problems using struts.MessageTool

[Nathan Bubna]

Yeah, MessageTool wouldn't make a transformation like that. Pretty sure
this is a Struts issue. Good luck! :)

On Wed, Jan 27, 2016 at 11:25 AM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> All,
>
> Using Velocity-Tools 2.0.
>
> I've got a resource bundle with the following message in it:
>
> text.patient.questionnaires.available=There {0,choice,0#are no
> questionnaires|1#is one questionnaire|1'{0}''
> questionnaires} ready to take
>
> (That's all on one single line, in case my emailer wraps it, or maybe
> yours does.)
>
> I have a problem where the  HTML markup is making ChoiceFormat angry:
>
> Caused by: java.lang.IllegalArgumentException: Choice Pattern incorrect:
> 0#are no questionnaires|1#is one questionnaire|1''{0}
> questionnaires
> at java.text.MessageFormat.makeFormat(MessageFormat.java:1519)
> at java.text.MessageFormat.applyPattern(MessageFormat.java:479)
> at java.text.MessageFormat.(MessageFormat.java:362)
> at
>
> org.apache.struts.util.MessageResources.getMessage(MessageResources.java:305)
> at
> org.apache.velocity.tools.struts.MessageTool.get(MessageTool.java:157)
> at
> org.apache.velocity.tools.struts.MessageTool.get(MessageTool.java:125)
> at
> org.apache.velocity.tools.struts.MessageTool.get(MessageTool.java:191)
> [...]
>
> Note that the pattern for the ChoiceFormat has been modified: there are
> extra single-quote characters in the format that ChoiceFormat complains
> about.
>
> I haven't yet read through all the code, but if this jogs anyone's
> memory for why something like this might happen, it would be very
> helpful to me.
>
> A couple of notes:
>
> 1. I have a custom build of Velocity-Tools, so the line numbers are not
> always correct. I have confirmed that my changes do not modify the
> message key's value.
>
> 2. It looks like in MessageTool.java:157, the value has the expected ...
> umm  ... value. That is, it does not have doubled single quotes. So I
> think this is almost certainly not Velocity Tools's fault. I may have to
> give into the Struts code.
>
> Thanks,
> -chris
>
> -
> To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
> For additional commands, e-mail: user-h...@velocity.apache.org
>
>

Re: Intercepting #set

[Nathan Bubna]

That's an option. Or, since Velocity is open source, you could always hack
on it. Whichever works best for you. :)

Best luck with it!

On Fri, Nov 6, 2015 at 4:16 AM, Paul Wellner Bou <p...@wellnerbou.de> wrote:

> Thanks, Nathan,
>
> yes, thats useful, this way I get all variables used, at least.
> Unfortunately I don't find a way to intercept something like
> #set($var="whatever"). So I assume I will have to parse the vm file
> manually searching for #set occurrences?
>
> Kind regards
> Paul Wellner Bou
>
> On Thu, Nov 5, 2015 at 8:57 PM, Nathan Bubna <nbu...@gmail.com> wrote:
>
> > You could configure a NullSetEventHandler to catch when the RHS is null.
> > But i'm afraid the #set directive is deeply embedded, without a lot of
> > hooks, much like #if.  But perhaps one of the other available
> EventHandler
> > interfaces can help?
> >
> >
> >
> https://velocity.apache.org/engine/releases/velocity-1.7/apidocs/org/apache/velocity/app/event/EventHandler.html
> >
> >
> http://velocity.apache.org/engine/devel/developer-guide.html#Configuring_Event_Handlers
> >
> > On Thu, Nov 5, 2015 at 2:27 AM, Paul Wellner Bou <p...@wellnerbou.de>
> > wrote:
> >
> > > Hello,
> > >
> > > i am trying to write something analyzing our velocity file hell
> > > automatically, showing direct (via #parse) or indirect (via declared
> > > variables, #set) between vm files.
> > >
> > > I found a way to intercept the #parse directive (
> > > https://gist.github.com/paulwellnerbou/b0e53e7a045e8e90a840). Is this
> > > possible with the #set directive as well?
> > >
> > > Thank you and best regards
> > > Paul Wellner Bou
> > >
> >
>

Re: Strings

[Nathan Bubna]

When you say doesn't like either, what do you mean? How can you tell it
isn't working? What output do you get?

On Tue, Mar 10, 2015 at 12:18 PM, Philippe de Rochambeau phi...@free.fr
wrote:

 Hi Nathan,

 I have tried this

 #set ($test = abc))

 #set ($temp = $test.indexOf(a))

 but Solr 5 Velocity doesn't like either.

 I will ask the Solr folks, as you've suggested.

 Philippe


  Le 10 mars 2015 à 19:27, Nathan Bubna nbu...@gmail.com a écrit :
 
  It's fine to use String methods on String variables.
 
  The question is whether $params.q is still a String variable after your
  change. And for that, you may have to ask the Solr folks...
 
  On Tue, Mar 10, 2015 at 10:56 AM, Philippe de Rochambeau phi...@free.fr
 
  wrote:
 
  Hello,
 
  I have written a vm template for Solr 4.9 which contains the following
  line:
 
  #set ($temp = $params.q.indexOf(aaa))
 
  which worked fine until I moved the template to a Solr 5 server.
 
  Is it incorrect to use Java String methods on string variables in
 Velocity?
 
  Cheers,
 
  Philippe
 
 
 
  -
  To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
  For additional commands, e-mail: user-h...@velocity.apache.org
 
 

 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org

Re: Strings

[Nathan Bubna]

Sorry, i'm not a Solr user, so when you say it will say that it's found;
it is unclear what you are talking about.  I just wanted to know what
output Velocity is generating when given:

#set( $test = abc )
#set( $temp = $test.indexOf('a') )
$temp

I would Velocity to generate output of:

0

Does it do that? If so, then Velocity is working right. If it doesn't, then
you may need to talk to the Solr folks. Perhaps they forked Velocity and
have their own different implementation now...

On Tue, Mar 10, 2015 at 1:52 PM, Philippe de Rochambeau phi...@free.fr
wrote:

 From memory (I'm not currently at the office), Velocity says that it's
 found an a where either a comma (?) or a right parenthesis is expected.

 If the string within the indexOf method is, say, ABC, then it will say
 that it's found ABC instead of a comma or right parenthesis.

 If you want, I can give provide accurate examples tomorrow morning when I
 am back at work.

 Philippe

 Le 10 mars 2015 à 20:47, Nathan Bubna nbu...@gmail.com a écrit :
 
  When you say doesn't like either, what do you mean? How can you tell it
  isn't working? What output do you get?
 
  On Tue, Mar 10, 2015 at 12:18 PM, Philippe de Rochambeau phi...@free.fr
 
  wrote:
 
  Hi Nathan,
 
  I have tried this
 
  #set ($test = abc))
 
  #set ($temp = $test.indexOf(a))
 
  but Solr 5 Velocity doesn't like either.
 
  I will ask the Solr folks, as you've suggested.
 
  Philippe
 
 
  Le 10 mars 2015 à 19:27, Nathan Bubna nbu...@gmail.com a écrit :
 
  It's fine to use String methods on String variables.
 
  The question is whether $params.q is still a String variable after your
  change. And for that, you may have to ask the Solr folks...
 
  On Tue, Mar 10, 2015 at 10:56 AM, Philippe de Rochambeau 
 phi...@free.fr
 
  wrote:
 
  Hello,
 
  I have written a vm template for Solr 4.9 which contains the following
  line:
 
  #set ($temp = $params.q.indexOf(aaa))
 
  which worked fine until I moved the template to a Solr 5 server.
 
  Is it incorrect to use Java String methods on string variables in
  Velocity?
 
  Cheers,
 
  Philippe
 
 
 
  -
  To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
  For additional commands, e-mail: user-h...@velocity.apache.org
 
  -
  To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
  For additional commands, e-mail: user-h...@velocity.apache.org
 
 

 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org

Re: Strings

[Nathan Bubna]

It's fine to use String methods on String variables.

The question is whether $params.q is still a String variable after your
change. And for that, you may have to ask the Solr folks...

On Tue, Mar 10, 2015 at 10:56 AM, Philippe de Rochambeau phi...@free.fr
wrote:

 Hello,

 I have written a vm template for Solr 4.9 which contains the following
 line:

 #set ($temp = $params.q.indexOf(aaa))

 which worked fine until I moved the template to a Solr 5 server.

 Is it incorrect to use Java String methods on string variables in Velocity?

 Cheers,

 Philippe



 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org

Re: multiple regions in 2-phase layout render views

[Nathan Bubna]

I don't know of any totally straightforward way to achieve this particular
feature set. You could probably just do something like:

 content.vtl 
#define( $regionFoo )
  #set( $foo = 'Foo' )
 pFoo/p
#end
#set( $regionFoo = $regionFoo )

--- layout.vtl ---
html
head
  meta name=foo content=$!foo
/head
body
  div id=foo
 $!regionFoo
  /div
/body
/html

but that's not as straightforward, of course.

On Mon, Mar 2, 2015 at 11:23 PM, Christopher Townson 
christopher.town...@gmail.com wrote:

 oops :)

 good idea, Nathan -- please see
 https://gist.github.com/corinthino/44fd09e730d08ab44dfb


 On 3 March 2015 at 01:10, Nathan Bubna nbu...@gmail.com wrote:

  Chris,
 
  The attached was not attached. :) Can you put it in a gist or something?
 
  -nathan
 
  On Fri, Feb 27, 2015 at 1:56 AM, Christopher Townson 
  christopher.town...@gmail.com wrote:
 
   Hi,
  
   I have an app that is using Velocity with a 2-phase layout render
 (using
   Spring VelocityLayoutView in this case). However, Spring's layout view
   effectively restricts you to having just the one screen_content area
 in
   the layout. What I wanted to be able to do was have an arbitrary number
  of
   regions defined in the view without having to go the whole Tiles
 route,
   which I felt was both a configuration hassle and overkill.
  
   So I found myself writing a new directive (attached) to have layouts
   constituted from an arbitrary number of regions.
  
   What I am wondering is whether I am just being really stupid and there
 is
   already a straightforward way to achieve the desired result using
   pre-existing Velocity directives/tools? The #define directive didn't
  quite
   cut it here: because render is deferred until reference, the layout
   decorator cannot reference context properties established within the
   regions themselves (in my use case: allowing regions to define scripts
  and
   stylesheets that are then added to head/end-of-body in the layout
   decorator).
  
   If this isn't possible with existing Velocity tools/directives then the
   attached might be useful to other people and/or as an addition to
  Velocity?
  
   Cheers,
  
   Chris
  
  
  
   -
   To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
   For additional commands, e-mail: user-h...@velocity.apache.org
  
 

Re: multiple regions in 2-phase layout render views

[Nathan Bubna]

Chris,

The attached was not attached. :) Can you put it in a gist or something?

-nathan

On Fri, Feb 27, 2015 at 1:56 AM, Christopher Townson 
christopher.town...@gmail.com wrote:

 Hi,

 I have an app that is using Velocity with a 2-phase layout render (using
 Spring VelocityLayoutView in this case). However, Spring's layout view
 effectively restricts you to having just the one screen_content area in
 the layout. What I wanted to be able to do was have an arbitrary number of
 regions defined in the view without having to go the whole Tiles route,
 which I felt was both a configuration hassle and overkill.

 So I found myself writing a new directive (attached) to have layouts
 constituted from an arbitrary number of regions.

 What I am wondering is whether I am just being really stupid and there is
 already a straightforward way to achieve the desired result using
 pre-existing Velocity directives/tools? The #define directive didn't quite
 cut it here: because render is deferred until reference, the layout
 decorator cannot reference context properties established within the
 regions themselves (in my use case: allowing regions to define scripts and
 stylesheets that are then added to head/end-of-body in the layout
 decorator).

 If this isn't possible with existing Velocity tools/directives then the
 attached might be useful to other people and/or as an addition to Velocity?

 Cheers,

 Chris



 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org

Re: Functions

[Nathan Bubna]

(shaking his head)

please use a tool object, if at all possible. using macros as functions
gives me the willies. :)  they're meant to clean/simplify repetition of
content. just because they can be used as functions, doesn't mean they
should be. things can get ugly down that road. :)

On Thu, Feb 19, 2015 at 7:47 AM, phi...@free.fr wrote:

 Ah, I never thought of using macros as methods/functions. Thanks.

 - Mail original -
 De: Erik Hatcher erik.hatc...@gmail.com
 À: Velocity Users List user@velocity.apache.org
 Envoyé: Jeudi 19 Février 2015 16:43:43
 Objet: Re: Functions

 You mean like the macros?  Since you’re in Solr-land, look at the
 VM_global_library.vm file and how those pieces are used.  (it’s a bit
 uglier than it should be in the Solr example macro library, but should give
 you some insight there).


 —
 Erik Hatcher, Senior Solutions Architect
 http://www.lucidworks.com http://www.lucidworks.com/




  On Feb 19, 2015, at 10:22 AM, phi...@free.fr wrote:
 
 
  Is there a way to create dynamic methods/functions in Velocity Templates?
 
  -
  To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
  For additional commands, e-mail: user-h...@velocity.apache.org
 


 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org

Re: velocimacro.library - all specified required?

[Nathan Bubna]

Glad you figured it out. I must have been thinking of the default macros
file lookup, which used to warn with a big error message. I suppose it
makes sense that a specified, but missing file be treated as an error.
Though that's certainly a debatable behavior.

On Wed, Jan 14, 2015 at 1:28 PM, Erik Hatcher erik.hatc...@gmail.com
wrote:

 Thanks Nathan for the reply.

 I worked around this issue by setting up a special loader that had all the
 (all empty but one) velocimacro’s defined, allowing one or more of them to
 be overridden by earlier loaders.

 But yeah, it chokes if the velocimacro’s specified don’t exist, not just a
 warning alas.

 Erik

  On Jan 14, 2015, at 3:10 PM, Nathan Bubna nbu...@gmail.com wrote:
 
  On Fri, Jan 9, 2015 at 6:59 AM, Erik Hatcher erik.hatc...@gmail.com
 wrote:
 
  I’m trying to set up a system that has some built-in (to a JAR, class
 path
  loader) macros defined (in _macros.vm) and allows the user, in their own
  file system loader path, to define macros.vm (without underscore
 prefix) to
  add their own.
 
  I’m trying this:
engine.setProperty(RuntimeConstants.VM_LIBRARY,
 _macros.vm,macros.vm”);
 
  But I get errors if macros.vm is not found.
 
 
  Those errors should effectively just be warnings and not interrupt the
  process. (Disclaimer: i haven't dealt with that stuff in a while)
 
  Can I make it so that velocimacro.library loaded files are optional, such
  that if macros.vm isn’t there all works fine?   It’s giving me an error
  currently.
 
 
  No, sorry, no way to mark a file as optional.
 
 
  Also, when given that comma-separated list, are they loaded in that
 order
  such that a macro defined in macros.vm can override one in _macros.vm?
 
 
  Later definitions should override newer ones by default, i think. But
  again, it's been a while since i worked with macros in this way.
 
 
  Thanks for your help!
 
 Erik
 
 
 
 
  -
  To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
  For additional commands, e-mail: user-h...@velocity.apache.org
 
 


 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org

Re: Standalone pages

[Nathan Bubna]

The VelocityTools project provides several servlets that make it easy to
serve up dynamic Velocity pages. http://velocity.apache.org/tools/devel/

On Thu, Oct 9, 2014 at 6:56 AM, Logan Stinger lstin...@bluelid.com wrote:

 It depends on the contents of your velocity file.

  If your velocity file contains no variables that need replaced by the
 velocity engine and is simply an html page then the answer is yes.  You
 simply need to place the file in a directory that is accessible via url.
 I'm assuming you have an images folder or some other folder where you can
 currently access image from e.g. img
 src=myserver:8983/images/myimage.png/  You would simply put your
 velocity file in a similar directory and reference it
 http://myserver:8983/static/velocityfile.vm.  You would also need to make
 sure your server is configured to send the proper content-type headers for
 such a request (map .vm extensions to content-type text/html).

 If your velocity file is not static and has variables or velocity code
 that needs processed then your best bet might be to create a filter such
 that urls of *.vm get processed by this filter and the results spit out.


 -Original Message-
 From: phi...@free.fr [mailto:phi...@free.fr]
 Sent: Thursday, October 09, 2014 8:13 AM
 To: Velocity Users List
 Subject: Re: Standalone pages

 Hi Erik,

 thank you for your reply.

 However, come to think of it, my question is not SOLR-specific.

 I would like to know if it is possible to create lightweight Web pages
 with Velocity, in Tomcat, without resorting to servlets, JSP, etc.

 In other words, can you add a Velocity template to a Tomcat server as
 easily as you can drop a .php file in an Apache server's DocumentRoot
 directory.

 Many thanks.

 Philippe



 - Mail original -
 De: Erik Hatcher erik.hatc...@gmail.com
 À: Velocity Users List user@velocity.apache.org
 Envoyé: Jeudi 9 Octobre 2014 14:59:02
 Objet: Re: Standalone pages

 Philiippe - I just noticed you posted this to the velocity user list.  How
 Solr uses Velocity is perhaps a bit niche/different, so best to ask over on
 the Solr user list for future questions about the Solr/Velocity
 integration.  But I’m on both lists :)

 Erik

 On Oct 9, 2014, at 4:19 AM, phi...@free.fr wrote:

  Hello,
 
  I am using currently the Velocity templates that come with the example
 provided with SOLR, in Tomcat 7.
 
  I would like to add a Velocity template called test.vm, in the
 example/solr/mycollection directory, to display an HTML page containing an
 image.
 
  Unfortunately, the following URL
 
  http://myserver:8983/solr/mycollection/test
 
  returns a 404 error.
 
  http://myserver:8983/solr/mycollection/browse
 
  works, though.
 
  How does one create standalone Velocity pages, such as test.vm?
 
  Many thanks.
 
  Philippe
 
 
  -
  To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
  For additional commands, e-mail: user-h...@velocity.apache.org
 


 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org


 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org



 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org

Re: velocity eclipse plugins, VTL grammar, XText

[Nathan Bubna]

Sounds like a good idea. I don't personally use Eclipse, so it wouldn't be
of use to me, unfortunately.

On Thu, Sep 25, 2014 at 4:07 AM, Christopher Townson 
christopher.town...@gmail.com wrote:

 Hi all,

 I've long thought that the Velocity could do with a better editor plugin
 for Eclipse. I know there are a 2 or 3 out there already (veloedit being my
 usual plugin of choice) but they're beginning to look a bit outdated next
 to some of the rather nice XText-based editors I've seen for things like
 Less-css and cukes/gherkin.

 Motivated by a personal desire to have a go with XText, I was thinking to
 have a go at creating a XText-based Eclipse editor plugin for Velocity.

 My question(s) to people on this list are:

 - How useful (or not) do people think this might be to them (i.e. is it
 worth the effort?)
 - Does anyone have any experience with XText and/or advice/suggestions for
 creating an XText grammar for VTL?

 Cheers,

 Chris

Re: [tools] Toolbox preventing session serialization

[Nathan Bubna]

The Configuring section in the upgrade doc describes how to turn off the
default tools.

http://velocity.apache.org/tools/releases/2.0/upgrading.html

And yeah, a transient logger implementation sounds reasonable, but i
honestly haven't used or looked at this code in years, so it's hard to be
certain without seeing the changes or making them myself (which i don't
have time for).


On Tue, Mar 11, 2014 at 12:54 PM, Christopher Schultz 
ch...@christopherschultz.net wrote:

 Claude,

 On 3/11/14, 4:57 AM, Claude Brisson wrote:
  The session toolbox is always created by default, to let users access
  standard session tools.
 
  There is a create-session parameter you can use for this purpose, see:
http://velocity.apache.org/tools/releases/2.0/config.xml.html

 Is it possible to disable all of the session-related tools -- even those
 loaded by default? When I switched from the old format to the new
 tools format, it seems I'm getting a large number of out-of-the-box
 tools that I don't necessarily need. If I can disable those that are
 destined for the user's session, will the session toolbox disappear as
 well? Is it possible to completely-disable the default tools?

  Yes, the problem is org.apache.velocity.runtime.log.Log, which is not
  serializable. It's rather logic, since a logger is basically an output
  stream. But some session standard tools keep a reference on a logger.
  There is a design issue we should adress, here.

 It seems reasonable to make the logger transient, and then attempt to
 obtain a local logger in readObject(). That shouldn't really affect the
 design in general... just the implementation of those tools that require
 a logger.

 -chris

Re: [tools] Using java.text.MessageFormat in templates

[Nathan Bubna]

Yes, the conflict was intentional. The idea was that people using
VelocityStruts would default to using Struts' message support, so we should
default $text to use that. Whether that is still valid reasoning, i don't
know. I haven't used Struts in a very, very long time.


On Fri, Feb 21, 2014 at 10:17 AM, Christopher Schultz 
ch...@christopherschultz.net wrote:

 All,

 On 2/21/14, 12:48 PM, Christopher Schultz wrote:
  All,
 
  I have a template where I'd like to take some text in a variable and do
  parametric-replacement like new
  MessageFormat(format).format(replacements) might do.
 
  I'm already using Velocity Tools/Struts to great effect with pre-defined
  messages in properties files, but this data needs to come from a
  database and I'd rather not pre-process the data in Java code unless
  absolutely necessary.
 
  I've browsed through the tools available from Velocity Tools and I don't
  really see anything that would meet my needs. I even looked at ClassTool
  to see if I could instantiate an object through brute-force and it looks
  like that is not possible.
 
  Is there a stock tool I can use, or will I have to write my own?

 Of course, as soon as I post, I find ResourceTool.render, which appears
 to do exactly what I want.

 I can see that while the Javadoc says the method signature is
 render(Object resource, Object[] args), Velocity treats it as a varargs
 call and so you need to do:

$text.render(format, arg, arg, arg)

  instead of

$text.render(format, [arg, arg, arg])

 Use of the latter yields unfortunate results ;)

 Also, it looks like the default key for ResourceTool is text, as I can
 see this during startup:

 INFO:  Velocity  [debug] Configuring factory with:
 FactoryConfiguration from 8 sources including 4 data with 3 toolboxes:
  Toolbox 'application' with 1 properties [scope -auto- application; ]
 and 17 tools:
   Tool 'alternator' = org.apache.velocity.tools.generic.AlternatorTool
   Tool 'class' = org.apache.velocity.tools.generic.ClassTool
 [...]
   Tool 'text' = org.apache.velocity.tools.generic.ResourceTool

 ...but it conflicts with Velocity Struts, which re-defined the key:

  Toolbox 'request' with 2 properties [scope -auto- request; xhtml
 -auto- true;
  ] and 16 tools:
   Tool 'context' = org.apache.velocity.tools.view.ViewContextTool
   [...]
   Tool 'text' = org.apache.velocity.tools.struts.MessageTool

 Since the Struts key is at a closer scope (request instead of
 application), it masks the definition at the application level. I can
 clearly re-name the ResourceTool's key, but I was wondering if it was
 intentional to have a tool key naming conflict there?

 Thanks,
 -chris

Re: [tools] Using java.text.MessageFormat in templates

[Nathan Bubna]

I'll be honest: toward the end of my active VelocityTools use and work, i
was not using VelocityStruts and it did not get the attention it could
have. If you can make MessageResourcesTool extend ResourceTool, that sounds
reasonable to me.

ResourceTool does extend SafeConfig (via LocaleConfig) so you can use it in
any scope:
http://velocity.apache.org/tools/devel/javadoc/org/apache/velocity/tools/generic/SafeConfig.html


On Fri, Feb 21, 2014 at 10:58 AM, Christopher Schultz 
ch...@christopherschultz.net wrote:

 Nathan,

 On 2/21/14, 1:42 PM, Nathan Bubna wrote:
  Yes, the conflict was intentional. The idea was that people using
  VelocityStruts would default to using Struts' message support, so we
 should
  default $text to use that. Whether that is still valid reasoning, i don't
  know. I haven't used Struts in a very, very long time.

 That sounds reasonable, yet MessageTool does not extend from
 ResourceTool, so a bunch of capability is lost with that conflict. Would
 it be reasonable for MessageResourcesTool to extend ResourceTool?

 (I just realized that ResourceTool is locale-ized and therefore should
 probably not be in my application scope. Either that, or
 MessageTool.render should have another method that accepts a Locale
 argument).

 -chris

Re: Iterator Tool

[Nathan Bubna]

http://velocity.apache.org/tools/devel/javadoc/org/apache/velocity/tools/generic/LoopTool.html


On Mon, Dec 2, 2013 at 12:29 PM, Mike Clovis m...@trifecta.com wrote:

 In that Iterator Tool is deprecated, what class and code is now supported
 to accomplish the same things?

Re: Reloading velocity macros

[Nathan Bubna]

Unfortunately, this is a known bug:
https://issues.apache.org/jira/browse/VELOCITY-710


On Tue, Oct 29, 2013 at 11:57 PM, Greg Huber gregh3...@gmail.com wrote:
 Hello,

 I am using the reloading macros in a tomcat environment, which is working
 great, but when I add a new macro I seem to have to restart the container.
 Is this correct or am I missing something?

 here are my settings:

 velocityProps.setProperty(class.resource.loader.cache, false);
 velocityProps.setProperty(webapp.resource.loader.cache,false);
 velocityProps.setProperty(webapp.resource.loader.modificationCheckInterval,
 2);
 velocityProps.setProperty(velocimacro.library.autoreload, true);

 in velocity.properties

 webapp.resource.loader.path=WEB-INF/velocity/macros.vm


 Cheers Greg

-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: foreach with XMLTool

[Nathan Bubna]

Hmm. Sounds less than ideal. I don't have time to improve how the
XMLTool handles this, but if you're up for filing a bug and perhaps
even contributing a patch, that'd be great. :)

On Wed, Oct 2, 2013 at 11:05 AM, Ralph Goers ralph.go...@dslextreme.com wrote:
 I found that the problem isn't in the foreach.  It is that when you do

 #foreach($row in $xml.details.row)
$row.item1
 #end

 It results in item1 printing the item1 value for all rows.  This is because 
 get() calls find(item1) which then calls node.selectNodes() in dom4j.  
 dom4j returns all the the nodes.  The only way I have found to fix this is to 
 do

$row.find(./item1)

 This returns the value for only the current row.

 Ralph


 On Oct 2, 2013, at 8:21 AM, Ralph Goers ralph.go...@dslextreme.com wrote:

 I have an XML document of the form

 data
  details
row
  item1
  item2
/row
row
  item1
  item2
/row
  /details
 /data

 I cannot seem to find a way to successfully iterate over the row elements.  
 For some reason the data from each of the rows is being co-mingled.  Does 
 anyone have an example of iterating over xml elements using the XMLTool?

 Ralph


 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org


-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: Unexpected template parsing issue

[Nathan Bubna]

Ick.  I've no idea what's happening here.  Filing a bug report with a
test case would be appreciated.

In the meantime, the best i can do is point out that #*whitespace*#
is the more common technique for exercising complete whitespace
control.  There are fewer complications with multi-line comments than
single line ones.  Also, that technique allows people to indent the
source instead of squish it all to the left.  Might be better to stick
to the more used path.

On Thu, Aug 29, 2013 at 10:55 AM, Christopher Schultz
ch...@christopherschultz.net wrote:
 All,

 Velocity 1.7, Oracle JDK 1.7.0_25

 I found something odd recently and was able to reduce it to this simple
 test-case:

 $foo##
 $foo.bar##
 $foo.bar.baz##

 Expected output (with foo=null):

 $foo$foo.bar$foo.bar.baz

 Actual output:
 $foo$foo.bar##
 $foo.bar.baz##

 Using {..} around the references makes this example work the way I had
 expected. Also, adding spaced /before/ the ## at the end of the lines
 makes the output look as I had expected.

 Another data point:

 $foo${foo.bar}##
 $foo.bar.baz}##

 (Note trailing } after baz).

 Yields:

 $foo${foo.bar}$foo.bar.baz}

 I've been using ## at the end of lines where I want to avoid a newline
 in the output for a while... I just noticed this case recently. Is this
 something that /should/ work the way I expect, or am I abusing Velocity
 in this way?

 Thanks,
 -chris


-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: What does Velocimacro with a Body mean?

[Nathan Bubna]

D'oh. I should have seen that.  Thanks, Alex!

On Wed, Aug 7, 2013 at 2:25 PM, Alex Fedotov a...@kayak.com wrote:
 It does not work because bodyContent is an instance of the ASTNode class and
 not a string, so it does not have the trim method.

 Use something like this:

 #macro(my_trim)#set($str=$bodyContent)$str.trim()#end

 Test:

 before#@my_trim()-blah- #{end}after

 Renders:
 before-blah-after


 On Wed, Aug 7, 2013 at 5:09 PM, O. Olson olson_...@yahoo.it wrote:



 Thank you very much Nathan for clarifying what body content
 meant. At least now I know what it means, but I think I am having a
 problem
 with my trim function here. It seems to delete everything. I have no clue
 how
 this worked previously.

 To avoid naming conflicts, I decided to rename my macro. It
 now looks like:
  #macro(query_url $query_param)
 q=$query_param
 #end

 #macro(my_trim)$!bodyContent.trim()#end



 I call it using
  #@my_trim()#query_url(sometext)#end


 And the result is blank i.e. I do not see anything in the
 result. I now attempt:
 #macro(my_trim)PREPEND$!bodyContent.trim()#end


 This time I see only:
  PREPEND

 This is expected, but why nothing from  $!bodyContent.trim()

 I don't know what is happening to trim() function i.e. why
 it is not working. But thank you for answering my question.

 O. O.


 - Messaggio originale -
 Da: Nathan Bubna nbu...@gmail.com
 A: Velocity Users List user@velocity.apache.org; O. Olson
 olson_...@yahoo.it
 Cc:
 Inviato: Lunedì 5 Agosto 2013 22:34
 Oggetto: Re: What does Velocimacro with a Body mean?

 Yes, all velocimacros have bodies in their definition:

   #macro( foo ) definition only #end
   #macro( bar ) definition accepts $bodyContent #end

 Not all velocimacros accept bodies in their usage:

   #foo()
   #@bar() body content when used #end

 Produces:

   definition only
   definition accepts body content when used

 As to why your example ends up with preceding spaces, i am not
 certain. The format part in particular, because Velocity has only
 input text and output text, no format.  Try defining your #@trim
 like so:

   #macro( trim )$!bodyContent.trim()#end

 to ensure there are no sneaky whitespaces hiding in the definition.


 On Mon, Aug 5, 2013 at 9:25 AM, O. Olson olson_...@yahoo.it wrote:
  Hi,
 
  I am new to
  Velocity and I am wondering what Velocimacro with a Body means?
  Here, I am referring to the description in
  http://velocity.apache.org/engine/releases/velocity-1.7/vtl-reference-guide.html#amacro_-_Allows_users_to_define_a_Velocimacro_VM_a_repeated_segment_of_a_VTL_template_as_required
 
  I thought
  all Velocimacros had bodies, just like all non-trivial functions in C or
  Java
  have bodies. I attempted the use the above suggestion given in the URL
  and it did not
  work.
 
  I attempted the following in my Global Library:
 
  #macro(query_url $query_param)
  q=$query_param
  #end
 
  #macro(trim)
  $!bodyContent.trim()
  #end
 
  According to the above URL, in my template, I called this
  using:
 
  #@trim()#query_url(sometext)#end
 
 
  The result seems to be:
  q=sometext
 
  i.e. there are spaces in the front that I don't like.
  (Depending on the format you are looking at, these preceeding spaces
  might be
  deleted, but they appear in the rendered results.) Any ideas what I am
  doing
  wrong?
 
  Thank you in advance,
  O. O.
 
  -
  To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
  For additional commands, e-mail: user-h...@velocity.apache.org
 

 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org

 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org



-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: What does Velocimacro with a Body mean?

[Nathan Bubna]

Yes, all velocimacros have bodies in their definition:

  #macro( foo ) definition only #end
  #macro( bar ) definition accepts $bodyContent #end

Not all velocimacros accept bodies in their usage:

  #foo()
  #@bar() body content when used #end

Produces:

  definition only
  definition accepts body content when used

As to why your example ends up with preceding spaces, i am not
certain. The format part in particular, because Velocity has only
input text and output text, no format.  Try defining your #@trim
like so:

  #macro( trim )$!bodyContent.trim()#end

to ensure there are no sneaky whitespaces hiding in the definition.


On Mon, Aug 5, 2013 at 9:25 AM, O. Olson olson_...@yahoo.it wrote:
 Hi,

 I am new to
 Velocity and I am wondering what Velocimacro with a Body means?
 Here, I am referring to the description in 
 http://velocity.apache.org/engine/releases/velocity-1.7/vtl-reference-guide.html#amacro_-_Allows_users_to_define_a_Velocimacro_VM_a_repeated_segment_of_a_VTL_template_as_required

 I thought
 all Velocimacros had bodies, just like all non-trivial functions in C or Java
 have bodies. I attempted the use the above suggestion given in the URL and it 
 did not
 work.

 I attempted the following in my Global Library:

 #macro(query_url $query_param)
 q=$query_param
 #end

 #macro(trim)
 $!bodyContent.trim()
 #end

 According to the above URL, in my template, I called this
 using:

 #@trim()#query_url(sometext)#end


 The result seems to be:
 q=sometext

 i.e. there are spaces in the front that I don't like.
 (Depending on the format you are looking at, these preceeding spaces might be
 deleted, but they appear in the rendered results.) Any ideas what I am doing
 wrong?

 Thank you in advance,
 O. O.

 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org


-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: In VTL, simply reverse a list with java.util.Collection static method

[Nathan Bubna]

http://velocity.apache.org/engine/devel/developer-guide.html#supportforstaticclasses

On Mon, May 6, 2013 at 12:15 PM, Travis P allotro...@gmail.com wrote:
 Via web searching, I've found quite a few people reversing lists by writing
 out loops.

 Seems to me, we should be able to something like:

 #set ($lst = [a,b,c])
 #set ($revlst = $lst)
 $Collection.reverse($revlst)

 where $Collection.reverse refers to the java.util.Collections static method
 static 
 void*reversehttp://w3.hursley.ibm.com/java/docs/jdk5.0/api/java/util/Collections.html#reverse(java.util.List)
 *(List http://w3.hursley.ibm.com/java/docs/jdk5.0/api/java/util/List.html
 ? list)
   Reverses the order of the elements in the specified list.

 but I don't see any way to do that without writing a custom tool.  Which
 seems heavy-handed for such a basic thing.  Am I missing something?

 (I'm using velocity-1.7, velocity-tools-view-2.0, running on tomcat-7.0.39)

 -Travis

-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: Tools and Sessions

[Nathan Bubna]

It's because by default it avoids session creation, passing in the
result of request.getSession(false).

You can configure your session toolbox to pass true and create
sessions.  See the examples at:
http://velocity.apache.org/tools/devel/config.html

(which i just noticed are all misformated. argh.)

On Sun, Apr 14, 2013 at 2:09 AM, Andrew Ducker and...@ducker.org.uk wrote:
 Odd one, that I'm hoping someone can clear up for me.

 I created a tool, and added setters for:
 public void setRequest(HttpServletRequest request)
 and
 public void setSession(HttpSession session)

 The session is being passed in as null, but request.getSession() is
 returning the session I'd expect to get.

 Any idea why this would be?

 (Running under Google App Engine, which doesn't seem to cause a problem
 otherwise.  But you never know...)

 Andy

 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org


-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: runtime.parser.Parser maintains multiple VelocityCharStreams?

[Nathan Bubna]

I've no idea.  I've never really dug into those much.  If Jarkko is
kicking around, he might know.

On Fri, Apr 12, 2013 at 10:41 AM, Christopher Schultz
ch...@christopherschultz.net wrote:
 All,

 I've been doing some profiling looking for wasted memory in my webapp
 and I've discovered that org.apache.velocity.runtime.parser.Parser
 contains a few members that appear to be (essentially) duplicates.

 First, there is the velocharstream member which is a
 VelocityCharStream. Then, there is also a token_source member which is a
 ParserTokenManager which has a separate VelocityCharStream
 (velcharstream member). YourKit reports that these two are distinct
 objects, and they don't appear to share anything so I think they really
 are distinct.

 Each VelocityCharStream has a pair of 4096-byte buffers (bufcolumn and
 bufline) plus a 8192-byte buffer in the inputStream member (a
 java.io.InputStreamReader), so each Parser is currently eating up 16k of
 memory in buffers. Yes, I know it's really nothing, but I'm wondering if
 buffers (or streams) are being allocated when they don't need to be
 allocated.

 Does anyone know why there might be two separate VelocityCharStreams at
 the Parser level? How about the 2 bufline/bufcolumn buffers in
 VelocityCharStream as well as the 8192-byte InputStreamReader buffer?

 The code has no inline documentation of Javadoc to suggest the purpose
 of these members.

 Thanks,
 -chris


-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: Problems finding template

[Nathan Bubna]

http://velocity.apache.org/engine/devel/developer-guide.html#Configuring_Resource_Loaders

On Tue, Feb 19, 2013 at 3:41 PM, Garey Mills
gmi...@library.berkeley.edu wrote:
 Hello -

 I am writing a web app that starts a thread to perform some operations
 that take too much time to require the user to wait for them.

 In that thread, I am trying to use Velocity to write out some data into
 a template. I start a VelocityEngine, init it, create a Velocity Context
 and then call mergeTemplate.  The problem is that I am at a loss about how
 to specify the location of the template. I have it in a directory
 called 'templates' in the root directory of my web app, but neither
 '/templates/template' or 'templates/template works. Investigating
 a little, I find that the current working directory is in tomcat's bin
 directory.

 Is there somewhere to specify where Velocity Engine should look for
 templates?

 --
 Garey Mills
 Library Systems Office
 UC Berkeley


 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org


-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: Simple list of all methods, properties, variables available to templates?

[Nathan Bubna]

Yeah, it's not $context.put(context, context) in a template, but
context.put(context, context); in your Java, so that the template
can access $context.  It doesn't contain itself by default.

Similarly, with ClassTool.  You need to put an instance into the
context (context.put(class, new ClassTool()); before you can use
$class

On Fri, Feb 15, 2013 at 2:33 PM, ANS Developer Team d...@answeb.org wrote:
 Thanks Nathan, just got a chance to test this.  $context.put(context,
 context) is just being written verbatim, rather than being evaluated.

 I've stuck into several different locations (templates, structures,
 content), some of which I know have Velocity processing enabled.

 Since it's not being evaluated, does this mean the context doesn't have a
 reference to itself in my CMS?

 Tried $class.inspect($context.get($key)), but same result.


 On Wed, Feb 13, 2013 at 11:08 AM, Nathan Bubna nbu...@gmail.com wrote:

 Yes, if the context has a reference to itself: context.put(context,
 context);
 Then you can #foreach( $key in $context.keySet() ) $key =
 $context.get($key)#end
 And if you add something like the ClassTool from the VelocityTools
 project, then you can avoid the nastiness of trying to use the
 reflection API within a template and explore what
 $class.inspect($context.get($key)) gives you.


 http://velocity.apache.org/tools/devel/javadoc/org/apache/velocity/tools/generic/ClassTool.html

 But again, you need to have access to the VelocityContext being used
 to merge the templates.  I don't know if your CMS is using
 VelocityTools, but all of this gets much easier if it is using Tools
 2.  There's even a ContextTool:

 http://velocity.apache.org/tools/devel/javadoc/org/apache/velocity/tools/generic/ContextTool.html

 On Tue, Feb 12, 2013 at 8:10 PM, ANS Developer Team d...@answeb.org
 wrote:
  Thanks, is it possible to do that from within a Velocity template?
 
 
  On Tue, Feb 12, 2013 at 2:09 PM, Sergiu Dumitriu
  sergiu.dumit...@gmail.comwrote:
 
  On 02/12/2013 12:17 PM, ANS Developer Team wrote:
   Ah thanks, it's pretty sparse, hence why I'm asking here.  Much
   appreciated, will figure it out from source.
 
  If you can get your hands on the current VelocityContext, then you could
  list all the properties it contains (it extends Map).
 
  
   On Tue, Feb 12, 2013 at 12:42 AM, Nathan Bubna nbu...@gmail.com
 wrote:
  
   Velocity doesn't provide anything but the syntax.  You will have to
   seek documentation from Vosao CMS.
  
   On Mon, Feb 11, 2013 at 6:57 PM, ANS Developer Team d...@answeb.org
   wrote:
   Hi all, I'm trying to find a list all of the above that can be used
 in
  a
   template, preferably with a brief description of what it does (but
  that's
   not entirely necessary).
  
   I'm building site using the Velocity-based Vosao CMS, and have no
 idea
   what
   what methods, properties, and variables are available to me except
 the
   sparse few used in the example Blog app.
  
   For example there's a $page.friendlyURL property, but what other
   properties
   does $page have?  Having trouble finding this information.
  
   I've found the Velocity VTL Reference Guide, but that's more of a
  syntax
   uide without a comprehensive list, and I've found the online
 Velocity
  API
   docs, but that's overkill and I still can't find the $page object
 in it
   (not sure what class it's in).
  
   Any help on this much appreciated!
 
 
  -
  To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
  For additional commands, e-mail: user-h...@velocity.apache.org
 
 

 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org



-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: Simple list of all methods, properties, variables available to templates?

[Nathan Bubna]

Yes, if the context has a reference to itself: context.put(context, context);
Then you can #foreach( $key in $context.keySet() ) $key = $context.get($key)#end
And if you add something like the ClassTool from the VelocityTools
project, then you can avoid the nastiness of trying to use the
reflection API within a template and explore what
$class.inspect($context.get($key)) gives you.

http://velocity.apache.org/tools/devel/javadoc/org/apache/velocity/tools/generic/ClassTool.html

But again, you need to have access to the VelocityContext being used
to merge the templates.  I don't know if your CMS is using
VelocityTools, but all of this gets much easier if it is using Tools
2.  There's even a ContextTool:
http://velocity.apache.org/tools/devel/javadoc/org/apache/velocity/tools/generic/ContextTool.html

On Tue, Feb 12, 2013 at 8:10 PM, ANS Developer Team d...@answeb.org wrote:
 Thanks, is it possible to do that from within a Velocity template?


 On Tue, Feb 12, 2013 at 2:09 PM, Sergiu Dumitriu
 sergiu.dumit...@gmail.comwrote:

 On 02/12/2013 12:17 PM, ANS Developer Team wrote:
  Ah thanks, it's pretty sparse, hence why I'm asking here.  Much
  appreciated, will figure it out from source.

 If you can get your hands on the current VelocityContext, then you could
 list all the properties it contains (it extends Map).

 
  On Tue, Feb 12, 2013 at 12:42 AM, Nathan Bubna nbu...@gmail.com wrote:
 
  Velocity doesn't provide anything but the syntax.  You will have to
  seek documentation from Vosao CMS.
 
  On Mon, Feb 11, 2013 at 6:57 PM, ANS Developer Team d...@answeb.org
  wrote:
  Hi all, I'm trying to find a list all of the above that can be used in
 a
  template, preferably with a brief description of what it does (but
 that's
  not entirely necessary).
 
  I'm building site using the Velocity-based Vosao CMS, and have no idea
  what
  what methods, properties, and variables are available to me except the
  sparse few used in the example Blog app.
 
  For example there's a $page.friendlyURL property, but what other
  properties
  does $page have?  Having trouble finding this information.
 
  I've found the Velocity VTL Reference Guide, but that's more of a
 syntax
  uide without a comprehensive list, and I've found the online Velocity
 API
  docs, but that's overkill and I still can't find the $page object in it
  (not sure what class it's in).
 
  Any help on this much appreciated!


 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org



-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: Simple list of all methods, properties, variables available to templates?

[Nathan Bubna]

Velocity doesn't provide anything but the syntax.  You will have to
seek documentation from Vosao CMS.

On Mon, Feb 11, 2013 at 6:57 PM, ANS Developer Team d...@answeb.org wrote:
 Hi all, I'm trying to find a list all of the above that can be used in a
 template, preferably with a brief description of what it does (but that's
 not entirely necessary).

 I'm building site using the Velocity-based Vosao CMS, and have no idea what
 what methods, properties, and variables are available to me except the
 sparse few used in the example Blog app.

 For example there's a $page.friendlyURL property, but what other properties
 does $page have?  Having trouble finding this information.

 I've found the Velocity VTL Reference Guide, but that's more of a syntax
 uide without a comprehensive list, and I've found the online Velocity API
 docs, but that's overkill and I still can't find the $page object in it
 (not sure what class it's in).

 Any help on this much appreciated!

-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: Is it possible to continue processing instead of throwing a ParseErrorException?

[Nathan Bubna]

Velocity uses a JavaCC generated parser.  So far as i know, JavaCC
doesn't support this kind of soft-fail parsing.

On Wed, Oct 3, 2012 at 12:27 PM, Collin Peters
cpet...@intouchfollowup.com wrote:
 Just wondering if it is possible to skip bad merge fields and just have it
 try to continue?  The use case is that we want to present the processed
 text, even if it has errors, to the end user so that the error can be
 visually seen

 e.g
 Dear $!{user.firstName}, welcome to $!{club.nspan
 style=font-size:12ame}/span

 Would show up as
 Dear Johnny, welcome to $!{club.nspan style=font-size:12ame}/span

 --
 Collin Peters
 cpet...@intouchfollowup.com
 (206) 855-6656 (Direct Line)

-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: Having trouble doing math with values retrieved from external data source

[Nathan Bubna]

Well, so long as you have other reasons too. :)  Just stay far away
from 1.5.  1.6 or 1.7 have far fewer issues.

On Tue, Oct 2, 2012 at 8:53 AM, Dalrymple, Craig - OCIO-ITS, Kansas
City, MO craig.dalrym...@kcc.usda.gov wrote:
 There are some other things that are available with later releases that I 
 would like to take advantage of, like the $foreach.count.  That appears to be 
 a 1.6 and later capablility.

 Craig K. Dalrymple
 Information Services Consultant (Contractor)
 FMI/Unisys Inc. working for
 USDA/OCIO/ITS/IOD/NOB
 FMI(BPA # AG-3144-B-12-0003)
 6501 Beacon Drive
 Kansas City, MO 64113
 816-926-8819  (W)


 -Original Message-
 From: Nathan Bubna [mailto:nbu...@gmail.com]
 Sent: Tuesday, October 02, 2012 10:47 AM
 To: Velocity Users List
 Subject: Re: Having trouble doing math with values retrieved from external 
 data source

 Glad it worked for you.  If you're not doing new dev and this is your
 only issue, i'd stick with 1.4, despite its inferiority.  Never
 upgrade just for the sake of upgrading.

 On Tue, Oct 2, 2012 at 8:19 AM, Dalrymple, Craig - OCIO-ITS, Kansas
 City, MO craig.dalrym...@kcc.usda.gov wrote:
 Thanks, this might actually work, however my test device was removed, so now 
 I have other issues.  However, this is basically what I was trying to do, 
 but you came up with a different approach.

 At last check, Cisco has no plans to go any higher than 1.4.  It's not a 
 product that accounts for much (any?) revenue, so why pursue it?  I am 
 considering doing the upgrade myself, but I need to stand up another test 
 box to make sure I don't break anything else -- the software appears pretty 
 fickle to changes.

 Craig K. Dalrymple
 Information Services Consultant (Contractor)
 FMI/Unisys Inc. working for
 USDA/OCIO/ITS/IOD/NOB
 FMI(BPA # AG-3144-B-12-0003)
 6501 Beacon Drive
 Kansas City, MO 64113
 816-926-8819  (W)

 -Original Message-
 From: Nathan Bubna [mailto:nbu...@gmail.com]
 Sent: Monday, October 01, 2012 6:18 PM
 To: Velocity Users List
 Subject: Re: Having trouble doing math with values retrieved from external 
 data source

 Velocity 1.4, eh?  I suppose upgrading to 1.7 isn't an option?

 With 1.4, you have a hack:

 #set( $Integer = 1 )
 #set( $wanCEIP = $Integer.parseInt($octetFour) + 1)

 or you can google for VelocityTools' MathTool, drop an instance in the
 context and use that to handle the parsing and/or addition in a
 cleaner way:

 #set( $wanCEIP = $math.add($octetFour, 1) )

 On Mon, Oct 1, 2012 at 3:01 PM, Dalrymple, Craig - OCIO-ITS, Kansas
 City, MO craig.dalrym...@kcc.usda.gov wrote:
 First, I apologize if this question has come up before, but after doing 
 some lengthy searching, I was unable to find anything related to the issue 
 I am having.

 I have included the segment of the template that is causing my headache 
 below.  Let me explain a little what I am doing, and give a background on 
 why.

 The client I work for has a product from Cisco (Cisco Configuration Engine) 
 for configuring large numbers of network devices.  We are trying to make 
 this rather cumbersome tool a bit easier to use.  Basically what it does is 
 keep a database of information about each object that can be included into 
 templates, which are then deployed to those objects to keep configurations 
 close to a uniform standard.  This tool supports two template formats, the 
 legacy and proprietary .cfgtpl, and .vm which is based on the Velocity 
 Template Engine.  Their legacy format allows for some simplification with 
 #include directives and very limited conditional checking --
 #if (a == b)
   Do this
 #else
   Do something else
 #endif

 By limited I mean you can check for equality, and thats all you can check.  
 Oh, and you cannot have nested condition tests.  Obviously, Velocity 
 doesn't have this limitation, even on the older version that Cisco has 
 deployed (1.4).

 One of the simplifications we would like to include is to handle IP 
 addressing for these network elements.  Currently this is input by users, 
 and may or may not be accurate.  Since the clients IP addresses conform to 
 a pretty strict standard, the only information we really need is the 
 subnet, and the subnet mask.  With this, we can compute the IP addresses.

 Below is the segment that has me going even more prematurely bald.  I am 
 trying to break an IP4 address into its four parts given the subnet 
 information, then assign the CER IP address (my side of the MPLS 
 connection) by adding 1 to this value, and the PER (carrier side) by adding 
 2.  I have managed to break the address up into a list, and can access the 
 elements directly.  However, when I try to manipulate the values it becomes 
 really obvious that I am trying to do addition to strings and not integers.

 #set ( $wanSubnet = $!{dsobj.getValue('WAN-Subnet')} ) ## retrieves data 
 from database
 ! breakupIP($wanSubnet) ## this is a Cisco IOS comment line.  It is the 
 only way I can really debug my code

Re: Macro caching and other caching

[Nathan Bubna]

And you're sure you're only using VelocityEngine.evaluate?  Not
loading templates through the resource loader?  Or are you doing both?

On Mon, Jul 30, 2012 at 2:51 PM, Bradley Wagner
bradley.wag...@hannonhill.com wrote:
 Nathan,

 Tokens are referenced by
 org.apache.velocity.runtime.parser.node.ASTReference which seem to be
 referenced by arrays of org.apache.velocity.runtime.parser.node.Nodes.  Most
 of the classes referencing these things are AST classes in the
 org.apache.velocity.runtime.parser.node package.

 Here's our properties file:

 runtime.log.logsystem.class =
 org.apache.velocity.runtime.log.Log4JLogChute,org.apache.velocity.runtime.log.AvalonLogSystem
 runtime.log.logsystem.log4j.logger=com.hannonhill.cascade.velocity.VelocityEngine

 runtime.log.error.stacktrace = false
 runtime.log.warn.stacktrace = false
 runtime.log.info.stacktrace = false
 runtime.log.invalid.reference = true

 input.encoding=UTF-8
 output.encoding=UTF-8

 directive.foreach.counter.name = velocityCount
 directive.foreach.counter.initial.value = 1

 resource.loader = class

 class.resource.loader.description = Velocity Classpath Resource Loader
 class.resource.loader.class =
 org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader

 velocimacro.permissions.allow.inline.local.scope = true

 Thanks!
 Bradley

 On Mon, Jul 30, 2012 at 4:47 PM, Nathan Bubna nbu...@gmail.com wrote:

 On Mon, Jul 30, 2012 at 1:30 PM, Bradley Wagner
 bradley.wag...@hannonhill.com wrote:
  Thanks for the input.
 
  What we're seeing is that Velocity seems to be holding on to a lot
  of org.apache.velocity.runtime.parser.Token objects (around 5 million).
  We
  allow people to write arbitrary Velocity templates in our system and are
  evaluating them with:
 
  VelocityEngine.evaluate(Context context, Writer writer, String logTag,
  Reader reader)
 
  I was under the impression that Templates evaluated this way are
  inherently
  not cacheable. Is that the case? If that's not true, is there a way to
  control the cache Velocity is using for these?

 me too.  just out of curiosity, what properties are you using for
 configuration?  and can you tell any more about what class is holding
 onto those Tokens?

  On Thu, Jul 19, 2012 at 10:26 AM, Alex Fedotov a...@kayak.com wrote:
 
  I think that Velocity has one global hash table for macros from the
  *.vm
  libraries and that is more or less static for the life time of the
  Velocity
  engine.
 
  I wish there there was a mechanism to control the list of the *.vm
  files
  and their order of lookup for each individual merge (thread). This
  would
  facilitate macro overloads based on the context.
  Unfortunately this feature is not available.
 
  I think the 1.7 behavior is (more or less):
 
  When template reference is found (i.e. #parse(x)) it is looked-up in
  the
  resource cache and if found there (with all the expiration checks,
  etc.)
  the parsed AST tree is used.
  If not found the template is loaded from the file, actually parsed and
  put
  into the cache. During the actual parsing process the macros that are
  defined in the template are put into the macro manager cache which is
  organized as:
  defining template name (name space) = macro name = AST macro code
  The AST is then rendered in the current context running #parse.
 
  When the time comes to call a macro there is a lookup process which can
  be
  influenced by some props, but the most general case is:
 
  1. Lookup in the global *.vm files, if found use that.
  2. Lookup in the same name space that calls the macro, if found use
  that.
  3. Going back through the list of the #parse-d templates lookup in
  each
  name space on the stack.
 
  The stack can be actually very long too, for example
 
  #foreach($templ in [1..5])
#parse(${templ}.vtl)
  #end
 
  #mymacro()
 
  The lookup list here would contain:
 
  1.vtl, 2.vtl, 3.vtl, 4.vtl, 5.vtl
 
  This is true even for cases where the name is the same:
 
  #foreach($item in [1..5])
#parse('item.vtl')
  #end
 
  The lookup list here would contain:
 
  item.vtl, item.vtl, item.vtl, item.vtl, item.vtl
 
  There is no attempt to optimize the lookup list and collapse the
  duplicates.
 
  Unfortunately 1.7 also had some nasty concurrency bugs there that had
  to do
  with clearing the name space of all the macros and repopulating it
  again on
  each parse which did not work at all with multiple threads.
  One thread could clear the name space while another was doing a lookup,
  etc.
 
  I think there was an effort to redesign that part in 2.0, but I have
  not
  looked at that yet.
 
  Alex
 
  On Wed, Jul 18, 2012 at 5:42 PM, Bradley Wagner 
  bradley.wag...@hannonhill.com wrote:
 
   Hi,
  
   We recently made some changes to our software to use just a single
   VelocityEngine as per recommendations on this group.
  
   We ran into an issue where macros were all of the sudden being shared
   across template renders because we had not
   specified

Re: Macro caching and other caching

[Nathan Bubna]

I dunno.  I keep casting about for possible explanations, but my
current rusty-ness with the Velocity codebase (haven't hacked on it
much in a couple years) is hampering me.  At this point, all i can say
is that i'm not sure where the cached nodes are from, but i suspect
either your few ClasspathResourceLoader templates (probably unlikely
to hit 5mil tokens unless they're huge) or evaluated macros (but i'm
not sure why they're being cached).

In any case, the proper fix would be resolving
https://issues.apache.org/jira/browse/VELOCITY-797 (the way it should
have been done in the first place) but my work schedule makes it
unlikely i'll get to it anytime soon.  Sigh.

On Tue, Jul 31, 2012 at 8:37 AM, Bradley Wagner
bradley.wag...@hannonhill.com wrote:
 Whoops, was misreading the API. It's actually that tempTemplateName
 variable.


 On Tue, Jul 31, 2012 at 11:21 AM, Bradley Wagner
 bradley.wag...@hannonhill.com wrote:

 A StringWriter:

 String template = ... the string containing the dynamic template to
 generate ...
 // Get a template as stream.
 StringWriter writer = new StringWriter();
 StringReader reader = new StringReader(template);
 // create a temporary template name
 String tempTemplateName = velocityTransform- +
 System.currentTimeMillis();

 // ask Velocity to evaluate it.
 VelocityEngine engine = getEngine();
 boolean success = engine.evaluate(context, writer, tempTemplateName,
 reader);

 if (!success)
 {
 LOG.debug(Velocity could not evaluate template with content: \n +
 template);
 return null;
 }
 LOG.debug(Velocity successfully evaluted template with content: \n +
 template);
 String strResult = writer.getBuffer().toString();
 return strResult;

 On Tue, Jul 31, 2012 at 11:10 AM, Nathan Bubna nbu...@gmail.com wrote:

 What do you use for logTag (template name) when you are using evaluate()?

 On Tue, Jul 31, 2012 at 8:01 AM, Bradley Wagner
 bradley.wag...@hannonhill.com wrote:
  Doing both. In the other case we're using a classpath resource loader
  to
  evaluate templates like this:
 
  VelocityContext = ... a context that we're building each time ...
  VelocityEngine engine = ... our single engine ...
  Template template = engine.getTemplate(templatePath);
  StringWriter writer = new StringWriter();
  template.merge(context, writer);
 
  However, we only have 7 of those static templates in our whole system.
 
  On Tue, Jul 31, 2012 at 10:52 AM, Nathan Bubna nbu...@gmail.com
  wrote:
 
  And you're sure you're only using VelocityEngine.evaluate?  Not
  loading templates through the resource loader?  Or are you doing both?
 
  On Mon, Jul 30, 2012 at 2:51 PM, Bradley Wagner
  bradley.wag...@hannonhill.com wrote:
   Nathan,
  
   Tokens are referenced by
   org.apache.velocity.runtime.parser.node.ASTReference which seem to
   be
   referenced by arrays of
   org.apache.velocity.runtime.parser.node.Nodes.
   Most
   of the classes referencing these things are AST classes in the
   org.apache.velocity.runtime.parser.node package.
  
   Here's our properties file:
  
   runtime.log.logsystem.class =
  
  
   org.apache.velocity.runtime.log.Log4JLogChute,org.apache.velocity.runtime.log.AvalonLogSystem
  
  
   runtime.log.logsystem.log4j.logger=com.hannonhill.cascade.velocity.VelocityEngine
  
   runtime.log.error.stacktrace = false
   runtime.log.warn.stacktrace = false
   runtime.log.info.stacktrace = false
   runtime.log.invalid.reference = true
  
   input.encoding=UTF-8
   output.encoding=UTF-8
  
   directive.foreach.counter.name = velocityCount
   directive.foreach.counter.initial.value = 1
  
   resource.loader = class
  
   class.resource.loader.description = Velocity Classpath Resource
   Loader
   class.resource.loader.class =
   org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader
  
   velocimacro.permissions.allow.inline.local.scope = true
  
   Thanks!
   Bradley
  
   On Mon, Jul 30, 2012 at 4:47 PM, Nathan Bubna nbu...@gmail.com
   wrote:
  
   On Mon, Jul 30, 2012 at 1:30 PM, Bradley Wagner
   bradley.wag...@hannonhill.com wrote:
Thanks for the input.
   
What we're seeing is that Velocity seems to be holding on to a
lot
of org.apache.velocity.runtime.parser.Token objects (around 5
million).
We
allow people to write arbitrary Velocity templates in our system
and
are
evaluating them with:
   
VelocityEngine.evaluate(Context context, Writer writer, String
logTag,
Reader reader)
   
I was under the impression that Templates evaluated this way are
inherently
not cacheable. Is that the case? If that's not true, is there a
way
to
control the cache Velocity is using for these?
  
   me too.  just out of curiosity, what properties are you using for
   configuration?  and can you tell any more about what class is
   holding
   onto those Tokens?
  
On Thu, Jul 19, 2012 at 10:26 AM, Alex Fedotov a...@kayak.com
wrote:
   
I think that Velocity has one global hash table

Re: Macro caching and other caching

[Nathan Bubna]

On Tue, Jul 31, 2012 at 10:48 AM, Bradley Wagner
bradley.wag...@hannonhill.com wrote:
 Yea, we're starting to figure that out. It seems like it's the macro cache
 that's growing and we have no way of clearing that cache or disabling it
 altogether.

 Any ideas there?

hmm.  i haven't confirmed this and am rusty on the codebase, but
evaluate() uses the logTag as the template name for lack of anything
else.  VelocimacroFactory uses template names as keys for local macro
namespaces.  by generating logTags for every evaluate, you appear to
be saving innumerable macro namespaces.  ideally, these should be
dumped at the end of evaluate(), but aren't.  that's a bug and
probably deserves its own issue (wanna report it).

so, i see three options:

1) accept a certain amount of useless-to-you inline macro caching and
adjust your logTag creation to be user-associated or something like
that that doesn't make it an infinite number of templates (as your
current system would appear to).

2) go for the quick, partial fix and change
RuntimeInstance.evaluate(context,writer,logTag,reader) to call
dumpVMNamespace(logTag) before returning but after rendering.  i'm
somewhat sure that should do the trick, and probably not cause side
effects.  :)

3) do what i haven't and try out Jarkko's patch for VELOCITY-797.  it
should (if he did it as i expect) store inline macros with the
template and thus tie their lifecycle to the template instead of the
VelocimacroFactory.

 On Tue, Jul 31, 2012 at 1:39 PM, Alex Fedotov a...@kayak.com wrote:

 It's not really a Velocity specific suggestion - I would just dump the
 heap and trace the instances to the garbage collection roots. Eclipse MAT or
 YourKit can do it as probably can a lot of other Java tools.


 On Tue, Jul 31, 2012 at 11:37 AM, Bradley Wagner
 bradley.wag...@hannonhill.com wrote:

 Whoops, was misreading the API. It's actually that tempTemplateName
 variable.

 On Tue, Jul 31, 2012 at 11:21 AM, Bradley Wagner 
 bradley.wag...@hannonhill.com wrote:

  A StringWriter:
 
  String template = ... the string containing the dynamic template to
  generate ...
  // Get a template as stream.
  StringWriter writer = new StringWriter();
  StringReader reader = new StringReader(template);
  // create a temporary template name
  String tempTemplateName = velocityTransform- +
  System.currentTimeMillis();
 
  // ask Velocity to evaluate it.
  VelocityEngine engine = getEngine();
  boolean success = engine.evaluate(context, writer, tempTemplateName,
  reader);
 
  if (!success)
  {
  LOG.debug(Velocity could not evaluate template with content: \n +
  template);
  return null;
  }
  LOG.debug(Velocity successfully evaluted template with content: \n +
  template);
  String strResult = writer.getBuffer().toString();
  return strResult;
 
  On Tue, Jul 31, 2012 at 11:10 AM, Nathan Bubna nbu...@gmail.com
  wrote:
 
  What do you use for logTag (template name) when you are using
  evaluate()?
 
  On Tue, Jul 31, 2012 at 8:01 AM, Bradley Wagner
  bradley.wag...@hannonhill.com wrote:
   Doing both. In the other case we're using a classpath resource
   loader to
   evaluate templates like this:
  
   VelocityContext = ... a context that we're building each time ...
   VelocityEngine engine = ... our single engine ...
   Template template = engine.getTemplate(templatePath);
   StringWriter writer = new StringWriter();
   template.merge(context, writer);
  
   However, we only have 7 of those static templates in our whole
   system.
  
   On Tue, Jul 31, 2012 at 10:52 AM, Nathan Bubna nbu...@gmail.com
  wrote:
  
   And you're sure you're only using VelocityEngine.evaluate?  Not
   loading templates through the resource loader?  Or are you doing
   both?
  
   On Mon, Jul 30, 2012 at 2:51 PM, Bradley Wagner
   bradley.wag...@hannonhill.com wrote:
Nathan,
   
Tokens are referenced by
org.apache.velocity.runtime.parser.node.ASTReference which seem
to be
referenced by arrays of
  org.apache.velocity.runtime.parser.node.Nodes.
Most
of the classes referencing these things are AST classes in the
org.apache.velocity.runtime.parser.node package.
   
Here's our properties file:
   
runtime.log.logsystem.class =
   
   
 
  org.apache.velocity.runtime.log.Log4JLogChute,org.apache.velocity.runtime.log.AvalonLogSystem
   
   
 
  runtime.log.logsystem.log4j.logger=com.hannonhill.cascade.velocity.VelocityEngine
   
runtime.log.error.stacktrace = false
runtime.log.warn.stacktrace = false
runtime.log.info.stacktrace = false
runtime.log.invalid.reference = true
   
input.encoding=UTF-8
output.encoding=UTF-8
   
directive.foreach.counter.name = velocityCount
directive.foreach.counter.initial.value = 1
   
resource.loader = class
   
class.resource.loader.description = Velocity Classpath Resource
  Loader
class.resource.loader.class =
   
org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader

Re: Macro caching and other caching

[Nathan Bubna]

On Mon, Jul 30, 2012 at 1:30 PM, Bradley Wagner
bradley.wag...@hannonhill.com wrote:
 Thanks for the input.

 What we're seeing is that Velocity seems to be holding on to a lot
 of org.apache.velocity.runtime.parser.Token objects (around 5 million). We
 allow people to write arbitrary Velocity templates in our system and are
 evaluating them with:

 VelocityEngine.evaluate(Context context, Writer writer, String logTag,
 Reader reader)

 I was under the impression that Templates evaluated this way are inherently
 not cacheable. Is that the case? If that's not true, is there a way to
 control the cache Velocity is using for these?

me too.  just out of curiosity, what properties are you using for
configuration?  and can you tell any more about what class is holding
onto those Tokens?

 On Thu, Jul 19, 2012 at 10:26 AM, Alex Fedotov a...@kayak.com wrote:

 I think that Velocity has one global hash table for macros from the *.vm
 libraries and that is more or less static for the life time of the Velocity
 engine.

 I wish there there was a mechanism to control the list of the *.vm files
 and their order of lookup for each individual merge (thread). This would
 facilitate macro overloads based on the context.
 Unfortunately this feature is not available.

 I think the 1.7 behavior is (more or less):

 When template reference is found (i.e. #parse(x)) it is looked-up in the
 resource cache and if found there (with all the expiration checks, etc.)
 the parsed AST tree is used.
 If not found the template is loaded from the file, actually parsed and put
 into the cache. During the actual parsing process the macros that are
 defined in the template are put into the macro manager cache which is
 organized as:
 defining template name (name space) = macro name = AST macro code
 The AST is then rendered in the current context running #parse.

 When the time comes to call a macro there is a lookup process which can be
 influenced by some props, but the most general case is:

 1. Lookup in the global *.vm files, if found use that.
 2. Lookup in the same name space that calls the macro, if found use that.
 3. Going back through the list of the #parse-d templates lookup in each
 name space on the stack.

 The stack can be actually very long too, for example

 #foreach($templ in [1..5])
   #parse(${templ}.vtl)
 #end

 #mymacro()

 The lookup list here would contain:

 1.vtl, 2.vtl, 3.vtl, 4.vtl, 5.vtl

 This is true even for cases where the name is the same:

 #foreach($item in [1..5])
   #parse('item.vtl')
 #end

 The lookup list here would contain:

 item.vtl, item.vtl, item.vtl, item.vtl, item.vtl

 There is no attempt to optimize the lookup list and collapse the
 duplicates.

 Unfortunately 1.7 also had some nasty concurrency bugs there that had to do
 with clearing the name space of all the macros and repopulating it again on
 each parse which did not work at all with multiple threads.
 One thread could clear the name space while another was doing a lookup,
 etc.

 I think there was an effort to redesign that part in 2.0, but I have not
 looked at that yet.

 Alex

 On Wed, Jul 18, 2012 at 5:42 PM, Bradley Wagner 
 bradley.wag...@hannonhill.com wrote:

  Hi,
 
  We recently made some changes to our software to use just a single
  VelocityEngine as per recommendations on this group.
 
  We ran into an issue where macros were all of the sudden being shared
  across template renders because we had not
  specified: velocimacro.permissions.allow.inline.local.scope = true.
  However, we also had not ever turned on caching in our props file
  with: class.resource.loader.cache = true.
 
  Does this mean that macros are cached separately from whatever is being
  cached in the class.resource.loader.cache cache? Is there any way to
  control that caching or is just using this property the
  way: velocimacro.permissions.allow.inline.local.scope = true
 
  One side effect of our recent changes is that the app seems to have an
  increased mem footprint. We're not *sure* it can be attributed to
 velocity
  but I was trying to see what kinds of things Velocity could be hanging on
  to and how much memory they might be taking up.
 
  Thanks!
 


-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: Odd observation during debugging

[Nathan Bubna]

On Mon, Jul 16, 2012 at 9:04 AM, Christopher Schultz
ch...@christopherschultz.net wrote:
 Nathan,

 On 7/11/12 1:35 PM, Nathan Bubna wrote:
 On Wed, Jul 11, 2012 at 9:58 AM, Christopher Schultz
 ch...@christopherschultz.net wrote:
 Nathan,
 ...
 See VELOCITY-731 and VELOCITY-692 and others...

 Those were good to read: 1.6 introduced more consistent (if slower)
 treatment of references and then a setting was added to get the old
 behavior.

 Any idea if a future version of Velocity (maybe 2.x) will have the
 default value of that directive set to false so that toString will
 only be called for users who actually want that?

 While backward-compatibility is certainly a reasonable goal, this
 behavior kind of sucks... and I can't really think of too many cases
 where it makes sense. Good that there is a setting for it ;)

 Actually, i still consider it correct for a template language (which
 is not the same as a scripting language) to treat render-as-empty as
 false in an #if.  So, my hope for 2.0 was to not to remove that
 behavior, but to pre-empt it.

 On a somewhat related issue, we had been considering using strict
 reference mode except that -- at least using the current if-directive
 semantics, it's not practical to do things like this:

 #if($mymap  $mymap.containsKey('somekey') 
 !$mymap.get('somekey').isEmpty()  ...)

 ...because many of those individual parts of the predicate may end up
 returning something that is neither Boolean nor a Map, etc. and you
 *must* test them for non-null-ness before trying to use them, otherwise
 you risk an exception.

 Without disabling the 'toString' behavior in the configuration, there
 will be no way for these types of checks to execute without spewing lots
 of (in my case) useless String objects (not to mention the wasted time
 to generate them in the first place).

 I've seen the use of things like this on occasion:

 #if($myobject == $null)

 My understanding was that a null reference would never be considered
 equal to *anything*, even another null reference. Does the above
 actually work? And the $null is just a reference that is assumed to be
 null, right? When in strict-reference-mode, would that work since $null
 has (presumably) never been defined?

Yes, it works.  And yes, $null is a reference assumed to be null.  And
i believe strict mode is concerned about key existence, so just do:

context.put(null, null);

And you should be able to use that.

-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: partial evaluation / removing directives

[Nathan Bubna]

On Thu, Jul 12, 2012 at 2:27 PM, Pete pete.devn...@gmail.com wrote:
 Hi all,
 I'm working with some velocity files where I want to partially evaluate
 them, such that the only things actually evaluated are #parse (includes of
 other velocity templates in the same directory) and  $references to a
 resourceBundle variable passed in the context map.  In essence, all this is
 doing is combining a number of velocity files into one master velocity
 file, and localizing any resource bundle references to a given locale. All
 the main velocity directives in the velocity file(s) should be left
 unevaluated-   #set, #ifelse, #foreach etc. This way, the result could be
 redistributed and modified specific to a particular locale, with just one
 file instead of n based on the #parse structure.

interesting challenge!  glad i don't have to do it though. :)

 Up till now, I've been doing this in a somewhat roundabout way:
 1. setting strict escape property to true
 2. pre-processing the velocity templates by regexp replacing all instances
 of #if / #else/ #elseif/ #end / #foreach / #define / #break / #stop  #set /
 #evaluate with  \\#{$1}
 This adds a an escape character before each of these directives, and I can
 then call mergeTemplate on the result.  It works OK, sometimes, but I still
 run into some parsing issues now and again (eg not a robust solution). It
 also seems kind of heavy handed to have to preprocess these files using a
 regular expression and saving them before velocity gets a handle on them.
 It would even be a bit better if I could do this by reading them in and
 doing the rgexp in-memory rather than on the saved files, then using
 evaluate instead of mergeTemplate. But I assume that would cause problems
 for the #parse directives.

Why would evaluate cause problems for #parse??  If the engine is
configured the same, the #parse should work the same whether you enter
via file or string.

 I know velocity added a removeDirective() method in 1.6.2 which seems like
 it should be perfect for me - I could simply rip out all the directives but
 #parse.  However, I tried the and it seems that it only works for certain
 directives, eg  #foreach, #include, etc.  More basic directives like #if
 and #elseif are not in the list of runtimedirectives, or even represented
 as Directive objects, so removing them doesn't work.

Yeah, they are deep in the parser.  Their structure doesn't work as a
normal directive.

 Any suggestions on the best way to proceed with this? Would it be easy to
 change a few velocity files locally, recompile and get this behavior? Or is
 it sufficiently complex removing all these more basic directives that I'm
 better off continuing to try some kind of  preprocessing/ escaping?

You would have to redesign Velocity's parsing deeply.  A major
overhaul.  You're best off preprocessing.   Have you considered using
a different template engine to do the first part (the parse and
resourceBundle resolution)?  Might be overkill, but might be easier,
so long as the syntax has no overlap with VTL.

 thanks,
 Pete

-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: partial evaluation / removing directives

[Nathan Bubna]

On Fri, Jul 13, 2012 at 8:12 AM, Pete pete.devn...@gmail.com wrote:
 Thanks for the info guys. To answer that one question
 Why would evaluate cause problems for #parse??  If the engine is
 configured the same, the #parse should work the same whether you enter
 via file or string.
 The problem would be even if the #parse directives get picked up OK in my
 in-memory, preprocessed string version of the file (since I set template
 location path), Velocity would just go and consume those additional
 template files on its own, not giving me a chance to preprocess them first.
  Maybe I could avoid this if there was way to extend /replacevelocity's
 template file loader, I haven't looked at the code enough to know if this
 is possible

oh yeah, duh.  and yes, you can definitely make your own resource
loaders.  those are pluggable. :)

 That's an interesting suggestion re: the other templating Engine... I
 considered trying to home-brew my own (just looking for those two
 directives), but it seemed like a waste since there's already such powerful
 and robust ones out there. Also, there'sa bit of subtley there since it can
 be recursive ($resourceBundles can themselves include references to #parse,
 which can include references to resource bundles, etc).  If there was a
 really simple, customizable template engine one that would let me choose
 exactly what was parsed, that would probably be best.

Hmm.  i'm not aware of one, but i'm much less active in this space
than i used to be.

 My only issue using
 another one similar in size to velocity is that there might be some side
 effects, eg statements which are ignored by velocity but which get
 interpreted somehow through this other engine due to its own particular
 syntax.

yeah, that's a concern.

 As for the AST rewrite idea, if it was possible to Burn down nodes to
 their corresponding text something like that would work, However, wouldnt'
 that then possibly miss additional child elements in that AST tree? For
 instance a clause in an if statement which had a resourceBundle reference?
  I'm not too familiar with ASTs (been years since I dealt with those at
 school), maybe I can look at it a bit more today.

worth a look.  it sounded like a reasonable approach to me.
definitely easier than trying to remove baked-in directives.


 thanks,
 Pete

 On Fri, Jul 13, 2012 at 9:57 AM, Alex Fedotov a...@kayak.com wrote:

 Another option may be rewriting the AST tree after the template is parsed
 and replacing some nodes with text or something else.
 I tried that on the side as an experiment to inject some security checks
 and collect profiling info for macros and templates.

 Alex



 On Fri, Jul 13, 2012 at 9:50 AM, Nathan Bubna nbu...@gmail.com wrote:

  On Thu, Jul 12, 2012 at 2:27 PM, Pete pete.devn...@gmail.com wrote:
   Hi all,
   I'm working with some velocity files where I want to partially evaluate
   them, such that the only things actually evaluated are #parse (includes
  of
   other velocity templates in the same directory) and  $references to a
   resourceBundle variable passed in the context map.  In essence, all
 this
  is
   doing is combining a number of velocity files into one master velocity
   file, and localizing any resource bundle references to a given locale.
  All
   the main velocity directives in the velocity file(s) should be left
   unevaluated-   #set, #ifelse, #foreach etc. This way, the result could
 be
   redistributed and modified specific to a particular locale, with just
 one
   file instead of n based on the #parse structure.
 
  interesting challenge!  glad i don't have to do it though. :)
 
   Up till now, I've been doing this in a somewhat roundabout way:
   1. setting strict escape property to true
   2. pre-processing the velocity templates by regexp replacing all
  instances
   of #if / #else/ #elseif/ #end / #foreach / #define / #break / #stop
   #set /
   #evaluate with  \\#{$1}
   This adds a an escape character before each of these directives, and I
  can
   then call mergeTemplate on the result.  It works OK, sometimes, but I
  still
   run into some parsing issues now and again (eg not a robust solution).
 It
   also seems kind of heavy handed to have to preprocess these files
 using a
   regular expression and saving them before velocity gets a handle on
 them.
   It would even be a bit better if I could do this by reading them in and
   doing the rgexp in-memory rather than on the saved files, then using
   evaluate instead of mergeTemplate. But I assume that would cause
 problems
   for the #parse directives.
 
  Why would evaluate cause problems for #parse??  If the engine is
  configured the same, the #parse should work the same whether you enter
  via file or string.
 
   I know velocity added a removeDirective() method in 1.6.2 which seems
  like
   it should be perfect for me - I could simply rip out all the directives
  but
   #parse.  However, I tried the and it seems that it only works for
 certain

Re: partial evaluation / removing directives

[Nathan Bubna]

On Fri, Jul 13, 2012 at 9:02 AM, Alex Fedotov a...@kayak.com wrote:
 Well, I did not get into the details, but the idea would be to replace the
 ASTIfStatement with a sequence of AST nodes that would output the #IF
 text followed by the result of rewriting the children, etc. followed by the
 #END text.
 I think the SimpleNode does not have a particularly friendly public
 interface to facilitate this kind of thing. I remember I had to resort to
 using reflection and accessing protected/private members directly.

sounds like something that could be improved.  you could always open a
JIRA issue for this and/or provide a patch. :)

 Alex


 As for the AST rewrite idea, if it was possible to Burn down nodes to
 their corresponding text something like that would work, However, wouldnt'
 that then possibly miss additional child elements in that AST tree? For
 instance a clause in an if statement which had a resourceBundle reference?
  I'm not too familiar with ASTs (been years since I dealt with those at
 school), maybe I can look at it a bit more today.

 thanks,
 Pete



-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: Odd observation during debugging

[Nathan Bubna]

Just set:
directive.if.tostring.nullcheck = false

See VELOCITY-731 and VELOCITY-692 and others...

On Wed, Jul 11, 2012 at 9:13 AM, Christopher Schultz
ch...@christopherschultz.net wrote:
 All,

 I recently started getting intermittent OOMEs in my webapp that seem to
 be completely recoverable. The stack traces look like this:

 java.lang.OutOfMemoryError: Java heap space
 at java.util.Arrays.copyOf(Arrays.java:2882)
 at
 java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100)
 at
 java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:390
 )
 at java.lang.StringBuilder.append(StringBuilder.java:119)
 at java.lang.StringBuilder.append(StringBuilder.java:115)
 at
 java.util.AbstractCollection.toString(AbstractCollection.java:422)
 at
 org.apache.velocity.runtime.parser.node.ASTReference.evaluate(ASTReference.java:547)
 [...]

 This happens so rarely, it's hard to catch, and it's fairly obvious what
 is happening: toString is being called on a really huge List. We try not
 to use really huge lists, but I suppose there is some potential danger
 in rare instances. I want to find those instances.

 Velocity 1.7, Tools 2.0 (plus some committed bugfixes that haven't made
 it into an official release, yet).

 So I thought I'd add some trickery to my VelocityContexts: We use our
 own subclasss of VelocityLayoutServlet for a number of things, and I
 have overridden the createContext() to wrap the Context the
 super.createContext() returns in a ChainedContext (btw, that's
 deprecated but doesn't document a replacement -- what should I use?). My
 wrapper wraps all List and Set objects in yet another set of wrappers
 which essentially pass-through everything except that their toString
 methods throw an exception: there should be no reason that a List or Set
 should have toString() called on it, because they should only be
 iterated over, for instance.

 But right on my login page, I see this exception after such instrumentation:

 SEVERE: Servlet.service() for servlet velocity threw exception
 org.apache.velocity.exception.VelocityException: Reference evaluation
 threw an exception at /layout/header.vm[line 18, column 5]
 at
 org.apache.velocity.runtime.parser.node.ASTReference.evaluate(ASTRefe
 rence.java:551)
 at
 org.apache.velocity.runtime.parser.node.ASTExpression.evaluate(ASTExp
 ression.java:62)
 at
 org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfSt
 atement.java:85)
 at
 org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.
 java:342)
 at
 org.apache.velocity.runtime.directive.Parse.render(Parse.java:260)
 at
 org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirect
 ive.java:207)
 at
 org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.
 java:342)
 at org.apache.velocity.Template.merge(Template.java:356)
 []
 Caused by: java.lang.IllegalStateException: Request /myapp/login.vm,
 called toString on key 'extraStylesheets'
 at
 com.chadis.web.servlet.VelocityLayoutServlet$WrappedList.toString(VelocityLayoutServlet.java:220)
 at
 org.apache.velocity.runtime.parser.node.ASTReference.evaluate(ASTReference.java:547)

 If I look at everything that references the key 'extraStylesheets' in my
 login page (and the header, etc.), I get only these:

 login.vm only includes these references:
 #set($extraStylesheets = ['/includes/css/login.css'])

 I'm using VelocityLayoutServlet which is using my layouts/Default.vm (no
 references to 'extraStylesheets') which includes (via #parse)
 'header.vm' which has this to say:

 #if($extraStylesheets)
 #foreach($stylesheet in $extraStylesheets)
 link type=text/css href=$link.setRelative($stylesheet)
 rel=stylesheet /
 #end
 #end

 ...and that's it. Given the upper stack trace it seems that the #if() is
 evaluating the argument by converting it into a String for evaluation.
 Is that intentional? I always used #if($foo) to check to see if $foo
 had a value of any kind -- that is, if it was non-null (and non-false)
 but it appears that the value is being converted into a String for ...
 what purpose?

 I know a lot of changes have occurred over the years and that
 String-conversion is something that has seen some of that action. Is
 there a better way of determining if a List (or whatever) has a value?
 That is, without converting it to a String, first?

 One can argue that I shouldn't have Lists of objects so large that
 converting them to a String will cause an OOME, but the calling of
 toString on these Lists is certainly surprising.

 Thanks,
 -chris


-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: Odd observation during debugging

[Nathan Bubna]

On Wed, Jul 11, 2012 at 9:58 AM, Christopher Schultz
ch...@christopherschultz.net wrote:
 Nathan,
...
 See VELOCITY-731 and VELOCITY-692 and others...

 Those were good to read: 1.6 introduced more consistent (if slower)
 treatment of references and then a setting was added to get the old
 behavior.

 Any idea if a future version of Velocity (maybe 2.x) will have the
 default value of that directive set to false so that toString will
 only be called for users who actually want that?

 While backward-compatibility is certainly a reasonable goal, this
 behavior kind of sucks... and I can't really think of too many cases
 where it makes sense. Good that there is a setting for it ;)

Actually, i still consider it correct for a template language (which
is not the same as a scripting language) to treat render-as-empty as
false in an #if.  So, my hope for 2.0 was to not to remove that
behavior, but to pre-empt it.  On your large lists, it would never get
around to checking toString(), since it would find isEmpty() and use
that.  IMHO, the lookup order ought to be something like this:

#if( $obj ) will be false if:

$obj is null
$obj is boolean false
$obj returns false from getAsBoolean()
$obj is empty string (CharSequence w/length 0)
$obj returns true from isEmpty()
$obj is array of length 0
$obj returns null from getAsString()
$obj returns empty string from getAsString()
$obj returns null from getAsNumber()
$obj returns empty string from toString()

So the config switch would stay, but in far more cases, it would be
unnecessary.  The vast majority of slow toString() impls are
collections or maps.  Other custom objects (see Apache Click) would
easily be able to avoid toString() by having an isEmpty() or
getAsBoolean() method.

-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: Odd observation during debugging

[Nathan Bubna]

On Wed, Jul 11, 2012 at 11:05 AM, Christopher Schultz
ch...@christopherschultz.net wrote:
 Nathan,

 On 7/11/12 1:35 PM, Nathan Bubna wrote:
 Actually, i still consider [the toString behavior] correct for a template 
 language (which
 is not the same as a scripting language) to treat render-as-empty as
 false in an #if.  So, my hope for 2.0 was to not to remove that
 behavior, but to pre-empt it.  On your large lists, it would never get
 around to checking toString(), since it would find isEmpty() and use
 that.  IMHO, the lookup order ought to be something like this:

 #if( $obj ) will be false if:

 $obj is null
 $obj is boolean false
 $obj returns false from getAsBoolean()
 $obj is empty string (CharSequence w/length 0)
 $obj returns true from isEmpty()
 $obj is array of length 0
 $obj returns null from getAsString()
 $obj returns empty string from getAsString()
 $obj returns null from getAsNumber()
 $obj returns empty string from toString()

 If the ordering of the checking is really done that way, then my huge
 lists (which shouldn't exist in the first place, really -- I know that
 part's my fault) would fall-through at case #5 (isEmpty)? It's not
 entirely clear to me what happens in this (List) case.

yes. no object that implements isEmpty() (which would include all
Collections and Maps) would continue checking beyond that step.

 So the config switch would stay, but in far more cases, it would be
 unnecessary.  The vast majority of slow toString() impls are
 collections or maps.  Other custom objects (see Apache Click) would
 easily be able to avoid toString() by having an isEmpty() or
 getAsBoolean() method.

 And these would be introspected so they don't have to implement some
 kind of interface, right?

definitely.  VTL has pushed toward duck-typing for years now and
should continue to do so, IMNSHO.

 After banging my head against my own code trying to figure out why my
 non-template-defined Lists weren't being wrapped, I realized that the
 contents of the Request/Session/Application attributes are *not* copied
 into the Context... they are fetched when requested. That means my code
 needs to get a bit more complicated if I want to wrap collections that
 are fetched from the request attributes ;)

true.

 This code is really crappy... but do you think it would be useful for
 anyone? I'd be happy to post it somewhere.

i have no idea.

 Thanks,
 -chris


-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: double evaluation

[Nathan Bubna]

Put the context in the context:

context.put(context, context);

Then do:

$context.get($id).content

On Fri, Jul 6, 2012 at 4:49 AM,  kieran...@gmx.net wrote:
 Hello Velocity Users,

 in our VelocityContext, there is a list called sourceIds, which lists the 
 available ids. In addition, there are HashMaps in the VelocityContext 
 registered under the available ids. Maps are as many as ids, of course.

 So, for example we have: sourceIds = [src1, scr2] and therefore two maps src1 
 and src2 in the context.

 How can we refer to the map object?

 Using #foreach ( $id in $sourceIds ), first of all the String src1 is the 
 value of id ($id). But how can wie refer to the object stored under src1 in 
 the VelocityContext?

 $($id).getContent() did not work (it was (src).getContent()).

 Kind regards,
 Kieran

 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org


-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: Inconsistent and strange NPE when initializing Velocity

[Nathan Bubna]

What are the macro settings in your velocity.properties?

On Mon, Jun 25, 2012 at 7:40 PM, Bradley Wagner
bradley.wag...@hannonhill.com wrote:
 We're noticing something now that may or may not be related to our change
 to only use a single instance of the Velocity Engine.

 Macros that we define in one template seem to be sticking around and being
 used when we go to merge or evaluate a different template.

 Is this possible related and to be expected when using a single instance of
 the VelocityEngine?

 On Thu, Jun 7, 2012 at 5:28 PM, Bradley Wagner 
 bradley.wag...@hannonhill.com wrote:

 Thanks Will. We'll make sure to just initialize it once.


 On Thu, Jun 7, 2012 at 3:36 PM, Will Glass-Husain 
 wglasshus...@gmail.comwrote:

 Hi,

 You should use either the Velocity static calls or the VelocityEngine but
 not both-- it's confusing.  They don't technically interfere with each
 other, but it'll be simpler and less error prone not to mix.

 It's also a performance hit to continually reinitialize Velocity.  There's
 no need to do this every time you process a page.  Besides the cost of
 initialization, it also prevents you from doing any caching.

 Here's the general pattern
 * On app start up, initialize a VelocityEngine.  Store it somewhere.
 * Every time you need to process a template
     -- get the template
     -- create and populate a context
     -- using the velocity engine, merge the template (with the context)

 WILL


 On Thu, Jun 7, 2012 at 8:26 AM, Bradley Wagner 
 bradley.wag...@hannonhill.com wrote:

  Thanks Will.
 
  So looking over the developer documentation about initialization and our
  code, it looks like we're using a mix of the Singleton Velocity Engine
 and
  Separate Instances in certain cases. However, in all these cases, we're
  using the same set of properties. The documentation suggests that the
  Separate Instance method is the newer way to do it, but you're saying
 that
  if we can get away with initializing Velocity one using Velocity.init()
 we
  should do that for better performance, yes? Are both mechanisms for
  evaluating templates thread-safe?
 
  In one place we're doing:
 
  VelocityContext context = new VelocityContext(contextMap)
  Properties props = VelocityProperties.getProperties();
  Velocity.init(props);
  String templatePath = VelocityTemplates.getTemplatePath(templateName);
  Template template = Velocity.getTemplate(templatePath);
  StringWriter writer = new StringWriter();
  template.merge(context, writer);
  return writer.toString();
 
  and in another we're doing:
 
  VelocityEngine engine = new VelocityEngine();
  Properties velocityProps = VelocityProperties.getProperties();
  engine.init(velocityProps);
 
  // Get a template as stream.
  StringWriter writer = new StringWriter();
  StringReader reader = new StringReader(template);
  // create a temporary template name
  String tempTemplateName = velocityTransform- +
  System.currentTimeMillis();
 
  // ask Velocity to evaluate it.
  boolean result = engine.evaluate(context, writer, tempTemplateName,
  reader);
 
  String strResult = null;
  if (result)
  {
     strResult = writer.getBuffer().toString();
  }
  return strResult;
 
  Thanks a bunch for your help!
 
  On Wed, Jun 6, 2012 at 6:34 PM, Will Glass-Husain 
 wglasshus...@gmail.com
  wrote:
  
   You only need to initialize Velocity once.  Performance is much better
  that
   way.
  
   WILL
  
   On Wed, Jun 6, 2012 at 2:37 PM, Bradley Wagner 
   bradley.wag...@hannonhill.com wrote:
  
The odd part about that is that while I could see this being a race
condition... once Velocity gets into this state it doesn't matter
 how
  many
times we call Velocity.init, it returns the NPE every time. I guess
 I
should have mentioned that in the original post. Basically once it
  starts
returning NPE our only recourse is to restart Tomcat, which fixes
 the
problem, until  it pops up again.
   
On Wed, Jun 6, 2012 at 5:35 PM, Bradley Wagner 
bradley.wag...@hannonhill.com wrote:
   
 Ha, that's a good question. Yes, we're initializing Velocity LOTS
 of
 times. Basically every time we use it to create these messages in
 our
 message util. I'm guessing that's not recommended?


 On Wed, Jun 6, 2012 at 1:53 PM, Will Glass-Husain 
wglasshus...@gmail.comwrote:

 Hi Bradley,

 Are you initializing Velocity multiple times?

 Though I haven't heard of this issue before, it sounds like a
 race
 condition, perhaps if the initialization is called twice at the
 same
time.

 WILL

 On Wed, Jun 6, 2012 at 8:37 AM, Bradley Wagner 
 bradley.wag...@hannonhill.com wrote:

  Hi,
 
  I sent this message before I had subscribed to the list so I
  wasn't
 sure if
  the original made it. My apologies if this is a duplicate.
 
  One of our clients running our software is *occasionally*
 running
  into
 the
  stack trace at the 

Re: Inconsistent and strange NPE when initializing Velocity

[Nathan Bubna]

A VelocityEngine allows for global macros and template caching, both
configurable, of course.  Context data is never cached or shared by
the engine, though you can yourself reuse a context across multiple
merges.

On Wed, Jun 27, 2012 at 1:03 PM, Bradley Wagner
bradley.wag...@hannonhill.com wrote:
 Thanks, Nathan, I'll give that a shot.

 Offhand, is there anything else I need to be aware of that could be
 persisting across template renders (like velocimacros) since I'm now using
 a single instance of engine?

 On Wed, Jun 27, 2012 at 3:51 PM, Nathan Bubna nbu...@gmail.com wrote:

 On Wed, Jun 27, 2012 at 11:04 AM, Bradley Wagner
 bradley.wag...@hannonhill.com wrote:
  None explicitly specified.
 
  I looked at a default velocity properties that's in our project but that
  we're not using:
 
  velocimacro.library = VM_global_library.vm
  velocimacro.permissions.allow.inline = true
  velocimacro.permissions.allow.inline.to.replace.global = false
  velocimacro.permissions.allow.inline.local.scope = false
  velocimacro.context.localscope = false
 
  I'm guessing this has something to do with these things being scoped
  globally by default or something?

 yeah, you should set

 velocimacro.permissions.allow.inline.local.scope = true

  On Wed, Jun 27, 2012 at 12:39 PM, Nathan Bubna nbu...@gmail.com wrote:
 
  What are the macro settings in your velocity.properties?
 
  On Mon, Jun 25, 2012 at 7:40 PM, Bradley Wagner
  bradley.wag...@hannonhill.com wrote:
   We're noticing something now that may or may not be related to our
 change
   to only use a single instance of the Velocity Engine.
  
   Macros that we define in one template seem to be sticking around and
  being
   used when we go to merge or evaluate a different template.
  
   Is this possible related and to be expected when using a single
 instance
  of
   the VelocityEngine?
  
   On Thu, Jun 7, 2012 at 5:28 PM, Bradley Wagner 
   bradley.wag...@hannonhill.com wrote:
  
   Thanks Will. We'll make sure to just initialize it once.
  
  
   On Thu, Jun 7, 2012 at 3:36 PM, Will Glass-Husain 
  wglasshus...@gmail.comwrote:
  
   Hi,
  
   You should use either the Velocity static calls or the
 VelocityEngine
  but
   not both-- it's confusing.  They don't technically interfere with
 each
   other, but it'll be simpler and less error prone not to mix.
  
   It's also a performance hit to continually reinitialize Velocity.
   There's
   no need to do this every time you process a page.  Besides the cost
 of
   initialization, it also prevents you from doing any caching.
  
   Here's the general pattern
   * On app start up, initialize a VelocityEngine.  Store it somewhere.
   * Every time you need to process a template
       -- get the template
       -- create and populate a context
       -- using the velocity engine, merge the template (with the
  context)
  
   WILL
  
  
   On Thu, Jun 7, 2012 at 8:26 AM, Bradley Wagner 
   bradley.wag...@hannonhill.com wrote:
  
Thanks Will.
   
So looking over the developer documentation about initialization
 and
  our
code, it looks like we're using a mix of the Singleton Velocity
  Engine
   and
Separate Instances in certain cases. However, in all these cases,
  we're
using the same set of properties. The documentation suggests that
 the
Separate Instance method is the newer way to do it, but you're
 saying
   that
if we can get away with initializing Velocity one using
  Velocity.init()
   we
should do that for better performance, yes? Are both mechanisms
 for
evaluating templates thread-safe?
   
In one place we're doing:
   
VelocityContext context = new VelocityContext(contextMap)
Properties props = VelocityProperties.getProperties();
Velocity.init(props);
String templatePath =
  VelocityTemplates.getTemplatePath(templateName);
Template template = Velocity.getTemplate(templatePath);
StringWriter writer = new StringWriter();
template.merge(context, writer);
return writer.toString();
   
and in another we're doing:
   
VelocityEngine engine = new VelocityEngine();
Properties velocityProps = VelocityProperties.getProperties();
engine.init(velocityProps);
   
// Get a template as stream.
StringWriter writer = new StringWriter();
StringReader reader = new StringReader(template);
// create a temporary template name
String tempTemplateName = velocityTransform- +
System.currentTimeMillis();
   
// ask Velocity to evaluate it.
boolean result = engine.evaluate(context, writer,
 tempTemplateName,
reader);
   
String strResult = null;
if (result)
{
   strResult = writer.getBuffer().toString();
}
return strResult;
   
Thanks a bunch for your help!
   
On Wed, Jun 6, 2012 at 6:34 PM, Will Glass-Husain 
   wglasshus...@gmail.com
wrote:

 You only need to initialize Velocity once.  Performance is much
  better
that
 way.

 WILL

 On Wed

Re: Java method that generates html tags is escaping angle brackets...

[Nathan Bubna]

This is not a standard behavior.  Either your $reportTool class is
doing it or else you have the EscapeHtmlReference EventHandler
configured.

On Sat, Jun 16, 2012 at 11:11 PM, smadirondack smadirond...@gmail.com wrote:

 From a Velocity template I call a java method that generates html tags

  area shape=rect href=http://test.com/mylink; /

 But it encodes so the page ends up with the following

 lt;area shape=quot;rectquot; href=quot;http:.

 Here's part of the template:

 #set($myLinks=$reportTool.getImageMapLinks($report))
 $myLinks

 In the java method I just use StringBuilder with its append method and
 return the toString like the following:

 StringBuilder sb = new StringBuilder();
 sb.append(area shape=\rect\ href=\http://test.com/mylink\; /);
 return sb.toString();


 What can I do so that the generated html is not encoded?

 Thanks
 --
 View this message in context: 
 http://old.nabble.com/Java-method-that-generates-html-tags-is-escaping-angle-brackets...-tp34024803p34024803.html
 Sent from the Velocity - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org


-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: Problem with static classes and chained contexts

[Nathan Bubna]

Yeah, i'd call that a bug.  Would you mind filing it in JIRA?  As for
performance gains, i would operate under the assumption that the gains
are small.  Yes, you cut down on map puts and short-term memory churn,
but each reference insertion has an extra lookup step now.  Unless the
default context objects are significant in terms of init-time or
memory usage (which does not appear to be the case from your example,
i would expect the return to be negligible.

On Thu, Jun 7, 2012 at 7:53 AM, Steve O'Hara
soh...@pivotal-solutions.co.uk wrote:
 Hi All,

 Has anyone else noticed a problem with chained contexts and static classes?
 As a performance improvement, I decided to put all our static context objects 
 into a context that would be the basis of all new contexts e.g.

    private static Context chainedContext;
    static {
        chainedContext = Z_getDefaultVelocityContext();
    }

    private static Context Z_getDefaultVelocityContext() {
        Context context = new VelocityContext();
        context.put(TmpDir, Common.getTemporaryDirectory());
        context.put(math, new MathTool());
        context.put(number, new NumberTool());
        context.put(sort, new SortTool());
        context.put(LSQUARE_CHAR, '[');
        context.put(RSQUARE_CHAR, ']');
        context.put(LCURLY_CHAR, '{');
        context.put(RCURLY_CHAR, '}');
        context.put(DOT_CHAR, '.');
        context.put(NEWLINE, '\n');
        context.put(HASH, '#');
        context.put(DOLLAR, '$');
        context.put(DQUOTE, '');
        context.put(Utils, Common.class);
        return context;
    }

    public static Context getVelocityContext(boolean runtimeMode) {
        Context context = new VelocityContext(chainedContext);
        context.put(Context, context);
        return context;
    }

 The problem is that in this configuration, $Utils is not available in the 
 scripts.
 All the other instantiated objects are OK.  Works fine of course if the 
 static class is added to each outer context.

 I guess it's a bug but actually am I really going to gain much performance 
 with this technique anyway?

 Cheers
 Steve




 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org


-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: Is it possible to have velocity ignore certain characters?

[Nathan Bubna]

No, the parser is JavaCC-generated and not dynamically modifiable.  If
you are using a lot of syntax that is like VTL, but is not actually
VTL (like your example), either use literals to avoid the syntax
conflicts

http://velocity.apache.org/engine/releases/velocity-1.7/user-guide.html#stringliterals

or consider a different template engine that has a non-conflicting
syntax, like Freemarker or StringTemplate.  Any time you choose a
template engine, syntax conflicts should be one of your top concerns.

On Thu, Jun 7, 2012 at 11:21 PM, tdoughty
timothy.evan.doug...@gmail.com wrote:

 I'm just starting with Velocity at my internship, but I couldn't find the
 answer to this. Is it possible to have Velocity ignore certain characters?
 Velocity is giving an error when it encounters a '[' in the html file. I
 will post the exact error tomorrow when I have access to my work computer.
 The html file looks like:


 ...

 ...${variable[encoding=html]}...

 ...


 It gives the error upon reading the opening bracket for encoding=html.
 That's the only character that's giving me a problem. I have broken it up
 into:


 ...

 #set{$D = '$'}

 #set{$VARIABLE = '{variable[encoding=html]}'}

 ${D}${VARIABLE}

 ...


 This works fine, but there's about a hundred different locations that a
 variation of this code is listed in the files and I'm hoping there's an
 easier way to manage it. Can you just list certain characters to ignore in
 the template, or some variation of this? Thank you!
 --
 View this message in context: 
 http://old.nabble.com/Is-it-possible-to-have-velocity-ignore-certain-characters--tp33979774p33979774.html
 Sent from the Velocity - User mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: Added Velocity language parser to CodeMirror

[Nathan Bubna]

That looks great!

On Sat, May 19, 2012 at 12:11 AM, Steve O'Hara
soh...@pivotal-solutions.co.uk wrote:
 Just a note to say that I've contributed a language parser/colourizer mode 
 for Velocity to the rather excellent free js package CodeMirror 
 http://codemirror.net/
 Looks good but if you spot something I've missed, let me know

-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: Added Velocity language parser to CodeMirror

[Nathan Bubna]

Oh, one thing it does appear to be missing is body macros:

#@foo()
this is inner content for \#foo()
#end

On Sat, May 19, 2012 at 7:14 AM, Nathan Bubna nbu...@gmail.com wrote:
 That looks great!

 On Sat, May 19, 2012 at 12:11 AM, Steve O'Hara
 soh...@pivotal-solutions.co.uk wrote:
 Just a note to say that I've contributed a language parser/colourizer mode 
 for Velocity to the rather excellent free js package CodeMirror 
 http://codemirror.net/
 Looks good but if you spot something I've missed, let me know

-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: More 1.7 BC issues (porting from 1.5)

[Nathan Bubna]

Anything in the log?  #set($type = \\) is not valid syntax, i think.
 I'm not even sure what value you want $type to have.  Two double
quotes or an empty string?

On Thu, May 3, 2012 at 11:17 AM, Boris Partensky
boris.parten...@gmail.com wrote:
 Hi, I have this use case which involves 2 nested macros and a foreach.
 I am trying to understand why this template evaluates to empty string
 on 1.7, and to foobaryokdar - on 1.5.


 String template = #set($global_types=['foo', 'bar', 'yok',
 'dar'])#macro( showBox $input)#set($type = \\)$input#end+
                #macro(showBoxes $types)#foreach($type in
 $types)#showBox($type)#end#end#showBoxes($global_types);

 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org


-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: More 1.7 BC issues (porting from 1.5)

[Nathan Bubna]

Ah, it was Sergiu, not Byron.  Here's the relevant discussion:

https://issues.apache.org/jira/browse/VELOCITY-681

On Thu, May 3, 2012 at 12:16 PM, Nathan Bubna nbu...@gmail.com wrote:
 Ok, for my sanity, is this an accurate rewrite?

 #macro( inner $arg )
  #set($ref = '')$arg
 #end
 #macro( outer )
  #foreach( $ref in ['foo','bar','yok','dar'] )
    #inner( $ref )
  #end
 #end
 #outer()

 Do you get the same behavior in both with this?

 #macro( inner $arg )
  #set($ref = '')$arg
 #end
 #foreach( $ref in ['foo','bar','yok','dar'] )
  #inner( $ref )
 #end

 Or is it only when the macros are nested?
 Also, do you have localscope on for the macros?

 I know changes were made in the pass-by-name behavior between 1.5 and
 the trunk (2.0-SNAPSHOT), but my memory is failing as to the
 chronology of them.  What i do recall (possibly incorrectly), makes me
 think this should have been reversed; blank in the older version,
 instead of the newer.  I thought we stopped proxying #set calls on
 macro args, because while that was arguably a correct way to do
 pass-by-name, it was deemed surprising and not worth the
 implementation/performance costs.  I seem to recall arguing with
 someone about this, maybe Byron?  Well, i'm confused.   I also haven't
 the time to fire up Velocity environment right now on this machine to
 test it.  Perhaps someone else can step in.

 On Thu, May 3, 2012 at 11:51 AM, Boris Partensky
 boris.parten...@gmail.com wrote:
 Not seeing any errors in log. Corrected to 2 single quotes. Same
 behavior. I was hoping that $input in each iteration will not be empty
 string, but rather 'foo', 'bar' etc (that's the way 1.5 behaves). Why
 would setting a value of $type in parent (foreach) scope would affect
 the value of the local $input argument?

 String template = #set($global_types=['foo', 'bar', 'yok',
 'dar'])#macro( showBox $input)#set($type = '')$input#end+
                #macro(showBoxes $types)#foreach($type in
 $types)#showBox($type)#end#end#showBoxes($global_types);


 On Thu, May 3, 2012 at 2:33 PM, Nathan Bubna nbu...@gmail.com wrote:
 Anything in the log?  #set($type = \\) is not valid syntax, i think.
  I'm not even sure what value you want $type to have.  Two double
 quotes or an empty string?

 On Thu, May 3, 2012 at 11:17 AM, Boris Partensky
 boris.parten...@gmail.com wrote:
 Hi, I have this use case which involves 2 nested macros and a foreach.
 I am trying to understand why this template evaluates to empty string
 on 1.7, and to foobaryokdar - on 1.5.


 String template = #set($global_types=['foo', 'bar', 'yok',
 'dar'])#macro( showBox $input)#set($type = \\)$input#end+
                #macro(showBoxes $types)#foreach($type in
 $types)#showBox($type)#end#end#showBoxes($global_types);

 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org


 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org


 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org


-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: More 1.7 BC issues (porting from 1.5)

[Nathan Bubna]

I'm at a lost and out of time to look into this.  I'd consider opening
a JIRA issue so this doesn't get forgotten, or maybe someone else will
jump in on this...

On Thu, May 3, 2012 at 12:35 PM, Boris Partensky
boris.parten...@gmail.com wrote:
 Ok, for my sanity, is this an accurate rewrite?

 Yep.

 Do you get the same behavior in both with this?

 Not quite same. *With* nested macros  I get empty string in 1.7 and
 foobaryokdar in 1.5. *Without* nested macros I get empty string in 1.5
 and in 1.7. Below are the test cases for 1.5 and 1.7 that succeed.

 1.5

  public void testVelocityForEachNestedMacroInvokeMacroScope() throws Exception
    {
        VelocityEngine ve = new VelocityEngine();

        ve.init();

        String template = #set($global_types=['foo', 'bar', 'yok',
 'dar'])#macro( showBox $input)#set($type = '')$input#end+
                #macro(showBoxes $types)#foreach($type in
 $types)#showBox($type)#end#end#showBoxes($global_types);

        StringWriter eval = new StringWriter();
        boolean b = ve.evaluate(new VelocityContext(), eval, foo, template);
        assertEquals(eval.toString(), foobaryokdar, eval.toString());

    }

    public void testVelocityForEachNestedMacroInvokeMacroScopeNathan()
 throws Exception
    {
        VelocityEngine ve = new VelocityEngine();

        ve.init();

        String template = #macro( inner $arg )#set($ref =
 '')$arg#end#macro( outer )#foreach( $ref in ['foo','bar','yok','dar']
 )#inner( $ref )#end#end#outer();

        StringWriter eval = new StringWriter();
        boolean b = ve.evaluate(new VelocityContext(), eval, foo, template);
        assertEquals(eval.toString(), foobaryokdar, eval.toString());

    }


    public void testVelocityNoNestedMacroForEachInvokeMacroScope()
 throws Exception
    {
        VelocityEngine ve = new VelocityEngine();

        ve.init();

        String template = #macro( inner $arg )#set($ref =
 '')$arg#end#foreach( $ref in ['foo','bar','yok','dar'] )#inner( $ref
 )#end;

        StringWriter eval = new StringWriter();
        boolean b = ve.evaluate(new VelocityContext(), eval, foo, template);
        assertEquals(eval.toString(), , eval.toString());

    }



 1.7


  public void testVelocityForEachNestedMacroInvokeMacroScope()
    {
        String template = #set($global_types=['foo', 'bar', 'yok',
 'dar'])#macro( showBox $input)#set($type = '')$input#end+
                #macro(showBoxes $types)#foreach($type in
 $types)#showBox($type)#end#end#showBoxes($global_types);
        String eval = evaluate(template);
        assertEquals(eval, , eval);

    }


    public void testVelocityForEachNestedMacroInvokeMacroScopeNathan()
    {
        String template = #macro( inner $arg )#set($ref =
 '')$arg#end#macro( outer )#foreach( $ref in ['foo','bar','yok','dar']
 )#inner( $ref )#end#end#outer();

        String eval = evaluate(template);
        assertEquals(eval, , eval);

    }

    public void testVelocityNoNestedMacroForEachInvokeMacroScope()
    {
        String template = #macro( inner $arg )#set($ref =
 '')$arg#end#foreach( $ref in ['foo','bar','yok','dar'] )#inner( $ref
 )#end;

        String eval = evaluate(template);
        assertEquals(eval, , eval);

    }

 On Thu, May 3, 2012 at 3:16 PM, Nathan Bubna nbu...@gmail.com wrote:
 Ok, for my sanity, is this an accurate rewrite?

 #macro( inner $arg )
  #set($ref = '')$arg
 #end
 #macro( outer )
  #foreach( $ref in ['foo','bar','yok','dar'] )
    #inner( $ref )
  #end
 #end
 #outer()

 Do you get the same behavior in both with this?

 #macro( inner $arg )
  #set($ref = '')$arg
 #end
 #foreach( $ref in ['foo','bar','yok','dar'] )
  #inner( $ref )
 #end

 Or is it only when the macros are nested?
 Also, do you have localscope on for the macros?

 I know changes were made in the pass-by-name behavior between 1.5 and
 the trunk (2.0-SNAPSHOT), but my memory is failing as to the
 chronology of them.  What i do recall (possibly incorrectly), makes me
 think this should have been reversed; blank in the older version,
 instead of the newer.  I thought we stopped proxying #set calls on
 macro args, because while that was arguably a correct way to do
 pass-by-name, it was deemed surprising and not worth the
 implementation/performance costs.  I seem to recall arguing with
 someone about this, maybe Byron?  Well, i'm confused.   I also haven't
 the time to fire up Velocity environment right now on this machine to
 test it.  Perhaps someone else can step in.

 On Thu, May 3, 2012 at 11:51 AM, Boris Partensky
 boris.parten...@gmail.com wrote:
 Not seeing any errors in log. Corrected to 2 single quotes. Same
 behavior. I was hoping that $input in each iteration will not be empty
 string, but rather 'foo', 'bar' etc (that's the way 1.5 behaves). Why
 would setting a value of $type in parent (foreach) scope would affect
 the value of the local $input argument?

 String template = #set($global_types=['foo', 'bar', 'yok',
 'dar'])#macro( showBox $input)#set($type

Re: upgrading from 1.5 to 1.7 compatibility issues

[Nathan Bubna]

On Tue, May 1, 2012 at 7:59 AM, Boris Partensky
boris.parten...@gmail.com wrote:
 Yes, compatibility was and is a goal, but with limited resources,
 continuing support for implicit scoping in macros didn't make the cut.

 Ok. Are there any BC corner cases other than nested macros I should be
 aware of? I could not really find the No-BC notification you had
 mentioned.

Hmm.  I think the #evaluate directive also lost its implicit scope,
but i'd have to double check on that.

 * When scopes of the same type are nested make the parent Scope
 available through the child (e.g. $foreach.parent or
 $foreach.topmost).

 Thanks. So, with macro.provide.scope.control =true scoping behavior
 should stay the same, and I'd have to explicitly use scope handles to
 reach different scopes, like $mymacroname.parent for example, or
 $macro.parent. Is this correct?

Yep.  Explicit read/write is the name of the game.  And just to make
sure we're on the same page, $mymacroname scope control would only be
provided when using #macro( mymacroname ) as a macro with a body
(#@mymacroname() $mymacroname #end) and you set

mymacroname.provide.scope.control = true

and $mymacroname.parent would only exist if you are nesting calls to
#@mymacroname

:)


 Thanks
 Boris



 On Mon, Apr 30, 2012 at 5:08 PM, Nathan Bubna nbu...@gmail.com wrote:
 On Mon, Apr 30, 2012 at 1:06 PM, Boris Partensky
 boris.parten...@gmail.com wrote:
 I am seeing 3 bullet points there pertinent to this issue and all 3
 seem to indicate that being compatible was the intention there, or am
 I wrong ? The way I read #2 and #3 is that the parent scope should
 only be available if I explicitly specify the scope I want (parent or
 topmost or replaced).

 Yes, compatibility was and is a goal, but with limited resources,
 continuing support for implicit scoping in macros didn't make the cut.

 * For performance and compatibility these are all off by default,
 *except* for $foreach. The others may be enabled by setting a velocity
 property like:macro.provide.scope.control = true

 off for compatibility here means reduced chance of squashing
 someone's previous $macro or $template var, or more realistically $foo
 when there is a body macro call #foo

 * When scopes of the same type are nested make the parent Scope
 available through the child (e.g. $foreach.parent or
 $foreach.topmost).

 $scope.parent is always and only made available when there actually
 is an explicit parent scope provided. e.g.

 #foreach( $a in $b )
   #foreach( $c in $d )
     $foreach.parent here == $foreach.topmost
   #end
  $foreach here == $foreach.topmost
 #end

 Think parent and topmost as ways to navigate the scope stack, which
 only exists when scope.provide.scope.control = true

 * When a Scope reference overrides an existing reference that is not a
 Scope, make it available through the Scope (e.g. $foreach.replaced).

 $scope.replaced is not a parent scope, but is 'bar' in the example:
 #set($foo='bar') #@foo $foo.replaced #end

 This is a workaround for incompatibilities/migrations/etc.  It doesn't
 provide any compatibility with the older implicit system of scoping.

 On Mon, Apr 30, 2012 at 3:51 PM, Nathan Bubna nbu...@gmail.com wrote:
 http://velocity.apache.org/engine/devel/changes-report.html#a1.7

 On Mon, Apr 30, 2012 at 12:37 PM, Boris Partensky
 boris.parten...@gmail.com wrote:
 No problem, thanks for making things clear.

  we decided to forego it and notify users of the non-BC change when
 we released 1.7.

 which notification are you referring to? Wonder if there is something
 else in there I am not aware of.


 On Mon, Apr 30, 2012 at 2:34 PM, Nathan Bubna nbu...@gmail.com wrote:
 Congratulations, Boris.  You are the corner case we feared.  :-/  We
 knew when we went ahead with this that providing a migration path
 would be difficult.  We knew most users didn't have extreme numbers of
 macros and hoped that those who didn't frequently nest them, in part
 because of the complexities of heavy scoping in a language that often
 treated scoping as a second-class feature, and in part because of the
 performance issues macros had prior to 1.6.  #parse,
 VelocityLayoutServlet and even custom tools, which lack the implicit
 scoping support, tended to be more performant and encouraged for
 simplifying complicated tools.  Considering those things and the
 difficulty of implementing a BC switch for implicit scoping, we
 decided to forego it and notify users of the non-BC change when we
 released 1.7.

 Sorry.  It sounds like it's going to take some legwork to upgrade in
 the cases where you nested your macros.

 On Mon, Apr 30, 2012 at 11:16 AM, Boris Partensky
 boris.parten...@gmail.com wrote:
 Yep, I am afraid we do set globals from within macros...

 On Mon, Apr 30, 2012 at 2:05 PM, Nathan Bubna nbu...@gmail.com wrote:
 Can you set velocimacro.context.localscope = true or is it important
 for your system to be able to #set global stuff from within macros?

 On Mon, Apr 30, 2012 at 10

Re: upgrading from 1.5 to 1.7 compatibility issues

[Nathan Bubna]

Yeah, it was intended, and part of an overall move toward
fixing/simplifying Velocity's variable scoping, avoiding the
complexities and costs (performance, yes, but mostly time/brainpower
for users and devs alike) of more programming language type behavior.
Velocity has long aspired to be a straightfoward template engine and
avoid being a complete scripting language.  (Implicit) variable
scoping, as seen in 1.5, was seen as a necessary compromise toward the
latter; after all, one big fat namespace is always unmanageable,
right?  Well, there's ways to make that easy to manage. :)  Let's call
it optional, provided, explicit scoping, explicit because you don't
have to grok the contextual scope to understand a reference, optional
because you can ignore it, and provided because Velocity does the work
of choosing prefixes and creating/destroying the scopes (as any
implicit scoping system does).  So everything is becoming globally
scoped, but it is now trivial to turn on automatic, explicit scopes or
namespaces that you can use when you don't want things to live in the
global scope.

Here's an example...  Do you use $velocityCount to get an index of
sorts inside of #foreach directives?  Well, that's an example of mixed
implicit/explicit namespacing that gets messy when you nest
#foreach's, with no good way to get the parent's count and
unwieldiness when you want to add $velocityIndex, $velocityHasNext and
so on.  Now, we automatically manage a $foreach var that not only has
a 'count' property, but an 'index', 'hasNext', 'parent', and so on
(see 
http://velocity.apache.org/engine/devel/apidocs/org/apache/velocity/runtime/directive/ForeachScope.html).
 It also, of course, accepts any property you want to set on it (like
any map).  This makes templates instantly understandable, making
debugging much better.  You always know exactly what you are referring
to, and so does anyone else reading the template.

#foreach is the only 'content directive' that has its explicit scope
automatically turned on, but all content containing directives
(including custom body macros) can have their own explicit,
auto-managed scope, named after themselves.  for example, you can flip
the macro scope on:

macro.provide.scope.control = true

and do:

#macro( outer $arg )
  #set( $macro.arg = $arg )
  #inner( 'inner' )
#end
#macro( inner $arg )
  #set( $macro.arg = $arg)
  inner: $macro.arg
  #if( $macro.parent )outer: $macro.parent.arg#end
#end

#outer( 'outer' )
#inner( 'just inner' )

and get

  inner: inner
  outer: outer
  inner: just inner

Hope this helps...

In any case, there was plenty of thought and discussion that went into
this change.  Search http://velocity.markmail.org for 'scope' and you
should find more on this.

On Mon, Apr 30, 2012 at 8:49 AM, Boris Partensky
boris.parten...@gmail.com wrote:
 Hello, while going through the upgrade I noticed an incompatible
 behavior during nested macro evaluation. Looks like in 1.7 (all
 default properties) child macro has access to variables set in parent
 macro scope (and those take precedence over globals), and 1.5 sees
 globals. In the following example, in 1.5 unit test the following
 template will evaluate to globalvar, and in 1.7 - to
 outermacroparam. Is this expected behavior?


 1.5 test case


 public void testVelocityNestedMacroScope() throws Exception
    {
        VelocityEngine ve = new VelocityEngine();

        ve.init();

        String template = #macro(outerMacro $arg1)+
                          #innerMacro('blah')+
                          #end+
                          #macro(innerMacro $arg2)$arg1#end+

 #set($arg1='globalval')#outerMacro('outermacroparam');
        StringWriter eval = new StringWriter();
        boolean b = ve.evaluate(new VelocityContext(), eval, foo, template);
        assertEquals(eval.toString(), globalval, eval.toString());

    }

 1.7 test case


  public void testVelocityNestedMacroScope()
    {
        String template = #macro(outerMacro $arg1)+
                          #innerMacro('blah')+
                          #end+
                          #macro(innerMacro $arg2)$arg1#end+

 #set($arg1='globalvar')#outerMacro('outermacroparam');
        String eval = evaluate(template);
        assertEquals(eval, outermacroparam, eval);

    }

 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org


-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: upgrading from 1.5 to 1.7 compatibility issues

[Nathan Bubna]

Can you set velocimacro.context.localscope = true or is it important
for your system to be able to #set global stuff from within macros?

On Mon, Apr 30, 2012 at 10:50 AM, Boris Partensky
boris.parten...@gmail.com wrote:
 Thanks Nathan, I think I do get the whole scoping idea, but my
 understanding was that one of the reasons to turn all scoping off by
 default (and have those properties to begin with) was to provide
 backward compatibility - as in: I upgrade to 1.7 and then I start
 turning on all those nice bells and whistles and use scopes and what
 not. Not so seems like? I also find somewhat strange that a a formal
 argument to a macro takes precedence and overwrites a global variable
 with the same name. How would one go about upgrading existing systems?
 We have roughly 1900 macros, big chunk of those are nested... Maybe I
 am misunderstanding something, but this issue makes it almost
 impossible to upgrade (at least for us).


 Thanks
 Boris

 On Mon, Apr 30, 2012 at 12:55 PM, Nathan Bubna nbu...@gmail.com wrote:
 Yeah, it was intended, and part of an overall move toward
 fixing/simplifying Velocity's variable scoping, avoiding the
 complexities and costs (performance, yes, but mostly time/brainpower
 for users and devs alike) of more programming language type behavior.
 Velocity has long aspired to be a straightfoward template engine and
 avoid being a complete scripting language.  (Implicit) variable
 scoping, as seen in 1.5, was seen as a necessary compromise toward the
 latter; after all, one big fat namespace is always unmanageable,
 right?  Well, there's ways to make that easy to manage. :)  Let's call
 it optional, provided, explicit scoping, explicit because you don't
 have to grok the contextual scope to understand a reference, optional
 because you can ignore it, and provided because Velocity does the work
 of choosing prefixes and creating/destroying the scopes (as any
 implicit scoping system does).  So everything is becoming globally
 scoped, but it is now trivial to turn on automatic, explicit scopes or
 namespaces that you can use when you don't want things to live in the
 global scope.

 Here's an example...  Do you use $velocityCount to get an index of
 sorts inside of #foreach directives?  Well, that's an example of mixed
 implicit/explicit namespacing that gets messy when you nest
 #foreach's, with no good way to get the parent's count and
 unwieldiness when you want to add $velocityIndex, $velocityHasNext and
 so on.  Now, we automatically manage a $foreach var that not only has
 a 'count' property, but an 'index', 'hasNext', 'parent', and so on
 (see 
 http://velocity.apache.org/engine/devel/apidocs/org/apache/velocity/runtime/directive/ForeachScope.html).
  It also, of course, accepts any property you want to set on it (like
 any map).  This makes templates instantly understandable, making
 debugging much better.  You always know exactly what you are referring
 to, and so does anyone else reading the template.

 #foreach is the only 'content directive' that has its explicit scope
 automatically turned on, but all content containing directives
 (including custom body macros) can have their own explicit,
 auto-managed scope, named after themselves.  for example, you can flip
 the macro scope on:

 macro.provide.scope.control = true

 and do:

 #macro( outer $arg )
  #set( $macro.arg = $arg )
  #inner( 'inner' )
 #end
 #macro( inner $arg )
  #set( $macro.arg = $arg)
  inner: $macro.arg
  #if( $macro.parent )outer: $macro.parent.arg#end
 #end

 #outer( 'outer' )
 #inner( 'just inner' )

 and get

  inner: inner
  outer: outer
  inner: just inner

 Hope this helps...

 In any case, there was plenty of thought and discussion that went into
 this change.  Search http://velocity.markmail.org for 'scope' and you
 should find more on this.

 On Mon, Apr 30, 2012 at 8:49 AM, Boris Partensky
 boris.parten...@gmail.com wrote:
 Hello, while going through the upgrade I noticed an incompatible
 behavior during nested macro evaluation. Looks like in 1.7 (all
 default properties) child macro has access to variables set in parent
 macro scope (and those take precedence over globals), and 1.5 sees
 globals. In the following example, in 1.5 unit test the following
 template will evaluate to globalvar, and in 1.7 - to
 outermacroparam. Is this expected behavior?


 1.5 test case


 public void testVelocityNestedMacroScope() throws Exception
    {
        VelocityEngine ve = new VelocityEngine();

        ve.init();

        String template = #macro(outerMacro $arg1)+
                          #innerMacro('blah')+
                          #end+
                          #macro(innerMacro $arg2)$arg1#end+

 #set($arg1='globalval')#outerMacro('outermacroparam');
        StringWriter eval = new StringWriter();
        boolean b = ve.evaluate(new VelocityContext(), eval, foo, 
 template);
        assertEquals(eval.toString(), globalval, eval.toString());

    }

 1.7 test case


  public void

Re: is it possible to maintain a foreach directive after a VelocityEngine.evaluate()?

[Nathan Bubna]

No, i don't think there's a way to do that automatically without
customizing your velocity build.  But you can fake it:

#set( $h = '#')
#set( $d = '$' )
#foreach( $element in $object1.elements )

#end
#if( !$object1 )
${h}foreach( ${d}element in $object1.elements )

${h}end
#end

On Mon, Apr 30, 2012 at 11:44 AM, John McNair jmcn...@enox.com wrote:
 Hi,



 I have an oddball case where I need a multi-stage Velocity template
 evaluation.  That is, image a pipelined process where:



 -          Task one grabs a Velocity template, adds some (but not all) items
 to the Context, evaluates, and sends the partially resolved output as input
 to task two

 -          Task two adds some (but not all) items to the Context, evaluates.



 I know I can have variables like ${object1.member1} that will be preserved
 in the output after evaluate() if object1 is not resolved, however, is it
 possible to maintain a foreach directive after an evaluation:



 ## preserve this 'foreach' in the output if object1 is not resolved

 #foreach( $element in $object1.elements )

 #end



 Thanks in advance,

 John


-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: upgrading from 1.5 to 1.7 compatibility issues

[Nathan Bubna]

http://velocity.apache.org/engine/devel/changes-report.html#a1.7

On Mon, Apr 30, 2012 at 12:37 PM, Boris Partensky
boris.parten...@gmail.com wrote:
 No problem, thanks for making things clear.

  we decided to forego it and notify users of the non-BC change when
 we released 1.7.

 which notification are you referring to? Wonder if there is something
 else in there I am not aware of.


 On Mon, Apr 30, 2012 at 2:34 PM, Nathan Bubna nbu...@gmail.com wrote:
 Congratulations, Boris.  You are the corner case we feared.  :-/  We
 knew when we went ahead with this that providing a migration path
 would be difficult.  We knew most users didn't have extreme numbers of
 macros and hoped that those who didn't frequently nest them, in part
 because of the complexities of heavy scoping in a language that often
 treated scoping as a second-class feature, and in part because of the
 performance issues macros had prior to 1.6.  #parse,
 VelocityLayoutServlet and even custom tools, which lack the implicit
 scoping support, tended to be more performant and encouraged for
 simplifying complicated tools.  Considering those things and the
 difficulty of implementing a BC switch for implicit scoping, we
 decided to forego it and notify users of the non-BC change when we
 released 1.7.

 Sorry.  It sounds like it's going to take some legwork to upgrade in
 the cases where you nested your macros.

 On Mon, Apr 30, 2012 at 11:16 AM, Boris Partensky
 boris.parten...@gmail.com wrote:
 Yep, I am afraid we do set globals from within macros...

 On Mon, Apr 30, 2012 at 2:05 PM, Nathan Bubna nbu...@gmail.com wrote:
 Can you set velocimacro.context.localscope = true or is it important
 for your system to be able to #set global stuff from within macros?

 On Mon, Apr 30, 2012 at 10:50 AM, Boris Partensky
 boris.parten...@gmail.com wrote:
 Thanks Nathan, I think I do get the whole scoping idea, but my
 understanding was that one of the reasons to turn all scoping off by
 default (and have those properties to begin with) was to provide
 backward compatibility - as in: I upgrade to 1.7 and then I start
 turning on all those nice bells and whistles and use scopes and what
 not. Not so seems like? I also find somewhat strange that a a formal
 argument to a macro takes precedence and overwrites a global variable
 with the same name. How would one go about upgrading existing systems?
 We have roughly 1900 macros, big chunk of those are nested... Maybe I
 am misunderstanding something, but this issue makes it almost
 impossible to upgrade (at least for us).


 Thanks
 Boris

 On Mon, Apr 30, 2012 at 12:55 PM, Nathan Bubna nbu...@gmail.com wrote:
 Yeah, it was intended, and part of an overall move toward
 fixing/simplifying Velocity's variable scoping, avoiding the
 complexities and costs (performance, yes, but mostly time/brainpower
 for users and devs alike) of more programming language type behavior.
 Velocity has long aspired to be a straightfoward template engine and
 avoid being a complete scripting language.  (Implicit) variable
 scoping, as seen in 1.5, was seen as a necessary compromise toward the
 latter; after all, one big fat namespace is always unmanageable,
 right?  Well, there's ways to make that easy to manage. :)  Let's call
 it optional, provided, explicit scoping, explicit because you don't
 have to grok the contextual scope to understand a reference, optional
 because you can ignore it, and provided because Velocity does the work
 of choosing prefixes and creating/destroying the scopes (as any
 implicit scoping system does).  So everything is becoming globally
 scoped, but it is now trivial to turn on automatic, explicit scopes or
 namespaces that you can use when you don't want things to live in the
 global scope.

 Here's an example...  Do you use $velocityCount to get an index of
 sorts inside of #foreach directives?  Well, that's an example of mixed
 implicit/explicit namespacing that gets messy when you nest
 #foreach's, with no good way to get the parent's count and
 unwieldiness when you want to add $velocityIndex, $velocityHasNext and
 so on.  Now, we automatically manage a $foreach var that not only has
 a 'count' property, but an 'index', 'hasNext', 'parent', and so on
 (see 
 http://velocity.apache.org/engine/devel/apidocs/org/apache/velocity/runtime/directive/ForeachScope.html).
  It also, of course, accepts any property you want to set on it (like
 any map).  This makes templates instantly understandable, making
 debugging much better.  You always know exactly what you are referring
 to, and so does anyone else reading the template.

 #foreach is the only 'content directive' that has its explicit scope
 automatically turned on, but all content containing directives
 (including custom body macros) can have their own explicit,
 auto-managed scope, named after themselves.  for example, you can flip
 the macro scope on:

 macro.provide.scope.control = true

 and do:

 #macro( outer $arg )
  #set( $macro.arg = $arg

Re: upgrading from 1.5 to 1.7 compatibility issues

[Nathan Bubna]

This might be of use too:
http://velocity.apache.org/engine/releases/velocity-1.7/upgrading.html

On Mon, Apr 30, 2012 at 12:51 PM, Nathan Bubna nbu...@gmail.com wrote:
 http://velocity.apache.org/engine/devel/changes-report.html#a1.7

 On Mon, Apr 30, 2012 at 12:37 PM, Boris Partensky
 boris.parten...@gmail.com wrote:
 No problem, thanks for making things clear.

  we decided to forego it and notify users of the non-BC change when
 we released 1.7.

 which notification are you referring to? Wonder if there is something
 else in there I am not aware of.


 On Mon, Apr 30, 2012 at 2:34 PM, Nathan Bubna nbu...@gmail.com wrote:
 Congratulations, Boris.  You are the corner case we feared.  :-/  We
 knew when we went ahead with this that providing a migration path
 would be difficult.  We knew most users didn't have extreme numbers of
 macros and hoped that those who didn't frequently nest them, in part
 because of the complexities of heavy scoping in a language that often
 treated scoping as a second-class feature, and in part because of the
 performance issues macros had prior to 1.6.  #parse,
 VelocityLayoutServlet and even custom tools, which lack the implicit
 scoping support, tended to be more performant and encouraged for
 simplifying complicated tools.  Considering those things and the
 difficulty of implementing a BC switch for implicit scoping, we
 decided to forego it and notify users of the non-BC change when we
 released 1.7.

 Sorry.  It sounds like it's going to take some legwork to upgrade in
 the cases where you nested your macros.

 On Mon, Apr 30, 2012 at 11:16 AM, Boris Partensky
 boris.parten...@gmail.com wrote:
 Yep, I am afraid we do set globals from within macros...

 On Mon, Apr 30, 2012 at 2:05 PM, Nathan Bubna nbu...@gmail.com wrote:
 Can you set velocimacro.context.localscope = true or is it important
 for your system to be able to #set global stuff from within macros?

 On Mon, Apr 30, 2012 at 10:50 AM, Boris Partensky
 boris.parten...@gmail.com wrote:
 Thanks Nathan, I think I do get the whole scoping idea, but my
 understanding was that one of the reasons to turn all scoping off by
 default (and have those properties to begin with) was to provide
 backward compatibility - as in: I upgrade to 1.7 and then I start
 turning on all those nice bells and whistles and use scopes and what
 not. Not so seems like? I also find somewhat strange that a a formal
 argument to a macro takes precedence and overwrites a global variable
 with the same name. How would one go about upgrading existing systems?
 We have roughly 1900 macros, big chunk of those are nested... Maybe I
 am misunderstanding something, but this issue makes it almost
 impossible to upgrade (at least for us).


 Thanks
 Boris

 On Mon, Apr 30, 2012 at 12:55 PM, Nathan Bubna nbu...@gmail.com wrote:
 Yeah, it was intended, and part of an overall move toward
 fixing/simplifying Velocity's variable scoping, avoiding the
 complexities and costs (performance, yes, but mostly time/brainpower
 for users and devs alike) of more programming language type behavior.
 Velocity has long aspired to be a straightfoward template engine and
 avoid being a complete scripting language.  (Implicit) variable
 scoping, as seen in 1.5, was seen as a necessary compromise toward the
 latter; after all, one big fat namespace is always unmanageable,
 right?  Well, there's ways to make that easy to manage. :)  Let's call
 it optional, provided, explicit scoping, explicit because you don't
 have to grok the contextual scope to understand a reference, optional
 because you can ignore it, and provided because Velocity does the work
 of choosing prefixes and creating/destroying the scopes (as any
 implicit scoping system does).  So everything is becoming globally
 scoped, but it is now trivial to turn on automatic, explicit scopes or
 namespaces that you can use when you don't want things to live in the
 global scope.

 Here's an example...  Do you use $velocityCount to get an index of
 sorts inside of #foreach directives?  Well, that's an example of mixed
 implicit/explicit namespacing that gets messy when you nest
 #foreach's, with no good way to get the parent's count and
 unwieldiness when you want to add $velocityIndex, $velocityHasNext and
 so on.  Now, we automatically manage a $foreach var that not only has
 a 'count' property, but an 'index', 'hasNext', 'parent', and so on
 (see 
 http://velocity.apache.org/engine/devel/apidocs/org/apache/velocity/runtime/directive/ForeachScope.html).
  It also, of course, accepts any property you want to set on it (like
 any map).  This makes templates instantly understandable, making
 debugging much better.  You always know exactly what you are referring
 to, and so does anyone else reading the template.

 #foreach is the only 'content directive' that has its explicit scope
 automatically turned on, but all content containing directives
 (including custom body macros) can have their own explicit,
 auto-managed

Re: upgrading from 1.5 to 1.7 compatibility issues

[Nathan Bubna]

On Mon, Apr 30, 2012 at 1:06 PM, Boris Partensky
boris.parten...@gmail.com wrote:
 I am seeing 3 bullet points there pertinent to this issue and all 3
 seem to indicate that being compatible was the intention there, or am
 I wrong ? The way I read #2 and #3 is that the parent scope should
 only be available if I explicitly specify the scope I want (parent or
 topmost or replaced).

Yes, compatibility was and is a goal, but with limited resources,
continuing support for implicit scoping in macros didn't make the cut.

 * For performance and compatibility these are all off by default,
 *except* for $foreach. The others may be enabled by setting a velocity
 property like:macro.provide.scope.control = true

off for compatibility here means reduced chance of squashing
someone's previous $macro or $template var, or more realistically $foo
when there is a body macro call #foo

 * When scopes of the same type are nested make the parent Scope
 available through the child (e.g. $foreach.parent or
 $foreach.topmost).

$scope.parent is always and only made available when there actually
is an explicit parent scope provided. e.g.

#foreach( $a in $b )
   #foreach( $c in $d )
 $foreach.parent here == $foreach.topmost
   #end
  $foreach here == $foreach.topmost
#end

Think parent and topmost as ways to navigate the scope stack, which
only exists when scope.provide.scope.control = true

 * When a Scope reference overrides an existing reference that is not a
 Scope, make it available through the Scope (e.g. $foreach.replaced).

$scope.replaced is not a parent scope, but is 'bar' in the example:
#set($foo='bar') #@foo $foo.replaced #end

This is a workaround for incompatibilities/migrations/etc.  It doesn't
provide any compatibility with the older implicit system of scoping.

 On Mon, Apr 30, 2012 at 3:51 PM, Nathan Bubna nbu...@gmail.com wrote:
 http://velocity.apache.org/engine/devel/changes-report.html#a1.7

 On Mon, Apr 30, 2012 at 12:37 PM, Boris Partensky
 boris.parten...@gmail.com wrote:
 No problem, thanks for making things clear.

  we decided to forego it and notify users of the non-BC change when
 we released 1.7.

 which notification are you referring to? Wonder if there is something
 else in there I am not aware of.


 On Mon, Apr 30, 2012 at 2:34 PM, Nathan Bubna nbu...@gmail.com wrote:
 Congratulations, Boris.  You are the corner case we feared.  :-/  We
 knew when we went ahead with this that providing a migration path
 would be difficult.  We knew most users didn't have extreme numbers of
 macros and hoped that those who didn't frequently nest them, in part
 because of the complexities of heavy scoping in a language that often
 treated scoping as a second-class feature, and in part because of the
 performance issues macros had prior to 1.6.  #parse,
 VelocityLayoutServlet and even custom tools, which lack the implicit
 scoping support, tended to be more performant and encouraged for
 simplifying complicated tools.  Considering those things and the
 difficulty of implementing a BC switch for implicit scoping, we
 decided to forego it and notify users of the non-BC change when we
 released 1.7.

 Sorry.  It sounds like it's going to take some legwork to upgrade in
 the cases where you nested your macros.

 On Mon, Apr 30, 2012 at 11:16 AM, Boris Partensky
 boris.parten...@gmail.com wrote:
 Yep, I am afraid we do set globals from within macros...

 On Mon, Apr 30, 2012 at 2:05 PM, Nathan Bubna nbu...@gmail.com wrote:
 Can you set velocimacro.context.localscope = true or is it important
 for your system to be able to #set global stuff from within macros?

 On Mon, Apr 30, 2012 at 10:50 AM, Boris Partensky
 boris.parten...@gmail.com wrote:
 Thanks Nathan, I think I do get the whole scoping idea, but my
 understanding was that one of the reasons to turn all scoping off by
 default (and have those properties to begin with) was to provide
 backward compatibility - as in: I upgrade to 1.7 and then I start
 turning on all those nice bells and whistles and use scopes and what
 not. Not so seems like? I also find somewhat strange that a a formal
 argument to a macro takes precedence and overwrites a global variable
 with the same name. How would one go about upgrading existing systems?
 We have roughly 1900 macros, big chunk of those are nested... Maybe I
 am misunderstanding something, but this issue makes it almost
 impossible to upgrade (at least for us).


 Thanks
 Boris

 On Mon, Apr 30, 2012 at 12:55 PM, Nathan Bubna nbu...@gmail.com wrote:
 Yeah, it was intended, and part of an overall move toward
 fixing/simplifying Velocity's variable scoping, avoiding the
 complexities and costs (performance, yes, but mostly time/brainpower
 for users and devs alike) of more programming language type behavior.
 Velocity has long aspired to be a straightfoward template engine and
 avoid being a complete scripting language.  (Implicit) variable
 scoping, as seen in 1.5, was seen as a necessary compromise toward the
 latter

Re: Configuring number of parsers and buffer sizes

[Nathan Bubna]

parser.pool.size

is this in 1.7?  i thought we trimmed a lot of the excess between 1.5
and 1.6, but if we can trim more, that'd be swell.

On Thu, Apr 26, 2012 at 5:59 PM, Christopher Schultz
ch...@christopherschultz.net wrote:
 All,

 I've been looking at the docs for both Velocity Tools and Velocity
 itself and I can't seem to find out what the properties are for
 controlling the number of template parsers to create and how big their
 buffer sizes are.

 I've been doing some memory profiling of my webapp and it looks like
 Velocity is keeping some rather large (and empty -- probably because
 they haven't yet been used) buffers for parsing.

 I can see a bunch (76) of int[4096] arrays within VelocityCharStream
 (the class member is 'bufline'), and I can also see buried in
 VelocityCharStream which uses an InputStreamReader ('inputStream') a
 byte[8192] which appears to exist 48 separate times.

 So, the total wasted space due to these two arrays (duplicated a bunch
 of times) is, on the face of it, small: it's like 1-2MiB. On the other
 hand, if I don't need all that buffer space, I'd like to remove it.

 So, first: how can I configure the number of parsers and possibly the
 buffer sizes used by them?

 Second: is VelocityCharStream essentially double-buffering since the
 InputStreamReader seems to have a large buffer inside it and also
 VelocityCharStream has its own buffer?

 Thanks,
 -chris


-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: getting session id

[Nathan Bubna]

If you put the HttpSession into the Velocity context, then you can use it.

The VelocityViewServlet (part of the VelocityTools project) does that
for you automatically.  Thus the references to $session being
magically available.

On Wed, Apr 18, 2012 at 11:46 AM, Michael Remijan mremi...@bjc.org wrote:

 I want to be get the user's session id in my VM page.

 How do I do that?

 I have found references to $request.getSession() but this does not work.
 $request and $session are not bound so I can't figure out how I can get the
 session id.


 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org

-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: getting session id

[Nathan Bubna]

The VelocityViewServlet does.  Velocity itself is merely a template
engine and knows nothing about J2EE, nor should it.

On Wed, Apr 18, 2012 at 12:04 PM, Michael Remijan mremi...@bjc.org wrote:
 It doesn't put the session in automatically??  the same with the request?

 Nathan Bubna nbu...@gmail.com 4/18/2012 2:02 PM 

 If you put the HttpSession into the Velocity context, then you can use it.

 The VelocityViewServlet (part of the VelocityTools project) does that
 for you automatically.  Thus the references to $session being
 magically available.

 On Wed, Apr 18, 2012 at 11:46 AM, Michael Remijan mremi...@bjc.org wrote:

 I want to be get the user's session id in my VM page.

 How do I do that?

 I have found references to $request.getSession() but this does not work.
 $request and $session are not bound so I can't figure out how I can get
 the
 session id.


 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org

 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org



 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org

-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: ReferenceInsertionEventHandler

[Nathan Bubna]

It would not be called on $testing, because $testing is not being
inserted into the output.  And it is not called on the variables
within the loop, because in this example testing appears to be
null/empty, so there is no attempt to render the body of the #foreach.

On Fri, Mar 30, 2012 at 6:45 AM, Jean-Francois Croteau jfcrot...@8d.com wrote:
 Hi everyone,
 quick question about the ReferenceInsertionEventHandler: is it supposed to
 be called on a variable called into a #foreach loop (or even on the variable
 defining the foreach loop)?

 For example:

 public class IsThisAVelocityBug {

 public static void main( String[] args ) {
 String template1 = ${otherVariable}\n;
 String template2 = #foreach($test in
 $testing)\n${test.something}\n${otherVariable}\n#end;

 VelocityEngine veloctiyEngine = new VelocityEngine();

 VelocityContext velocityContext = new VelocityContext();
 EventCartridge eventCartridge = new EventCartridge();
 velocityContext.attachEventCartridge( eventCartridge );

 eventCartridge.addReferenceInsertionEventHandler( new ReferenceInsertionEventHandler()
 {

 @Override
 public Object referenceInsert( String reference, Object value ) {
 System.out.println( Inserting :  + reference );
 return reference;
 }
 } );

 System.out.println( template1 );
 veloctiyEngine.evaluate( velocityContext, new StringWriter(), template1,
 template1 );
 System.out.println( template2 );
 veloctiyEngine.evaluate( velocityContext, new StringWriter(), template2,
 template2 );
 }
 }

 Here is the output:

 template1
 09:43:39.568 [main] DEBUG org.apache.velocity - CommonsLogLogChute name is
 'org.apache.velocity'
 09:43:39.579 [main] DEBUG org.apache.velocity - Initializing Velocity,
 Calling init()...
 09:43:39.579 [main] DEBUG org.apache.velocity - Starting Apache Velocity
 v1.7 (compiled: 2010-11-19 12:14:37)
 09:43:39.580 [main] DEBUG org.apache.velocity - Default Properties File:
 org/apache/velocity/runtime/defaults/velocity.properties
 09:43:39.580 [main] DEBUG org.apache.velocity - Trying to use logger class
 org.apache.velocity.runtime.log.AvalonLogChute
 09:43:39.580 [main] DEBUG org.apache.velocity - Target log system for
 org.apache.velocity.runtime.log.AvalonLogChute is not available
 (java.lang.NoClassDefFoundError: org/apache/log/format/Formatter).  Falling
 back to next log system...
 09:43:39.581 [main] DEBUG org.apache.velocity - Trying to use logger class
 org.apache.velocity.runtime.log.Log4JLogChute
 09:43:39.581 [main] DEBUG org.apache.velocity - Target log system for
 org.apache.velocity.runtime.log.Log4JLogChute is not available
 (java.lang.NoClassDefFoundError: org/apache/log4j/Layout).  Falling back to
 next log system...
 09:43:39.581 [main] DEBUG org.apache.velocity - Trying to use logger class
 org.apache.velocity.runtime.log.CommonsLogLogChute
 09:43:39.582 [main] DEBUG org.apache.velocity - Using logger class
 org.apache.velocity.runtime.log.CommonsLogLogChute
 09:43:39.606 [main] DEBUG org.apache.velocity - ResourceLoader instantiated:
 org.apache.velocity.runtime.resource.loader.FileResourceLoader
 09:43:39.610 [main] DEBUG org.apache.velocity - Do unicode file
 recognition:  false
 09:43:39.611 [main] DEBUG org.apache.velocity - FileResourceLoader : adding
 path '.'
 09:43:39.724 [main] DEBUG org.apache.velocity - ResourceCache: initialized
 (class org.apache.velocity.runtime.resource.ResourceCacheImpl) with class
 java.util.Collections$SynchronizedMap cache map.
 09:43:39.728 [main] DEBUG org.apache.velocity - Loaded System Directive:
 org.apache.velocity.runtime.directive.Stop
 09:43:39.732 [main] DEBUG org.apache.velocity - Loaded System Directive:
 org.apache.velocity.runtime.directive.Define
 09:43:39.733 [main] DEBUG org.apache.velocity - Loaded System Directive:
 org.apache.velocity.runtime.directive.Break
 09:43:39.735 [main] DEBUG org.apache.velocity - Loaded System Directive:
 org.apache.velocity.runtime.directive.Evaluate
 09:43:39.737 [main] DEBUG org.apache.velocity - Loaded System Directive:
 org.apache.velocity.runtime.directive.Literal
 09:43:39.745 [main] DEBUG org.apache.velocity - Loaded System Directive:
 org.apache.velocity.runtime.directive.Macro
 09:43:39.759 [main] DEBUG org.apache.velocity - Loaded System Directive:
 org.apache.velocity.runtime.directive.Parse
 09:43:39.764 [main] DEBUG org.apache.velocity - Loaded System Directive:
 org.apache.velocity.runtime.directive.Include
 09:43:39.769 [main] DEBUG org.apache.velocity - Loaded System Directive:
 org.apache.velocity.runtime.directive.Foreach
 09:43:40.229 [main] DEBUG org.apache.velocity - Created '20' parsers.
 09:43:40.260 [main] DEBUG org.apache.velocity - Velocimacro :
 velocimacro.library is not set.  Trying default library:
 VM_global_library.vm
 09:43:40.260 [main] DEBUG org.apache.velocity - Velocimacro : Default
 library not found.
 09:43:40.260 [main] DEBUG org.apache.velocity - Velocimacro : allowInline =
 true : VMs can be defined inline in templates
 09:43:40.260 [main] DEBUG 

Re: Velocity engine 2.0 release

[Nathan Bubna]

It'll be released when it's ready, and how quickly that happens
depends on people stepping up to help.  Feel free to jump in and help.
 There are open issues in JIRA, as well as general testing and
performance testing that needs to happen.  So much energy in the
webapp world has slipped over to the client side (at least so much of
my energy, though i doubt i'm alone) that work is slow.  We need more
people to step up their game and contribute. :)

On Mon, Mar 26, 2012 at 6:47 AM, Nikhil G. Daddikar n...@celoxis.com wrote:

 Any ideas when velocity 2.0 release is going to happen. I am unable to port
 from a competing product because velocity 1.7 doesn't have default arguments
 for macros. But I see that in 2.0, so I am wondering when I will be able to
 move to Velocity.

 Thanks.


 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org


-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: Velocity syntax

[Nathan Bubna]

On Mon, Mar 26, 2012 at 12:36 AM, Nikhil G. Daddikar n...@celoxis.com wrote:
 Hello,

 I was looking at Velocity syntax and have a few questions.

 What is use of parenthesis in the #set directive: #set ($x = 1) Why not
 simply: #set $x = 1 ?

Why do you ask? Is there some reason that a space is superior to a
parenthesis?  The latter is easier for my eyes to parse, but Sergiu is
quite right that consistency with other places where parentheses are
more obviously useful is the key reason.

 Another question is regarding curly braces: What is the use of curly braces
 in the directives? E.g. #{set} ($x = 1)

 I am sure there are good reasons, just would like to know why.

 Thanks.



 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org


-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: [ANNOUNCE] Velosurf 2.3

[Nathan Bubna]

Congrats, Claude!  Great work.

On Fri, Mar 9, 2012 at 8:45 AM, Claude Brisson cla...@renegat.net wrote:
 Velosurf 2.3 has just been released.

 This release brings several new features, among which 'upsert' methods,
 per-field dirty flags, a cleaner syntax to specify external parameters
 for a query (aka 'parametrized getters'), some meta-information
 methods... It also provides several bugfixes and optimizations related
 to statements pools handling, database reverse enginering, connections
 checking and instance caching.

 It can be downloaded from:
 http://sourceforge.net/projects/velosurf/files/velosurf/2.3/velosurf-2.3.tgz/download


  --
  Claude


 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org


-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: Dynamic Templates

[Nathan Bubna]

Would you consider submitting this via
https://issues.apache.org/jira/browse/VELOCITY?

That would allow us to possibly incorporate improvements from your
code into future versions.

On Thu, Feb 9, 2012 at 2:47 PM, Mark-12345
marks1900-pos...@yahoo.com.au wrote:

 I thought I would share the following code with the Apache Velocity
 community.


 Problem Description:  I wanted to use Dynamic Templates though I found the
 following had massive performance implications.

 -- Velocity Call Snippet --
 String template = message.to:  ${message.to} ;
 StringWriter velocityWriter = new StringWriter();
 velocityEngine.evaluate( velocityContext, velocityWriter, LOG, template );
 return velocityWriter.toString();
 -- Velocity Call Snippet --


 As such, I needed an alternate solution and guessed that if I could cache
 the Velocity templates used I could see big performance gains.

 I initially looked to the
 org.apache.velocity.runtime.resource.loader.StringResourceLoader class to
 solve my problems.   The StringResourceLoader class requires an instance of
 the StringResourceRepository class, and the only implementation of
 StringResourceRepository is StringResourceRepositoryImpl.  Unfortunately,
 since the number of unique templates will grow over time, in time the
 StringResourceRepositoryImpl.resources Map will cause an out of memory
 error.

 Why doesn't StringResourceRepositoryImpl use a cache with a maximum size?
 Is a cache even needed as the Velocity ResourceCacheImpl will cache
 Templates?

 +
 In the end I settled on the following solution.  From my tests using YourKit
 Java Profiler I invoked the static Velocity wrapping method 100,000 times,
 and discovered a performance difference of around 75 fold (146,937ms vs
 1,981ms).

 Below is my solution.  Feedback appreciated.

 +


 Regards,
 Mark

 -- Velocity Engine Setup Snippet --
 Properties p = new Properties();

 p.setProperty( RuntimeConstants.INPUT_ENCODING, DEFAULT_ENCODING );
 p.setProperty( RuntimeConstants.OUTPUT_ENCODING, DEFAULT_ENCODING );

 p.setProperty( RuntimeConstants.RESOURCE_MANAGER_CLASS,
       org.apache.velocity.runtime.resource.ResourceManagerImpl );
 p.setProperty( RuntimeConstants.RESOURCE_MANAGER_CACHE_CLASS,
       org.apache.velocity.runtime.resource.ResourceCacheImpl );
 p.setProperty( RuntimeConstants.RESOURCE_MANAGER_DEFAULTCACHE_SIZE, 100 );

 p.setProperty( RuntimeConstants.RESOURCE_LOADER, string );
 p.setProperty( string.resource.loader.class,
       custom.SimpleStringResourceLoader );
 p.setProperty( string.resource.loader.encoding, DEFAULT_ENCODING );
 p.setProperty( string.resource.loader.cache, Boolean.TRUE.toString() );
 p.setProperty( string.resource.loader.modificationCheckInterval, -1 );

 VelocityEngine engine = new VelocityEngine( p );
 engine.init();
 -- Velocity Engine Setup Snippet --

 -- Velocity Call Snippet --
 String template = message.to:  ${message.to} ;
 StringWriter velocityWriter = new StringWriter();
 Template veTemplate = velocityEngine.getTemplate( template );
 veTemplate.merge( velocityContext, velocityWriter );
 return velocityWriter.toString();
 -- Velocity Call Snippet --




 -- Velocity Supporting Class Snippet --

 package custom;

 import java.io.ByteArrayInputStream;
 import java.io.InputStream;
 import java.io.UnsupportedEncodingException;
 import java.util.concurrent.atomic.AtomicLong;

 import org.apache.commons.collections.ExtendedProperties;
 import org.apache.velocity.exception.VelocityException;
 import org.apache.velocity.runtime.resource.Resource;
 import org.apache.velocity.runtime.resource.loader.ResourceLoader;
 import org.apache.velocity.runtime.resource.util.StringResource;

 public class SimpleStringResourceLoader extends ResourceLoader
 {

    protected static int classMetricsLevel;
    protected static AtomicLong totalClassInstancesCreatedCount;
    protected static AtomicLong totalStringsGeneratedCount;

    static {
        classMetricsLevel = 1;
        totalClassInstancesCreatedCount = new AtomicLong();
        totalStringsGeneratedCount = new AtomicLong();
    }


    protected String encoding;


    public SimpleStringResourceLoader()
    {

        if ( classMetricsLevel  0 )
        {
            totalClassInstancesCreatedCount.incrementAndGet();
        }

        this.encoding = UTF-8;
    }

    @Override
    public void init( ExtendedProperties paramExtendedProperties )
    {
        String paramEncoding = paramExtendedProperties.getString( encoding
 );

        if ( null != encoding  encoding.trim().length()  0 )
        {
            this.encoding = paramEncoding;
        }
    }

    @Override
    public InputStream getResourceStream( String contents )
    {
        if ( classMetricsLevel  1 )
        {
            totalStringsGeneratedCount.incrementAndGet();
        }

        StringResource resource = new StringResource( contents, encoding );

        byte[] byteArray = null;
     

Re: Validate templates before use

[Nathan Bubna]

Pre-validating templates would fall in the advanced uses category,
making it much more reasonable to interact with Template. :)

On Mon, Feb 6, 2012 at 7:07 AM, Chad La Joie laj...@itumi.biz wrote:
 Thanks, thats what I was looking for.  After my last email about the
 Template object I wasn't sure if I should really be calling
 getTemplate() or not.

 On Mon, Feb 6, 2012 at 09:58, Guillaume Polet guillaume.po...@gmail.com 
 wrote:
 I would go for the fundamentals of the developer guide:
 http://velocity.apache.org/engine/releases/velocity-1.7/developer-guide.html

 // If not done yet, init an engine (here the one of the singleton pattern
 but there is a non-static call that you can do if you don't use the
 singleton pattern engine)
 Velocity.init();

 Template template = null;
 try {
  // Call getTemplate will automatically look up the template and parse it.
  template = Velocity.getTemplate(mytemplate.vm);
 } catch( ResourceNotFoundException rnfe ) {
   // This should not happen in your case (although it could)
 } catch( ParseErrorException pee ) {
   // Well pretty obvious that the template is not correct
 } catch( MethodInvocationException mie ) {
   // I don't remember in which case this exception is thrown.
 } catch( Exception e ) {
 }


 Cheers,
 Guillaume

 Le 6/02/2012 15:44, Chad La Joie a écrit :

 On Mon, Feb 6, 2012 at 09:41, sebbseb...@gmail.com  wrote:

 Just because it's parseable does not mean it's safe to use ...
 allowing an end-user to provide a template without manual checking
 sounds like a recipe for inviting exploits.

 There's nothing I can do about that.  If the user wants to write a
 template that exploits their own system, that's up to them.  I'm just
 trying to provide what checking I can at startup time.




 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org




 --
 Chad La Joie
 www.itumi.biz
 trusted identities, delivered

 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org


-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: Most efficient evaluation

[Nathan Bubna]

On Sat, Feb 4, 2012 at 7:58 AM, Chad La Joie laj...@itumi.biz wrote:
 I'm looking for the most efficient/performant way to evaluate a
 template and have some questions surrounding this.

 1. Are Template objects reusable and thread safe?  If they're just
 ASTs, it seems like they should be.

Yes, but you shouldn't have to directly interact with Template
objects, because...

 2. Does the Velocity/VelocityEngine class cache compiled templates (as
 Template objects or anything else)?

... they are handled (and yes, cached, if you want) internally.  You
just turn caching on.  See User's Guide for more info.

 3. If yes to both above, is there really any difference between
 calling Velocity[Engine].merge and Template.merge?

Mostly in that VelocityEngine is the API users are expected to use and
Template is really much more of an internal class for advanced
purposes.

 Thanks.

 --
 Chad La Joie
 www.itumi.biz
 trusted identities, delivered

 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org


-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: MIME type for velocity templates

[Nathan Bubna]

On Tue, Jan 31, 2012 at 7:48 AM, Christopher Schultz
ch...@christopherschultz.net wrote:
 Nathan,

 On 1/25/12 1:16 PM, Nathan Bubna wrote:
 text/velocity sounds fine to me.  this isn't something that i recall
 coming up previously, so i'm pretty sure there's no official opinion.

 Why not text/plain?

If you you are serving up plain text, sure, why not?  You can use
plain text as a template, or almost plain text.  But what if they are
serving up an un-rendered template that has enough VTL directives in
it to clearly not be plain text.  Wouldn't that seem like a more
fitting place for text/x-velocity?  I was just assuming the mime type
was for a template itself, not the rendered contents of a template. :)

 -chris


-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: Stopping parsing

[Nathan Bubna]

This is probably something best handled by a Filter, not in a
template.  But that said, no, there is no stop parsing command
anymore.  As of Velocity 1.7, #stop is used to stop *rendering*
instead of parsing.  But i think that's what you want, right?

On Sun, Jan 29, 2012 at 12:49 PM, Andrew Ducker and...@ducker.org.uk wrote:
 Is there a way to say Stop parsing at this point?

 I can wrap the two paths through my document in an #if #else but it would
 feel a bit cleaner to me to say:
 #if(!$user.loggedIn)
 You are not logged in
 #STOPOPROCESSING

 And then have the rest of my document underneath that.

 If that's not possible then I'll live with:
 #if(!$user.loggedIn)
 You are not logged in
 #else
 Do lots of stuff
 #end

 Thanks,

 Andy

 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org


-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: Velocity and XML as context

[Nathan Bubna]

You might prefer the syntax provided by the XmlTool (in the
VelocityTools project)

http://velocity.apache.org/tools/releases/2.0/javadoc/org/apache/velocity/tools/generic/XmlTool.html

I much prefer it to Anakia and DVSL for simply navigating/reading xml
files in a template.

On Wed, Jan 25, 2012 at 6:19 AM, Angelo zerr angelo.z...@gmail.com wrote:
 Hi Velocity Team,

 I'm one of developer of XDocReport http://code.google.com/p/xdocreport/which
 is Java reporting API to generate docx, odt, pptx etc from a docx, odt,
 pptx by using Velocity and Freemarker syntax to set the fields to replace,
 manage loop etc...
 Goal of XDocReport is to create reporting with MS Word or OpenOffice and
 use Velocity/Freemarker interpolation and directive. So the report is very
 simply to create.

 Velocity integration with XDocReport works great and very performant (I had
 implemented my own Velocity cache).

 I would like use XML DOM as Java context (insteaod of Java POJO context).
 When I serach XML+Velocity in google I find :

  * DVSL : http://velocity.apache.org/dvsl/releases/dvsl-1.0/users-guide.html
 * Anakia : http://velocity.apache.org/engine/devel/anakia.html

 As I have said, goal of XDocReport is to simplify the reporting creation
 and if I want to use XML as Java context with Velocity It seems I must use
 Anakia and I find it's not very easy to write the fields (more there is a
 new dependency to JDOM).
 You must write that with Velocity Anakia :

 --
 #set ($customMenus = $xpath.applyTo(body/menu,$customContext))
 #foreach($customMenu in $customMenus)
  strong$customMenu.getAttributeValue(name)/strong
 #end
 --

 With Freemarker I find it's more easy :

 --
 [#list doc.body.menu as m]
  strong${m.@name}/strong
 [/#list]
 --

 So I would like know if it's possible to do that with Velocity, if I can
 implement my own DOM-Wrapper to manage this syntax.

 Thank a lot for your help.

 Regards Angelo

-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: Velocity template Evaluation

[Nathan Bubna]

What is dead may never die, but rises again, harder and stronger.

Ok, but seriously, dead means no community.  When a project's
community dies, Apache puts it into the Attic project.   So pretty
much any non-Attic project is not dead.  Velocity has both a large
user community that supports each other both on this list and
stackoverflow.com and a small developer community and thus will not be
going into the Attic anytime soon.  Lack of activity in this case
merely means that no one is highly motivated to work on the next
version much because the current releases (Engine 1.7 and Tools 2.0)
are great for most any templating need.  The projects have reached a
high level of stability and maturity.

On Tue, Jan 24, 2012 at 9:40 AM, abc12345 indrajit.bis...@21st.com wrote:

 I'm a developer and trying to evaluate Velocity as an alternative to JSP,
 When I go to the Apache Velocity Site I don't see much activity on this
 Project other than a few bug fixes, there are no dates for the next Release
 etc.
 Can someone tell me if this is a dead project.

 Thanks
 --
 View this message in context: 
 http://old.nabble.com/Velocity-template-Evaluation-tp33196367p33196367.html
 Sent from the Velocity - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org


-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: Thread safety reuse ToolContext in Servlet Environment

[Nathan Bubna]

Yes, that looks safe to me.  As long as the ToolContext is nested
behind another context, so it isn't changed by #set calls in the
threads, you should be fine.

On Wed, Jan 18, 2012 at 2:16 AM, Christian Beutenmüller
christian.beutenmuel...@saxess.ag wrote:
 Hi folks,

 I'm currently embedding Velocity in some custom JSF Components roughly
 based on the idea of Mathias Wessendorf as shown in
 http://people.apache.org/~matzew/jsfvelocity.html.
 Now I'd like to know if it's safe to reuse the ToolContext accross
 requests and threads.

 Currently my setup code is:

 Singleton setup of VelocityEngine via Spring:
  - Init VelocityEngine as Singleton
  - Init ToolManager as Singleton, set VelocityEngine
  - Get Tool Context from ToolManager

 Per Request Rendering:
  - Create VelocityContext based on ToolContext and Parameter Map
  - merge Template

 The code is shown below.

 Are there any threading/synchronisation Issues I am not aware of?
 The documentation I've read so far, did basically tell, that chaininig
 of VelocityContext instances should be ok in a multithread environment.

 Code:

 //Singleton setup:
         public void setEngine(final VelocityEngine engine) {
                this.engine = engine;
                this.toolManager = new ToolManager();
                this.toolManager.setVelocityEngine(engine);
                this.toolManager.setUserCanOverwriteTools(false);
                this.toolContext = toolManager.createContext();
        }

 //per Request use:
  public void merge(String template, ResponseWriter writer,  MapString,
 Object parameters) {

        final VelocityContext velocityContext = new
 VelocityContext(parameters, toolContext);
        engine.mergeTemplate(template, UTF-8, velocityContext, writer);
    }

 Greetings,
 Christian


 --

 Christian Beutenmüller
 saxess.ag
 Springerstr. 15
 04105 Leipzig

 Tel.: +49(341)218299-60
 Fax.: +49(341)218299-94
 Mail: christian.beutenmuel...@saxess.ag
 Http: www.saxess.ag

 HRB 17905 (AG Leipzig)
 Vorstand: Gerd Tautenhahn, Matthias Lehmann
 Aufsichtsrat (Vors.): Holger Grentzebach



 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org

-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: Can clients really specify 'layout' parameter in the URL?

[Nathan Bubna]

On Mon, Jan 9, 2012 at 11:00 AM, Christopher Schultz
ch...@christopherschultz.net wrote:
 Nathan,

 On 1/8/12 2:04 PM, Nathan Bubna wrote:
 The tools.view.servlet.layout.directory property is fairly important
 here, as it is prefixed to layout paths.  i didn't think just slipping
 .. into the path would get Velocity to load things out of that
 directory.  Seems like this isn't anymore risky than allowing third
 parties to use #parse, #inclue or anything else that loads/renders
 templates dynamically.

 That's true, but if you never code your templates to use request
 /parameters/ as part of a path to #parse or #include, then you are safe.
 In this case, the request parameter is used if it's there by
 VelocityLayoutServlet: you can't prevent a remote user from selecting
 the template because it's part of the servlet.

 So, before we jump to calling this an inherent security flaw.  What is
 your layout directory?

 What's *in* it? I have about 10 templates (header.vm, footer.vm,
 Default.vm, etc.) in there.

is !- in it

i'm just trying to figure out what your
tools.view.servlet.layout.directory setting is.

 What is your resource loader configuration?

 All defaults in development (where it's reproducible), and these
 settings in prod (which is also vulnerable):

 resource.loader=webapp
 webapp.resource.loader.class=org.apache.velocity.tools.view.servlet.WebappLoader
 webapp.resource.loader.cache=true
 webapp.resource.loader.path=/

 (I think those are roughly the defaults, anyway).

 The resource loaders really ought not be able to load any file either,
 otherwise the VelocityViewServlet itself becomes a risk, right?

 Perhaps this is only a problem if the webapp.resource.loader.path=/, but
 I believe that is the default configuration.

The point is merely that if the servlet is picking templates via url
path, how is that any more secure than picking a layout template via a
param.  Both are meant to be constrained to particular directories and
not allow general file access.  Those constraints ought to be coming
from the resource loader [configuration], not the servlet.

 It's fairly easy to try on your own webapp.at

not at the moment, tomorrow, maybe.


 -chris


-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: $hollow.message cannot be resolved

[Nathan Bubna]

You put your Hollow class under the key $toytool  (in the toolbox).
Why then does your template look for $Hollow.message instead of
$toytool.message?

On Thu, Dec 22, 2011 at 11:33 AM, SigmaSquared freddiej...@hotmail.com wrote:

 Velocity isnt picking up the class and the var in that class (i.e.
 hollow.message).
 I get the following error:
 Velocity  [debug] Null reference [template '/index.vm', line 16, column 28]
 : $Hollow.message cannot be resolved.

 message = 'asdf' in my java file.  What gives?



 I have the following directories:
 http://old.nabble.com/file/p33025653/Hollow.png

 These are my files:
 index.vm


 html
 body

 I'm a velocity template processed using the VelocityViewServlet.

 #if( $XHTML )
  #set( $br = br / )
 #else
  #set( $br = br )
 #end

 $br
 $br

 Here we use a custom tool: $hollow.message

 $br
 $br

 Lets count : #foreach($i in [1..5])$i #end

 $br
 $br

 Let's play with a hashmap:$br
 first add foo: $map.put(foo,$foo)$br
 then add bar: $map.put(bar,$bar)$br
 $br
 and that gives us $map

 $br
 $br

 Here we get the date from the DateTool:  $date.medium

 $br
 $br

 #if( $isSimple )
 This is simple#if( $XHTML ) xhtml#end app version ${version}.
 #end

 $br
 $br

 Click  index.jsp here  to see the VelocityViewTag handle the same VTL
 markup.

 /body
 /html

 Hollow.java



 public class Hollow {
   private String message = asdf;

   public String getMessage()
   {
     return message;
   }

  public void setMessage(String m)
  {
     message = m;
  }

  /** To test exception handling in templates. */
  public boolean whine() {
     throw new IllegalArgumentException();
  }

 }

 web.xml
 ?xml version=1.0 encoding=UTF-8?
 !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application
 2.2//EN http://java.sun.com/j2ee/dtds/web-app_2_2.dtd;

 !--
  Licensed to the Apache Software Foundation (ASF) under one
  or more contributor license agreements.  See the NOTICE file
  distributed with this work for additional information
  regarding copyright ownership.  The ASF licenses this file
  to you under the Apache License, Version 2.0 (the
  License); you may not use this file except in compliance
  with the License.  You may obtain a copy of the License at

   http://www.apache.org/licenses/LICENSE-2.0

  Unless required by applicable law or agreed to in writing,
  software distributed under the License is distributed on an
  AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
  KIND, either express or implied.  See the License for the
  specific language governing permissions and limitations
  under the License.
 --

 web-app
  servlet
    servlet-namevelocity/servlet-name

 servlet-classorg.apache.velocity.tools.view.VelocityViewServlet/servlet-class
  /servlet
  servlet-mapping
    servlet-namevelocity/servlet-name
    url-pattern*.vm/url-pattern
  /servlet-mapping
  welcome-file-list
    welcome-fileindex.vm/welcome-file
  /welcome-file-list
 /web-app


 tools.xml


 ?xml version=1.0?

 !--
  Licensed to the Apache Software Foundation (ASF) under one
  or more contributor license agreements.  See the NOTICE file
  distributed with this work for additional information
  regarding copyright ownership.  The ASF licenses this file
  to you under the Apache License, Version 2.0 (the
  License); you may not use this file except in compliance
  with the License.  You may obtain a copy of the License at

   http://www.apache.org/licenses/LICENSE-2.0

  Unless required by applicable law or agreed to in writing,
  software distributed under the License is distributed on an
  AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
  KIND, either express or implied.  See the License for the
  specific language governing permissions and limitations
  under the License.
 --

 tools
    data type=boolean key=xhtml value=true/
    data type=boolean key=isSimple value=true/
    data type=number key=version value=2.0/
    data key=foothis is foo/data
    data key=barthis is bar./data
    toolbox scope=request
        tool key=toytool class=Hollow restrictTo=index*/
    /toolbox
    toolbox scope=session
        tool key=map class=java.util.HashMap/
    /toolbox
 /tools





 --
 View this message in context: 
 http://old.nabble.com/%24hollow.message-cannot-be-resolved-tp33025653p33025653.html
 Sent from the Velocity - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org


-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: Problem with userdirective in velocity-1.7

[Nathan Bubna]

 I'm working on a servlets-based project that uses Velocity and I'm trying
 to upgrade from version 1.6.2 to 1.7.  Unfortunately, I can't figure out
 how to make the userdirective property work the way it did in 1.6.2.

weird.  i don't remember anything changing with that property.  will
you consider filing a bug report for someone to look into this?

 The servlets are all based on VelocityViewServlet and the directives are
 all LINE type (modeled very closely on the examples in the wiki).  My
 velocity.properties file contains the line:
        userdirective = com.whatever.FooDirective,com.whatever.BarDirective
 I've put debugging statements in the directives so I can see that the
 getName() function is being called once on startup.  After that, nothing.
  When my pages render, I see the #foo($something) code, not the rendered
 output.  getType() and render() are never called at all.

 I found one way around this -- at the top of my servlet's doRequest()
 function I can put a call like this:

  getVelocityView().getVelocityEngine().loadDirective(com.whatever.FooDirective);
 But using that call a dozen times for every page load seems like it will
 affect my site's performance.

don't do it per request.  directives need only be loaded per instance
of VelocityEngine.  do it once at the end of servlet init.

 This worked fine in 1.6.2; what am I doing wrong?

without a failing example to test, i don't really know.

 -- Sam Clippinger







 --
 Best Regards,
 Moatz Shawki

-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: Avoiding whitespace

[Nathan Bubna]

Gobbling mostly happens at the parser level right now.  This means
it's not extensible or configurable.  All you can do is modify the
parser and custom build Engine, modify the input (smart resource
loader), or modify the output (jTidy and friends).

http://wiki.apache.org/velocity/VelocityWhitespaceGobbling
https://issues.apache.org/jira/browse/VELOCITY-253

In my ideal world, the parser would treat the whitespace
preceding/following directives as a node type themselves or perhaps as
a distinct part of the directive nodes, allowing us full freedom to
configure whitespace behavior around directives.  (

In my optimistic world, i'd be perfectly happy for Engine 2.0 to
simply have a modified parser that gobbles more  predictably (i.e.
according to Christoph's very nice rules).

In my practical world, it would even be an improvement to just change
the parser to gobble nothing and leave whitespace management fully to
resource loaders or post-processors like jTidy.

But in reality, no one is doing any of this work, including myself.
Velocity is at the dreaded good enough point where no flaw is itchy
enough to inspire much hacking.  :(  But you could be the one! :)


On Wed, Nov 2, 2011 at 12:11 PM, Christopher Schultz
ch...@christopherschultz.net wrote:
 Nathan,

 On 10/31/11 11:45 AM, Nathan Bubna wrote:
 In that case, the documentation is wrong.  Leading whitespace is only
 trimmed from in front of a #set directive that has nothing after it.
 I'm not aware of any other case where leading whitespace is trimmed.

 Is this something that could be extended to directives other than #set?
 I just modified some of my XML-emitting templates to adjust whitespace
 and, especially in loops, tons of extra whitespace is generated. I ended
 up inserting VTL comments to get the job done and still have my
 directives indented properly (or I'd lose my sanity).

 Thanks,
 -chris



-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: Avoiding whitespace

[Nathan Bubna]

In that case, the documentation is wrong.  Leading whitespace is only
trimmed from in front of a #set directive that has nothing after it.
I'm not aware of any other case where leading whitespace is trimmed.

On Mon, Oct 31, 2011 at 7:29 AM, Christopher Schultz
ch...@christopherschultz.net wrote:
 All,

 The User Guide says that Velocity's behavior is to gobble-up excess
 whitespace and offers this example:

 Velocity's behaviour is to gobble up excess whitespace. The preceding
 directive can be written as:

 
 Send me
 #set( $foo = [$10 and ,a pie] )
 #foreach( $a in $foo )
 $a
 #end
 please.

 or as

 Send me
 #set($foo       = [$10 and ,a pie])
                 #foreach           ($a in $foo )$a
         #end please.

 In each case the output will be the same.
 

 I'm not observing this behavior. In my templates, the trailing
 whitespace after a directive on a line (usually just a newline) appears
 to be trimmed, but leading whitespace is preserved. So, the output from
 the second example looks like this:

 Send me
                 $10 and
         a pie
          please.

 (note the leading whitespace before $10 and, etc. which you may not be
 able to see if you are viewing this message in HTML mode).

 Am I missing some kind of configuration parameter? I don't appear to
 have anything in my configuration that has anything to do with whitespace.

 Is the documentation wrong? Or am I just mis-reading it?

 I know the issue of whitespace comes-up a lot, and I'm sorry to add to
 the never-ending discussion.

 Thanks,
 -chris



-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: Velocity to fetch full docs?

[Nathan Bubna]

Definitely for a question for the Nutch or Solr lists.  Velocity is a
simple template engine and knows nothing about Nutch or Solr that it
isn't told about.

On Mon, Sep 26, 2011 at 5:17 AM, Fred Zimmerman w...@nimblebooks.com wrote:
 Hi,

 I am using Nutch/Solr to index an intranet of about 12 million pages and
 when I do a search I want Solr to retrieve the full documents and append
 them into a single simple HTML doc (no js, not ads, etc.), then shoot the
 single doc to another (nonSolr) process for postprocessing.   Can I use
 Velocity to do this? How?  Can Velocity reach back to the Nutch crawl for
 the full text of the docs (they don't change often at all)?

 Any help would be much appreciated.


-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: Getting Velocity working with Google App Engine

[Nathan Bubna]

tools.xml is supported by the VelocityTools project.  make sure you
include a current VelocityTools jar.

On Sun, Sep 25, 2011 at 12:51 PM, Andrew Ducker and...@ducker.org.uk wrote:
 I'm plugging away at this, because I'd like to use Velocity for the
 templates in the app I'm working on.

 I've got part of the way there*, but seem to be having a problem with the
 tools.xml file.

 The pieces that don't depend on the tools.xml seem to work ok.  For
 instance,
 Lets count : #foreach($i in [1..5])$i #end
 comes out as
 Lets count : 1 2 3 4 5

 but if it tries to use any of the variable in the tools.xml then I get
 something like:
 This is simple app version ${version}.
 or
 Here we use a custom tool: $toytool.message

 Is there something I need to set to get it running with the tools.xml file?
  I've got it sitting in the WEB-INF folder, and it's a copy straight from
 the tutorial.

 Any ideas?

 Thanks,

 Andy


 *I had to add the following to the appengine-web.xml:
 static-files
    exclude path=/**.vm /
 /static-files
 and create an empty velocity.properties to the web-inf folder in order to
 not get exceptions or other oddness.

 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org



-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: Getting Velocity working with Google App Engine

[Nathan Bubna]

On Sun, Sep 25, 2011 at 3:08 PM, Andrew Ducker and...@ducker.org.uk wrote:
 On 25/09/2011 21:33, Nathan Bubna wrote:

 tools.xml is supported by the VelocityTools project.  make sure you
 include a current VelocityTools jar.

 I've got Velocity-tools-view-2.0.jar included.  I've also used the
 velocity-1.6.2.jar that was shipped with it.

 This being the case, is there any reason why it might not be picking up the
 tools.xml from the web-inf folder?

 Is this something that GAE does differently?

i'm not sure.  i've never used GAE with Velocity (nor much at all).
Is there a GAE forum where you can ask about it?  Have you tried
putting the tools.xml in the root of the classpath?

 Cheers,

 Andy




 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org



-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: Passing an object as a parameter to a method

[Nathan Bubna]

and it should be ${report.generate($null)} too, for that matter.  :)

On Tue, Sep 20, 2011 at 4:08 PM, Nathan Bubna nbu...@gmail.com wrote:
 ${report.generate($project.manager)}

 On Tue, Sep 20, 2011 at 4:07 PM, Alec Swan alecs...@gmail.com wrote:
 Hello,

 I am trying to get the following template to work:
 ${report.generate(project.manager)}

 I expect this template to call method Report#generate(User) and pass
 project.manager property (of type User) as a parameter.

 I tested that ${project.manager} returns correct result and that
 ${report.generate(null)} calls Report#generate(User) and throws an
 NPE. However, calling ${report.generate(project.manager)} results in a
 syntax error.

 Thanks,

 Alec

 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org




-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: Problems with #set($var = $x - $a.func($z))${var}

[Nathan Bubna]

what are the types of $x and $a.func($z) ?

subtraction only works on java.lang.Number (or primitive counterparts)
or objects that implement Velocity's TemplateNumber interface.

On Wed, Aug 24, 2011 at 12:33 PM, Alec Swan alecs...@gmail.com wrote:
 Hello,

 I am having problems with getting the following expression to work correctly:
 #set($var = $x - $a.func($z))${var}

 Note that the following expressions work properly:
 #set($var = $x)${var}
 #set($var = $a.func($z))${var}

 However, subtraction does not seem to return the expected result.

 Thanks,

 Alec

 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org



-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: Problems with #set($var = $x - $a.func($z))${var}

[Nathan Bubna]

No, but there's plenty of ways to convert it.  Jonathan's
$Integer.parse($x) is simple.  VelocityTools has a ConversionTool or
MathTool that both can handle the conversion.  Or you can just use the
MathTool to do the subtraction and it will automatically convert
strings or other objects.

On Wed, Aug 24, 2011 at 12:51 PM, Alec Swan alecs...@gmail.com wrote:
 Ah, looks like $x type is a string even though it represents a number.
  Is there any type casting in Velocity?

 On Wed, Aug 24, 2011 at 1:46 PM, Nathan Bubna nbu...@gmail.com wrote:
 what are the types of $x and $a.func($z) ?

 subtraction only works on java.lang.Number (or primitive counterparts)
 or objects that implement Velocity's TemplateNumber interface.

 On Wed, Aug 24, 2011 at 12:33 PM, Alec Swan alecs...@gmail.com wrote:
 Hello,

 I am having problems with getting the following expression to work 
 correctly:
 #set($var = $x - $a.func($z))${var}

 Note that the following expressions work properly:
 #set($var = $x)${var}
 #set($var = $a.func($z))${var}

 However, subtraction does not seem to return the expected result.

 Thanks,

 Alec

 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org



 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org



 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org



-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: Evaluating basic expression

[Nathan Bubna]

Velocity is not a scripting language; it's a template engine.  It
doesn't have standalone expressions like that.  It has references and
directives, some directives handle expressions in the arguments.  Some
references handle expressions as arguments to method calls.

That said, even if you put ${var + 5} into a proper place for an
expression, then you would have problems because the ${} syntax is the
formal bounds for a reference, not an expression.  Try something like
this instead:

#set( $val = $var + 5)${val}

On Tue, Aug 16, 2011 at 10:15 AM, Alec Swan alecs...@gmail.com wrote:
 Hello,

 I am puzzled why evaluating ${var + 5} with var-1 bindings does not
 produce 6? Here is some sample code:

 Velocity.evaluate(new VelocityContext(Collections.singletonMap(var,
 1)), writer, getClass().getSimpleName(), ${var + 5})

 Thanks,

 Alec

 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org



-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: [tools] StrutsLinkTool's setForward method has different behavior

[Nathan Bubna]

Wow.  Slow down.  I already fixed VELTOOLS-146.  You need to svn
update your code.

On Thu, Jul 28, 2011 at 10:00 AM, Christopher Schultz
ch...@christopherschultz.net wrote:
 All,

 On 7/28/2011 12:48 PM, Christopher Schultz wrote:
 I think the solution is to modify this so that
 generic.LinkTool.absolute() /does/ use the URI class to parse the URI
 and separate-out the query string, etc. and then set them on the copied
 LinkTool's instance.

 Okay, this works, but I'm not sure if it's the best solution, or if it's
 even a complete solution. StrutsLinkTool calls LinkTool.absolute(), but
 the path is actually a relative path, so maybe calling
 LinkTool.relative() is a better thing to do. In that case, the fix
 should probably be different.

 Quick diff for generic.LinkTool:


 Index: src/main/java/org/apache/velocity/tools/generic/LinkTool.java
 ===
 --- src/main/java/org/apache/velocity/tools/generic/LinkTool.java
 (revision 1151249)
 +++ src/main/java/org/apache/velocity/tools/generic/LinkTool.java
 (working copy)
 @@ -1357,6 +1357,7 @@
                 {
                     return null;
                 }
 +
                 copy.setScheme(uri.getScheme());
                 copy.setUserInfo(uri.getUserInfo());
                 copy.setHost(uri.getHost());
 @@ -1378,8 +1379,30 @@
                 }
                 return copy;
             }
 -            else if (!pth.startsWith(/))
 +            else if (pth.startsWith(/))
             {
 +                // This is a relative path, not absolute.
 +                // That's okay -- parse the URI anyway but don't process
 +                // the host, scheme, port, user, etc.
 +                URI uri = toURI(pth);
 +
 +                pth = uri.getPath();
 +                if (pth.equals(/) || pth.length() == 0)
 +                {
 +                    pth = null;
 +                }
 +                copy.setPath(pth);
 +                if (uri.getQuery() != null)
 +                {
 +                    copy.setQuery(uri.getQuery());
 +                }
 +                if (uri.getFragment() != null)
 +                {
 +                    copy.setFragment(uri.getFragment());
 +                }
 +            }
 +            else
 +            {
                 // paths that don't start with '/'
                 // are considered relative to the current directory
                 pth = combinePath(getDirectory(), pth);



-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: [tools] StrutsLinkTool's setForward method has different behavior

[Nathan Bubna]

Also, these discussions REALLY need to happen on dev@.  user@ is not
the right place.

On Thu, Jul 28, 2011 at 10:20 AM, Nathan Bubna nbu...@gmail.com wrote:
 Wow.  Slow down.  I already fixed VELTOOLS-146.  You need to svn
 update your code.

 On Thu, Jul 28, 2011 at 10:00 AM, Christopher Schultz
 ch...@christopherschultz.net wrote:
 All,

 On 7/28/2011 12:48 PM, Christopher Schultz wrote:
 I think the solution is to modify this so that
 generic.LinkTool.absolute() /does/ use the URI class to parse the URI
 and separate-out the query string, etc. and then set them on the copied
 LinkTool's instance.

 Okay, this works, but I'm not sure if it's the best solution, or if it's
 even a complete solution. StrutsLinkTool calls LinkTool.absolute(), but
 the path is actually a relative path, so maybe calling
 LinkTool.relative() is a better thing to do. In that case, the fix
 should probably be different.

 Quick diff for generic.LinkTool:


 Index: src/main/java/org/apache/velocity/tools/generic/LinkTool.java
 ===
 --- src/main/java/org/apache/velocity/tools/generic/LinkTool.java
 (revision 1151249)
 +++ src/main/java/org/apache/velocity/tools/generic/LinkTool.java
 (working copy)
 @@ -1357,6 +1357,7 @@
                 {
                     return null;
                 }
 +
                 copy.setScheme(uri.getScheme());
                 copy.setUserInfo(uri.getUserInfo());
                 copy.setHost(uri.getHost());
 @@ -1378,8 +1379,30 @@
                 }
                 return copy;
             }
 -            else if (!pth.startsWith(/))
 +            else if (pth.startsWith(/))
             {
 +                // This is a relative path, not absolute.
 +                // That's okay -- parse the URI anyway but don't process
 +                // the host, scheme, port, user, etc.
 +                URI uri = toURI(pth);
 +
 +                pth = uri.getPath();
 +                if (pth.equals(/) || pth.length() == 0)
 +                {
 +                    pth = null;
 +                }
 +                copy.setPath(pth);
 +                if (uri.getQuery() != null)
 +                {
 +                    copy.setQuery(uri.getQuery());
 +                }
 +                if (uri.getFragment() != null)
 +                {
 +                    copy.setFragment(uri.getFragment());
 +                }
 +            }
 +            else
 +            {
                 // paths that don't start with '/'
                 // are considered relative to the current directory
                 pth = combinePath(getDirectory(), pth);




-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: [tools] StrutsLinkTool's setForward method has different behavior

[Nathan Bubna]

On Wed, Jul 27, 2011 at 7:32 AM,  ch...@christopherschultz.net wrote:
...
 Basically, setForward
 passes the url to absolute(url) which would correctly handle absolute
 urls with query strings but treats relative urls as merely paths,
 without parsing out anchors or query strings.

 Okay, I'll take a look at this.

 I think we should adapt both $link.relative($url) and
 $link.absolute($url) to accept paths with query strings and anchors.

 That would be great. I dunno about anchors, but query strings used to work
 -- at least with SLT's setForward().

anchors should be allowed too.

 This probably will require a setFromURI(url, withoutOverriding)
 adapted from what absolute($url) does for actual absolute URIs.

 So withoutOverriding really means don't escape?

no, it means that after you turn the url into a java.net.URI (which
does the parsing for you) and you are copying out the sections of the
URI into the current LinkTool instance, you don't want to override
things in the currents LinkTool that are absent in the URI.  If the
URI has no scheme, don't set the LinkTool to have a null scheme, and
so on.

 In the meantime, try this:

 context.put(java.net.URLDecoder.class, url);

 $url.decode($link.setForward('some-reference'))

 That's not going to work because we also add more query string data to the
 link after the setForward() call. (I simplified my original example).

As long as your query string data doesn't have anything encoded that
you don't want decoded, then add the params before decoding and don't
worry about it.

 LinkTool would be most flexible if it would parse any existing query string
 into it's own parameter table OR be sensitive about an existing query string
 and add anything to is as appropriate (this would probably be best, unless
 there are methods in LinkTool that expect to be able to /replace/
 previously-set query string parameters).

The method of upgrading relative(url) and absolute(url) that i
describe above will parse and add params to the internal map, because
yes, there are methods that expect to be able to replace parameters.

 Or extend StrutsLinkTool to do that for you.

 I think I'll try to hack SLT to work for me temporarily with an eye towards
 a longer-term solution that actually gets committed to VELTOOLS. I need to
 get this working so I can continue to use VELTOOLS-2.0... otherwise I'll
 have to roll-back to 1.4.

Please don't. :)

-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: LinkTool.addRequestParams is difficult to use due to varargs/String[] parameter

[Nathan Bubna]

On Wed, Jul 27, 2011 at 11:59 AM, Christopher Schultz
ch...@christopherschultz.net wrote:
 All,

 I've been trying to switch my templates from using
 LinkTool.addIgnore()addAllParameters() to use
 LinkTool.addRequestParamsExcept(String... allButThese) but I'm having a
 bit of difficulty with it.

 If I call addRequestParams() with no argument, things work as expect. On
 the other hand, this does not work:

 #set($ignoreList = ['foo'])
 $link.relative('/bar').addRequestParamsExcept($ignoreList)

 I get an invalid reference log message and the above $link... text is
 rendered as written instead of evaluating successfully.

 Without much investigation, I believe the problem is that the ignoreList
 is a List and it needs to be String[]. Velocity will auto-convert Lists
 into Object[] if appropriate, but I suspect that the resulting object
 type is Object[] and not, say, String[].

i believe you're right.

 There does not appear to be a way to create a String[] from a Velocity
 template, so using addRequestParams and the other, similar methods will
 be very difficult to use with an argument.

why not just do $link.addRequestParamsExcept('foo', 'bar', 'etc')?

 If anyone has any suggestions for how to use these methods with
 template-supplied data, I'd love to hear them. Otherwise, I'm inclined
 to either overload or modify these methods to accept an Object[]
 parameter and throw an exception if the array elements are not String
 objects.

i think that would be a good enhancement regardless.  i don't
particularly like templates and tools being picky about types when
they don't have to be.

-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: [tools] LinkTool.addAllParameters is not behaving as before

[Nathan Bubna]

On Tue, Jul 26, 2011 at 2:59 PM, Christopher Schultz
ch...@christopherschultz.net wrote:
 All,

 On 7/26/2011 5:23 PM, Christopher Schultz wrote:
 As I get further into the testing of Velocity Tools 2.0, I'm finding
 that the addAllParameters method isn't working as it used to.

 Given:

 #set($forward = $link.relative('/foo'))

 WORKS: \$forward=$forward
 WORKS: \$forward.addAllParameters()=$forward.addAllParameters()
 WORKS:
 \$link.setRelative('/foo').addAllParameters()=$link.setRelative('/foo').addAllParameters()

 Given:

 #set($forward = $link.relative('/foo').addQueryData('token', 'xyz'))

 (Note the added addQueryData call)

 FAILS: \$forward=$forward
 FAILS: \$forward.addAllParameters()=$forward.addAllParameters()

 Any ideas?

No, addQueryData in the deprecated version just forwards to
append(Object,Object) in the generic version, and both clearly return
the fresh copy of the LinkTool.  So, i see no reason for those
references to fully fail unless an exception is being thrown that you
are suppressing with an event handler.  Anything in the logs?

 I don't know why using a temporary reference would have any bearing on
 the behavior. Perhaps I'm stumbling into something else and drawing the
 wrong conclusion.

 Thanks,
 -chris



-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: Velocity Tools 2.0 README has incorrect build instructions

[Nathan Bubna]

On Thu, Jul 21, 2011 at 9:44 AM, Christopher Schultz
ch...@christopherschultz.net wrote:
...
 All important changes not linked to the build system change have been
 backported to the branch. Feel free to commit in it, we'll forward-post
 changes if needed.

 Great. I have created an enhancement bug this morning in JIRA and I can
 either attach my patch and wait for comment, or simply commit to the
 2.0.0 branch and wait for any objections.

 Which would be best?

you are a committer.  you should commit. :)  if you have hesitations
or desire discussion about a change before you commit it, we have
d...@velocity.apache.org ready and waiting.

 Also, this change is applicable in both trunk and 2.0.0, so shall I
 commit both places, or commit to 2.0.0 and wait for someone else to
 post-forward?

if you believe the change is useful in both the trunk 2.x and the
branch 2.0.x, then commit it to both.


 I'm happy to do either.

or both? :)


 Thanks,
 -chris




-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: Velocity Tools 2.0 README has incorrect build instructions

[Nathan Bubna]

On Thu, Jul 21, 2011 at 10:06 AM, Christopher Schultz
ch...@christopherschultz.net wrote:
 Nathan,

 On 7/21/2011 12:54 PM, Nathan Bubna wrote:
 On Thu, Jul 21, 2011 at 9:44 AM, Christopher Schultz
 ch...@christopherschultz.net wrote:
 ...
 All important changes not linked to the build system change have been
 backported to the branch. Feel free to commit in it, we'll forward-post
 changes if needed.

 Great. I have created an enhancement bug this morning in JIRA and I can
 either attach my patch and wait for comment, or simply commit to the
 2.0.0 branch and wait for any objections.

 Which would be best?

 you are a committer.  you should commit. :)  if you have hesitations
 or desire discussion about a change before you commit it, we have
 d...@velocity.apache.org ready and waiting.

 Tomcat has a somewhat more formal review-than-commit process for
 previously-released versions (the TC5 and TC6 releases, for instance)
 but a commit-then-review process for TC7 where most of the new
 development is going. I just didn't want to commit out of turn :)

thanks for checking, but yeah most ASF projects are not as formal as
Tomcat, especially ones like Velocity where the number of active
developers is relatively small and x.x.y releases for past x.x
versions are unusual.

 I'll go ahead and commit everywhere.

 Thanks,
 -chris



-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: Trouble finding velocity.properties in a jar

[Nathan Bubna]

I would do two things (the first of which, you have probably done).
1) double-check that the build process for the JAR is correctly
putting the velocity.properties file into the root of the jar and that
the jar is in the classpath  2) try finding it elsewhere in the
classloader heirarchy:

InputStream stream =
Thread.currentThread().getContextClassLoader().getResourceAsStream(velocity.properties);
if (stream == null) {
  stream = 
ThisClass.class.getClassLoader().getResourceAsStream(velocity.properties);
  if (stream == null) {
  stream = ThisClass.class.getResourceAsStream(velocity.properties);
  if (stream == null) {
 throw new RuntimeException(WTF?  i'm not sure the resource
is really there.);
  }
  }
}

On Thu, Jul 21, 2011 at 9:37 AM, laredotornado laredotorn...@gmail.com wrote:

 Hi,

 I'm using Java 1.6, Velocity 1.6.2.  I have a Maven JAR project, in which
 the velocity.properties gets packaged at the root of the JAR.  When I
 include this JAR in other projects, I'm not able to initialize velocity,
 using ...

                VelocityEngine ve = new VelocityEngine();
                final InputStream resourceStream =
 Thread.currentThread().getContextClassLoader().getResourceAsStream(velocity.properties);
                final Properties velocityProps = new Properties();
                velocityProps.load(resourceStream);
                ve.init( velocityProps );

 The above dies because the resourceStream is null.  Any ideas how I
 reference this file?  Keep in mind that it is packaged within the JAR.
 Thanks, - Dave
 --
 View this message in context: 
 http://old.nabble.com/Trouble-finding-velocity.properties-in-a-jar-tp32108932p32108932.html
 Sent from the Velocity - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
 For additional commands, e-mail: user-h...@velocity.apache.org



-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org

Re: Velocity Tools 2.0 README has incorrect build instructions

[Nathan Bubna]

On Thu, Jul 21, 2011 at 10:25 AM, Christopher Schultz
ch...@christopherschultz.net wrote:
 Nathan,

 On 7/21/2011 1:06 PM, Christopher Schultz wrote:
 I'll go ahead and commit everywhere.

 Hmm... I'm having trouble building trunk. That could be due to a number
 of environmental factors including wrong maven version (I grabbed
 3.0.3), wrong maven use (I tried mvn compile), or missing local
 settings (no local Velocity 2.0 build), etc.

checkout/update https://svn.apache.org/repos/asf/velocity/maven/trunk/pom
run mvn install for that project
checkout/update the engine trunk
run mvn install for that project
checkout/update the tools trunk
run mvn install for that project

 My patch builds and tests cleanly on 2.0.x and has been committed.

:)

 I can simply commit a similar patch to trunk (only difference is path
 names) and let someone verify it works. I'm reasonably confident that
 everything will be fine, and I'm guessing that VELOTOOLS-2.1 is quite a
 ways off so I won't be ruining some schedule if some small thing is out
 of order.

agreed.  however, it would be very good for you to be able to build the trunk.

 Shall I commit or let someone else forward-port my change? The patch was
 a completely new method in DateTool and a completely new DateToolTest file.

always better to test if you can.  but if you can't i promise to test
right after you commit, just so i don't have to mess with patches in
JIRA.  i pushed for you to be a committer in large part because i was
tired of committing your patches, remember? :)

 -chris



-
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org