headers
Georg Kallidis (Commented) (JIRA | 1 Feb 16:12
Picon
Favicon

[jira] [Commented] (VELOCITY-719) Unwritable velocity.log appears to cause Velocity initialization to fail, leaving velocity dead and useless.


    [
https://issues.apache.org/jira/browse/VELOCITY-719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13197896#comment-13197896
] 

Georg Kallidis commented on VELOCITY-719:
-----------------------------------------

may be this is related. The definition in TR.properties 

services.VelocityService.runtime.log=/log/velocity.log

If using as VelocityService org.apache.turbine.services.velocity.TurbineVelocityService in
createVelocityProperties(..) you find a condition: if (!key.endsWith(RESOURCE_LOADER_PATH) {...
continue } and only after pathes are resolved relative to the web-app. IF you consider this, then e.g
defining runtime.log as above you end up (in may case) with a log in C:/log/velocity.log.

> Unwritable velocity.log appears to cause Velocity initialization to fail, leaving velocity dead and
useless. 
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: VELOCITY-719
>                 URL: https://issues.apache.org/jira/browse/VELOCITY-719
>             Project: Velocity
>          Issue Type: Bug
>          Components: Engine
>    Affects Versions: 1.6.2
>            Reporter: Cott Lang
>
> When we upgraded to 1.6.2 from 1.5.0, we began experiencing failures:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Georg Kallidis (Issue Comment Edited) (JIRA | 1 Feb 16:14
Picon
Favicon

[jira] [Issue Comment Edited] (VELOCITY-719) Unwritable velocity.log appears to cause Velocity initialization to fail, leaving velocity dead and useless.


    [
https://issues.apache.org/jira/browse/VELOCITY-719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13197896#comment-13197896
] 

Georg Kallidis edited comment on VELOCITY-719 at 2/1/12 3:14 PM:
-----------------------------------------------------------------

may be this is related. The definition in TR.properties of the velocity log is

services.VelocityService.runtime.log=/log/velocity.log

If using as VelocityService the default class
org.apache.turbine.services.velocity.TurbineVelocityService 

you find in the method createVelocityProperties(..)  (which is called when initializing) a condition: 

if (!key.endsWith(RESOURCE_LOADER_PATH) {... continue } 

and only after pathes are resolved relative to the web-app. 

If you consider this, then e.g defining runtime.log as above you end up (in may case) with a log in C:/log/velocity.log.

                
      was (Author: gm_kall):
    may be this is related. The definition in TR.properties 

services.VelocityService.runtime.log=/log/velocity.log

If using as VelocityService org.apache.turbine.services.velocity.TurbineVelocityService in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Georg Kallidis (Updated) (JIRA | 1 Feb 16:16
Picon
Favicon

[jira] [Updated] (VELOCITY-719) Unwritable velocity.log appears to cause Velocity initialization to fail, leaving velocity dead and useless.


     [
https://issues.apache.org/jira/browse/VELOCITY-719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Georg Kallidis updated VELOCITY-719:
------------------------------------

    Comment: was deleted

(was: may be this is related. The definition in TR.properties of the velocity log is

services.VelocityService.runtime.log=/log/velocity.log

If using as VelocityService the default class
org.apache.turbine.services.velocity.TurbineVelocityService 

you find in the method createVelocityProperties(..)  (which is called when initializing) a condition: 

if (!key.endsWith(RESOURCE_LOADER_PATH) {... continue } 

and only after pathes are resolved relative to the web-app. 

If you consider this, then e.g defining runtime.log as above you end up (in may case) with a log in C:/log/velocity.log.

)

> Unwritable velocity.log appears to cause Velocity initialization to fail, leaving velocity dead and
useless. 
> -------------------------------------------------------------------------------------------------------------
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark S (Created) (JIRA | 10 Feb 06:50
Picon
Favicon

[jira] [Created] (VELOCITY-817) Dynamic Templates with Caching

Dynamic Templates with Caching
------------------------------

                 Key: VELOCITY-817
                 URL: https://issues.apache.org/jira/browse/VELOCITY-817
             Project: Velocity
          Issue Type: Improvement
          Components: Engine
    Affects Versions: 1.7
            Reporter: Mark S

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 --
{code}
String template = "message.to:  ${message.to} ";
StringWriter velocityWriter = new StringWriter();
velocityEngine.evaluate( velocityContext, velocityWriter, "LOG", template );
return velocityWriter.toString();
{code}
-- 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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mark S (Updated) (JIRA | 10 Feb 06:50
Picon
Favicon

[jira] [Updated] (VELOCITY-817) Dynamic Templates with Caching


     [
https://issues.apache.org/jira/browse/VELOCITY-817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mark S updated VELOCITY-817:
----------------------------

    Description: 
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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark S (Created) (JIRA | 10 Feb 17:44
Picon
Favicon

[jira] [Created] (VELOCITY-818) Case-insensitive matching ${object.methodName} == ${object.methodname} == ${object.methodName}

Case-insensitive matching ${object.methodName} == ${object.methodname} == ${object.methodName}
----------------------------------------------------------------------------------------------

                 Key: VELOCITY-818
                 URL: https://issues.apache.org/jira/browse/VELOCITY-818
             Project: Velocity
          Issue Type: New Feature
          Components: Engine
    Affects Versions: 1.7
            Reporter: Mark S

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

Currently there is no easy way for Velocity to do a case-insensitive match on a property or method.  Below is
my implementation to achieve this.

VelocityContext velocityContext = new VelocityContext();
{
    context.put( "aNumericValue", "1234567890" );
}

| If String template =                 | Then String evaluatedTemplate =  |
| ${aNumericValue}                     | 1234567890                       |
| ${anumericvalue}                     | 1234567890                       |
| ${anumericValue}                     | 1234567890                       |
| ${aNumericvalue}                     | 1234567890                       |
| ${aNumericValue.toString()}          | 1234567890                       |
| ${anumericvalue.tostring()}          | 1234567890                       |

-- Setup Snippet --
(Continue reading)

Permalink | Reply | 0 comments |
headers
Konstantinos Kougios (Commented) (JIRA | 2 Mar 13:10
Picon
Favicon

[jira] [Commented] (VELOCITY-812) Parser.jj_scan_token very slow during debugging


    [
https://issues.apache.org/jira/browse/VELOCITY-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13220866#comment-13220866
] 

Konstantinos Kougios commented on VELOCITY-812:
-----------------------------------------------

there is a fix:
Parser.LookaheadSuccess should be modified to:

static private final class LookaheadSuccess extends RuntimeException
	{
		@Override
		public synchronized Throwable fillInStackTrace()
		{
			return this;
		}
	}

I'll inform the JavaCC team

> Parser.jj_scan_token very slow during debugging
> -----------------------------------------------
>
>                 Key: VELOCITY-812
>                 URL: https://issues.apache.org/jira/browse/VELOCITY-812
>             Project: Velocity
>          Issue Type: Bug
>          Components: Engine
(Continue reading)

Permalink | Reply | 0 comments |

Gmane