headers
Antonio Petrelli | 1 Feb 09:36
Picon

Re: [TOOLS] Trouble building 2.0.x

2012/2/1 Christopher Schultz <chris <at> christopherschultz.net>

> Antonio,
>
> On 1/31/12 6:11 PM, Christopher Schultz wrote:
> > No problem: just check it out from svn (done) and build:
>
> I forgot to mention that I downloaded the Velocity 1.7 tag. I wasn't
> sure if trunk would be a good idea in this case.
>

The problem is that Tools 2.1.0-SNAPSHOT depends on Velocity
2.0.0-SNAPSHOT, that depends on velocity-master 1-SNAPSHOT.
IOW, everything is ready to use Maven as the main builder for the next
iteration, so you have to build everything at once or nothing at all.

Antonio
Permalink | Reply | 3 comments |
headers
Christopher Schultz | 1 Feb 20:29

Re: [TOOLS] Trouble building 2.0.x

Antonio,

On 2/1/12 3:36 AM, Antonio Petrelli wrote:
> 2012/2/1 Christopher Schultz <chris <at> christopherschultz.net>
> 
>> Antonio,
>>
>> On 1/31/12 6:11 PM, Christopher Schultz wrote:
>>> No problem: just check it out from svn (done) and build:
>>
>> I forgot to mention that I downloaded the Velocity 1.7 tag. I wasn't
>> sure if trunk would be a good idea in this case.
>>
> 
> The problem is that Tools 2.1.0-SNAPSHOT depends on Velocity
> 2.0.0-SNAPSHOT, that depends on velocity-master 1-SNAPSHOT.
> IOW, everything is ready to use Maven as the main builder for the next
> iteration, so you have to build everything at once or nothing at all.

So, if I want to work on Tools, I need to use tools/trunk, and
velocity/trunk. Back-porting is going to be a big mess :(

-chris
Permalink | Reply | 2 comments |
headers
Antonio Petrelli | 2 Feb 09:19
Picon

Re: [TOOLS] Trouble building 2.0.x

2012/2/1 Christopher Schultz <chris <at> christopherschultz.net>

> Antonio,
>
> On 2/1/12 3:36 AM, Antonio Petrelli wrote:
> > 2012/2/1 Christopher Schultz <chris <at> christopherschultz.net>
> >
> >> Antonio,
> >>
> >> On 1/31/12 6:11 PM, Christopher Schultz wrote:
> >>> No problem: just check it out from svn (done) and build:
> >>
> >> I forgot to mention that I downloaded the Velocity 1.7 tag. I wasn't
> >> sure if trunk would be a good idea in this case.
> >>
> >
> > The problem is that Tools 2.1.0-SNAPSHOT depends on Velocity
> > 2.0.0-SNAPSHOT, that depends on velocity-master 1-SNAPSHOT.
> > IOW, everything is ready to use Maven as the main builder for the next
> > iteration, so you have to build everything at once or nothing at all.
>
> So, if I want to work on Tools, I need to use tools/trunk, and
> velocity/trunk. Back-porting is going to be a big mess :(
>

The question is: is backporting necessary?

Antonio
Permalink | Reply | 1 comment |
headers
Christopher Schultz | 2 Feb 16:39

Re: [TOOLS] Trouble building 2.0.x

Antonio,

On 2/2/12 3:19 AM, Antonio Petrelli wrote:
> 2012/2/1 Christopher Schultz <chris <at> christopherschultz.net>
> 
>> Antonio,
>>
>> On 2/1/12 3:36 AM, Antonio Petrelli wrote:
>>> 2012/2/1 Christopher Schultz <chris <at> christopherschultz.net>
>>>
>>>> Antonio,
>>>>
>>>> On 1/31/12 6:11 PM, Christopher Schultz wrote:
>>>>> No problem: just check it out from svn (done) and build:
>>>>
>>>> I forgot to mention that I downloaded the Velocity 1.7 tag. I wasn't
>>>> sure if trunk would be a good idea in this case.
>>>>
>>>
>>> The problem is that Tools 2.1.0-SNAPSHOT depends on Velocity
>>> 2.0.0-SNAPSHOT, that depends on velocity-master 1-SNAPSHOT.
>>> IOW, everything is ready to use Maven as the main builder for the next
>>> iteration, so you have to build everything at once or nothing at all.
>>
>> So, if I want to work on Tools, I need to use tools/trunk, and
>> velocity/trunk. Back-porting is going to be a big mess :(
>>
> 
> The question is: is backporting necessary?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chad La Joie | 4 Feb 16:58

Most efficient evaluation

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.

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

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

Thanks.

--

-- 
Chad La Joie
www.itumi.biz
trusted identities, delivered
Permalink | Reply | 1 comment |
headers
Nathan Bubna | 4 Feb 17:44
Picon

Re: Most efficient evaluation

On Sat, Feb 4, 2012 at 7:58 AM, Chad La Joie <lajoie <at> 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
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chad La Joie | 6 Feb 13:17

Validate templates before use

Is there a way to "validate" a template prior to using it?  I'd like
to check that some user supplied templates are, at least, parsable
during system startup.

Thanks.

--

-- 
Chad La Joie
www.itumi.biz
trusted identities, delivered
Permalink | Reply | 7 comments |
headers
sebb | 6 Feb 15:41
Picon

Re: Validate templates before use

On 6 February 2012 12:17, Chad La Joie <lajoie <at> itumi.biz> wrote:
> Is there a way to "validate" a template prior to using it?  I'd like
> to check that some user supplied templates are, at least, parsable
> during system startup.

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.

But perhaps I'm missing something here, and you have some other way of
protecting against valid (but faulty or malicious) templates.

> Thanks.
>
> --
> Chad La Joie
> www.itumi.biz
> trusted identities, delivered
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe <at> velocity.apache.org
> For additional commands, e-mail: user-help <at> velocity.apache.org
>
Permalink | Reply | 6 comments |
headers
Chad La Joie | 6 Feb 15:44

Re: Validate templates before use

On Mon, Feb 6, 2012 at 09:41, sebb <sebbaz <at> 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.

--

-- 
Chad La Joie
www.itumi.biz
trusted identities, delivered
Permalink | Reply | 5 comments |
headers
Guillaume Polet | 6 Feb 15:58
Picon

Re: Validate templates before use

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, sebb<sebbaz <at> 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
(Continue reading)

Permalink | Reply | 4 comments |

Gmane