You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Veit Guna <ve...@gmx.de> on 2017/12/05 22:46:00 UTC
Setting context value from template broken in 2.0
Hi.
I just gave 2.0 a testdrive and some issues occurred to me.
a) Until 1.7 I could use
#set($subject = "Hey Buddy")
To pass back context values to the caller (java code). I could simply
get it from the Map:
contextMap.get("subject");
Now this doesn't work anymore. The key is not contained in the context
after the template has been processed.
Is this by intention? Is there another way of passing back values from
the template?
b) org.springframework.ui.velocity.VelocityEngineFactoryBean doesn't
work anymore if configured like this:
<property name="resourceLoaderPath" value="classpath:mail-templates" />
or this (leaving it out completely results in the same):
<property name="overrideLogging" value="true" />
Spring uses an old ResourceLoader for classpath scanning (can be fixed
by using velocitys own). Also it uses
the old *Chute logger class. Both resulting in appropriate exceptions
not finding matching classes.
As Spring announced to drop Velocity Support with 5, this is maybe not a
topic for you guys anymore.
But it would have been nice to keep these classes for a while to not
break existing projects :).
So let's forget about b). Does anyone has a clue about a)?
Cheers
Veit
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
Re: Setting context value from template broken in 2.0
Posted by Claude Brisson <cl...@renegat.net.INVALID>.
On 05/12/2017 23:46, Veit Guna wrote:
> Hi.
>
> I just gave 2.0 a testdrive and some issues occurred to me.
>
> a) Until 1.7 I could use
>
> #set($subject = "Hey Buddy")
>
> To pass back context values to the caller (java code). I could simply
> get it from the Map:
>
> contextMap.get("subject");
>
> Now this doesn't work anymore. The key is not contained in the context
> after the template has been processed.
> Is this by intention? Is there another way of passing back values from
> the template?
It does work with this following code:
VelocityContext context = new VelocityContext();
template.merge(context, output);
/* template contains #set($suject = "hello there") */
System.out.println("subject = " + context.get("subject"));
Ok, I saw your second email. Well, anyhow, the behavior should still be
the same.
Note that you can turn it off with:
template.provide.scope.control = true
> b) org.springframework.ui.velocity.VelocityEngineFactoryBean doesn't
> work anymore if configured like this:
>
> <property name="resourceLoaderPath" value="classpath:mail-templates" />
>
> or this (leaving it out completely results in the same):
>
> <property name="overrideLogging" value="true" />
>
> Spring uses an old ResourceLoader for classpath scanning (can be fixed
> by using velocitys own). Also it uses
> the old *Chute logger class. Both resulting in appropriate exceptions
> not finding matching classes.
>
> As Spring announced to drop Velocity Support with 5, this is maybe not a
> topic for you guys anymore.
On the contrary, they just don't want to maintain the Velocity
integration themselves, which means we should host the few glue classes
here. Adapting the org.springframework.ui.velocity pakage for 2.0 should
be trivial, we're just waiting for someone to contribute it.
Regards,
Claude
> But it would have been nice to keep these classes for a while to not
> break existing projects :).
>
> So let's forget about b). Does anyone has a clue about a)?
>
> Cheers
> Veit
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> For additional commands, e-mail: user-help@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
Re: Setting context value from template broken in 2.0
Posted by Veit Guna <ve...@gmx.de>.
Hi Claude.
Thanks for taking you time looking into this!
Meanwhile I figured out what the problem was. I switched to the Velocity Classpath Resource Loader
but forgot to specify the path to my templates (that were configured via Spring before).
So it couldn't find the templates at all but I didn't propagate that error properly. So also nothing
in the context :). So case closed. Thanks!
Good idea @ providing the Spring glue from your side!
Cheers
Veit
Am 06.12.2017 um 12:45 schrieb Claude Brisson:
> On 05/12/2017 23:46, Veit Guna wrote:
>
>> Hi.
>>
>> I just gave 2.0 a testdrive and some issues occurred to me.
>>
>> a) Until 1.7 I could use
>>
>> #set($subject = "Hey Buddy")
>>
>> To pass back context values to the caller (java code). I could simply
>> get it from the Map:
>>
>> contextMap.get("subject");
>>
>> Now this doesn't work anymore. The key is not contained in the context
>> after the template has been processed.
>> Is this by intention? Is there another way of passing back values from
>> the template?
>
> It does work with this following code:
>
> VelocityContext context = new VelocityContext();
> template.merge(context, output);
> /* template contains #set($suject = "hello there") */
> System.out.println("subject = " + context.get("subject"));
>
> Ok, I saw your second email. Well, anyhow, the behavior should still
> be the same.
> Note that you can turn it off with:
>
> template.provide.scope.control = true
>
>> b) org.springframework.ui.velocity.VelocityEngineFactoryBean doesn't
>> work anymore if configured like this:
>>
>> <property name="resourceLoaderPath" value="classpath:mail-templates" />
>>
>> or this (leaving it out completely results in the same):
>>
>> <property name="overrideLogging" value="true" />
>>
>> Spring uses an old ResourceLoader for classpath scanning (can be fixed
>> by using velocitys own). Also it uses
>> the old *Chute logger class. Both resulting in appropriate exceptions
>> not finding matching classes.
>>
>> As Spring announced to drop Velocity Support with 5, this is maybe not a
>> topic for you guys anymore.
>
> On the contrary, they just don't want to maintain the Velocity
> integration themselves, which means we should host the few glue
> classes here. Adapting the org.springframework.ui.velocity pakage for
> 2.0 should be trivial, we're just waiting for someone to contribute it.
>
> Regards,
>
> Claude
>
>> But it would have been nice to keep these classes for a while to not
>> break existing projects .
>>
>> So let's forget about b). Does anyone has a clue about a)?
>>
>> Cheers
>> Veit
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
>> For additional commands, e-mail: user-help@velocity.apache.org
>>
>>
>
> On 05/12/2017 23:46, Veit Guna wrote:
>> Hi.
>>
>> I just gave 2.0 a testdrive and some issues occurred to me.
>>
>> a) Until 1.7 I could use
>>
>> #set($subject = "Hey Buddy")
>>
>> To pass back context values to the caller (java code). I could simply
>> get it from the Map:
>>
>> contextMap.get("subject");
>>
>> Now this doesn't work anymore. The key is not contained in the context
>> after the template has been processed.
>> Is this by intention? Is there another way of passing back values from
>> the template?
>>
>> b) org.springframework.ui.velocity.VelocityEngineFactoryBean doesn't
>> work anymore if configured like this:
>>
>> <property name="resourceLoaderPath" value="classpath:mail-templates" />
>>
>> or this (leaving it out completely results in the same):
>>
>> <property name="overrideLogging" value="true" />
>>
>> Spring uses an old ResourceLoader for classpath scanning (can be fixed
>> by using velocitys own). Also it uses
>> the old *Chute logger class. Both resulting in appropriate exceptions
>> not finding matching classes.
>>
>> As Spring announced to drop Velocity Support with 5, this is maybe not a
>> topic for you guys anymore.
>> But it would have been nice to keep these classes for a while to not
>> break existing projects :).
>>
>> So let's forget about b). Does anyone has a clue about a)?
>>
>> Cheers
>> Veit
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
>> For additional commands, e-mail: user-help@velocity.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
Re: Setting context value from template broken in 2.0
Posted by Claude Brisson <cl...@renegat.net.INVALID>.
On 05/12/2017 23:46, Veit Guna wrote:
> Hi.
>
> I just gave 2.0 a testdrive and some issues occurred to me.
>
> a) Until 1.7 I could use
>
> #set($subject = "Hey Buddy")
>
> To pass back context values to the caller (java code). I could simply
> get it from the Map:
>
> contextMap.get("subject");
>
> Now this doesn't work anymore. The key is not contained in the context
> after the template has been processed.
> Is this by intention? Is there another way of passing back values from
> the template?
It does work with this following code:
VelocityContext context = new VelocityContext();
template.merge(context, output);
/* template contains #set($suject = "hello there") */
System.out.println("subject = " + context.get("subject"));
Ok, I saw your second email. Well, anyhow, the behavior should still be
the same.
Note that you can turn it off with:
template.provide.scope.control = true
> b) org.springframework.ui.velocity.VelocityEngineFactoryBean doesn't
> work anymore if configured like this:
>
> <property name="resourceLoaderPath" value="classpath:mail-templates" />
>
> or this (leaving it out completely results in the same):
>
> <property name="overrideLogging" value="true" />
>
> Spring uses an old ResourceLoader for classpath scanning (can be fixed
> by using velocitys own). Also it uses
> the old *Chute logger class. Both resulting in appropriate exceptions
> not finding matching classes.
>
> As Spring announced to drop Velocity Support with 5, this is maybe not a
> topic for you guys anymore.
On the contrary, they just don't want to maintain the Velocity
integration themselves, which means we should host the few glue classes
here. Adapting the org.springframework.ui.velocity pakage for 2.0 should
be trivial, we're just waiting for someone to contribute it.
Regards,
Claude
> But it would have been nice to keep these classes for a while to not
> break existing projects .
>
> So let's forget about b). Does anyone has a clue about a)?
>
> Cheers
> Veit
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> For additional commands, e-mail: user-help@velocity.apache.org
>
>
On 05/12/2017 23:46, Veit Guna wrote:
> Hi.
>
> I just gave 2.0 a testdrive and some issues occurred to me.
>
> a) Until 1.7 I could use
>
> #set($subject = "Hey Buddy")
>
> To pass back context values to the caller (java code). I could simply
> get it from the Map:
>
> contextMap.get("subject");
>
> Now this doesn't work anymore. The key is not contained in the context
> after the template has been processed.
> Is this by intention? Is there another way of passing back values from
> the template?
>
> b) org.springframework.ui.velocity.VelocityEngineFactoryBean doesn't
> work anymore if configured like this:
>
> <property name="resourceLoaderPath" value="classpath:mail-templates" />
>
> or this (leaving it out completely results in the same):
>
> <property name="overrideLogging" value="true" />
>
> Spring uses an old ResourceLoader for classpath scanning (can be fixed
> by using velocitys own). Also it uses
> the old *Chute logger class. Both resulting in appropriate exceptions
> not finding matching classes.
>
> As Spring announced to drop Velocity Support with 5, this is maybe not a
> topic for you guys anymore.
> But it would have been nice to keep these classes for a while to not
> break existing projects :).
>
> So let's forget about b). Does anyone has a clue about a)?
>
> Cheers
> Veit
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> For additional commands, e-mail: user-help@velocity.apache.org
>
>
Re: Setting context value from template broken in 2.0
Posted by Veit Guna <ve...@gmx.de>.
Ok, It looks like it even can't find the template - but isn't
complaining. So something seems wrongly configured with the locator path.
Please ignore the #set issue described below for now. I'll have to check
the classpath loader in more detail...
Sorry for any inconvenience :).
Cheers
Veit
Am 05.12.2017 um 23:46 schrieb Veit Guna:
> Hi.
>
> I just gave 2.0 a testdrive and some issues occurred to me.
>
> a) Until 1.7 I could use
>
> #set($subject = "Hey Buddy")
>
> To pass back context values to the caller (java code). I could simply
> get it from the Map:
>
> contextMap.get("subject");
>
> Now this doesn't work anymore. The key is not contained in the context
> after the template has been processed.
> Is this by intention? Is there another way of passing back values from
> the template?
>
> b) org.springframework.ui.velocity.VelocityEngineFactoryBean doesn't
> work anymore if configured like this:
>
> <property name="resourceLoaderPath" value="classpath:mail-templates" />
>
> or this (leaving it out completely results in the same):
>
> <property name="overrideLogging" value="true" />
>
> Spring uses an old ResourceLoader for classpath scanning (can be fixed
> by using velocitys own). Also it uses
> the old *Chute logger class. Both resulting in appropriate exceptions
> not finding matching classes.
>
> As Spring announced to drop Velocity Support with 5, this is maybe not a
> topic for you guys anymore.
> But it would have been nice to keep these classes for a while to not
> break existing projects :).
>
> So let's forget about b). Does anyone has a clue about a)?
>
> Cheers
> Veit
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> For additional commands, e-mail: user-help@velocity.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org