[prev in list] [next in list] [prev in thread] [next in thread] 

List:       velocity-user
Subject:    Re: velocimarco.library property and StringResourceLoader
From:       "Nathan Bubna" <nbubna () gmail ! com>
Date:       2009-01-08 19:06:18
Message-ID: 4d651da50901081106j6ac778e9i859e9000b0a739b8 () mail ! gmail ! com
[Download RAW message or body]

On Thu, Jan 8, 2009 at 10:04 AM, Raymond Auge <rauge@liferay.com> wrote:
> On Thu, 2009-01-08 at 09:46 -0800, Nathan Bubna wrote:
>
>
>> That would work great for your particular setup, where you are always
>> checking if the resource is already stored in the repo.  Others,
>> however, may expect that strings in the repo don't disappear based on
>> usage anymore than a lesser-used file would disappear from the file
>> system, so that really couldn't be the default implementation.
>
> Very true. I wasn't implying that for a default to Velocity, but as a
> solution to the potential memory issue in my scenario.
>
>>
>> >> You would just have to set the
>> >> string.resource.loader.repository.class property or manually set the
>> >> repo via:
>> >>
>> >> StringResourceLoader.setRepository(StringResourceLoader.REPOSITORY_NAME_DEFAULT,
>> >> myStringResourceRepo);
>
> Regarding this, we already have:
>
>                props.setProperty(
>                        org.apache.velocity.app.VelocityEngine.RESOURCE_MANAGER_CLASS,
>                        "com.liferay.portal.velocity.LiferayResourceManager");
>
>                props.setProperty(
>                        org.apache.velocity.app.VelocityEngine.RESOURCE_MANAGER_CACHE_CLASS,
>                        "com.liferay.portal.velocity.LiferayResourceCache");
>
>
> Will the rendered Template objects fall into this cache anyway? If so,
> is there any reason to change the repository configuration?

yeah, each String that you put into the repository, when requested, is
parsed into a Template which will be managed/cached by the classes
above.  But that String will still be sitting in the repository too.
If the repository is becoming a memory issue (as always, be wary of
premature optimization), then it might behoove you to create your own
StringResourceRepository that doesn't keep everything around.

> Thanks,
>
> --
> Raymond Augé
> Senior Software Engineer
> Liferay, Inc.
> Enterprise. Open Source. For Life.
>
>

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


[prev in list] [next in list] [prev in thread] [next in thread]