Re: templates path not reloading on clearTemplateCache()

Daniel Dekany <[email protected]>
Newsgroups gmane.comp.web.freemarker.user
Message-ID <[email protected]>
Saturday, April 18, 2009, 1:07:33 AM, Matthew Anderson wrote:
> Just a little follow up on this.  
>
> Is setDirectoryForTemplateLoading  thread safe? Documentation doesnt say if it is or not.

The JavaDoc of Configuration itself says:

"This object is not synchronized. Thus, the settings must not be
changed after you have started to access the object from multiple
threads. If you use multiple threads, set everything directly after
you have instantiated the Configuration object, and don't change the
settings anymore."

That said, it's not thread-safe.

See also:
http://freemarker.org/docs/pgui_misc_multithreading.html

> setTemplateLoader is not thread safe

Ah... so this was the unclear then: setDirectoryForTemplateLoading is
just a convenience method that calls setTemplateLoader, so the same
rules apply.

> clearTemplateCache() is thread safe
>
> thanks,
> matthew
>
> On Tue, Feb 10, 2009 at 5:34 AM, Attila Szegedi <[email protected]> wrote:
> Hm... This is strange - FreeMarker's FileTemplateLoader doesn't use
> canonicalized paths to load templates...
>
> Now, instead of clearing the template cache, you could call
> Configuration.setDirectoryForTemplateLoading() again with the path (or
> Configuration.setTemplateLoader() with a recreated
> FileTemplateLoader). That will recreate the FileTemplateLoader object
> and should get rid of any stuck state (with the disclaimer that there
> should be no such stuck state anyway). Changing the template loader
> also internally triggers cache clearing.
>
> There is actually another reason why would you want to recreate the
> template loader if you're chaning symlinks. The reason is that a
> FileTemplateLoader will resolve a path to a canonical path on
> construction, and will refuse to serve files from outside the
> canonical location the symlink resolves to. Note: it is _not_ using
> the canonical path to look up templates, it is just comparing the
> canonical path of the root template directory with the canonical path
> of the template, and if the former isn't a prefix of the latter,
> refuses to load the template.
>
> Alternatively, you can just create a FileTemplateLoader with the two-
> arg constructor and pass true for parameter "allowLinking" in the
> constructor, and then it won't care about canonical paths at all.
>
> Attila.
>
>
> On 2009.02.07., at 20:53, Matthew Anderson wrote:
>
>> We are having an issue that when we clear the template cache using
>> clearTemplateCache(), we dont get the new templates.  Here is our
>> settup.
>>
>> We have a symlinked path to our templates.
>>
>> path to templates that we load: /mypath/templates
>> This path is a symlink pointing to the real hard linked path for the
>> templates
>> ie: v1 of templates path is /local/templates/v1
>> v2 of templates path os /local/templates/v2
>>
>> Reproduce steps:
>> /mypath/templates points to /local/templates/v1
>> We deploy new templates to v2 path, and flip the symlink /mypath/
>> templates to now point to /local/templates/v2
>>
>> Every five minutes, our service checks to see if the canonical path
>> has changed for the template dir path, and if it has,  then we call
>> clearTemplateCache()
>>
>> However, the templates from v1 path are still getting picked up. Is
>> there a way to force freemarker to reload the symlink path?  It
>> seems as if there is a handle somewhere to the old symlinked
>> directory.
>>
>> thanks,
>> matthew

-- 
Best regards,
 Daniel Dekany


------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and 
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today. 
Use priority code J9JMT32. http://p.sf.net/sfu/p
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.