You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Most TemplateSource implementations inherit equals() from AbstractTemplateSource which only compares filename().
This means that two equally named TemplateSource's, even loaded from different media (ClassPath, filesystem, Internet, whatever), will be considered identical by the template cache system, which can cause caching false positives. So probably URLTemplateSource should be considered equal only to another URLTemplateSource with the same location (not name!).
StringTemplateSource is a place where this problem can surface even without using different template loaders and fancy stuff like that. It gets its filename from the constructor parameter; in Handlebars.compileInline(), the name passed to the constructor is derived from the template string's hashCode(). In case of hash code collision, two different template strings will have the same filename in StringTemplateSource and will thus be considered equal by the cache system, which will yield the same Template for two different template strings. A totally unexpected, rare, and thus hard to catch failure. StringTemplateSource must compare content, not filename!
The text was updated successfully, but these errors were encountered:
Got hit by this issues recently! Currently the equals() only compares the filename.
should definitely compare content if the filename is the same for StringTemplateSource. It's easily to hit collision when having a lot strings.
yohannrub
added a commit
to yohannrub/handlebars.java
that referenced
this issue
Jan 28, 2022
Most
TemplateSource
implementations inheritequals()
fromAbstractTemplateSource
which only comparesfilename()
.This means that two equally named
TemplateSource
's, even loaded from different media (ClassPath, filesystem, Internet, whatever), will be considered identical by the template cache system, which can cause caching false positives. So probablyURLTemplateSource
should be considered equal only to anotherURLTemplateSource
with the samelocation
(notname
!).StringTemplateSource
is a place where this problem can surface even without using different template loaders and fancy stuff like that. It gets itsfilename
from the constructor parameter; inHandlebars.compileInline()
, the name passed to the constructor is derived from the template string'shashCode()
. In case of hash code collision, two different template strings will have the samefilename
inStringTemplateSource
and will thus be considered equal by the cache system, which will yield the sameTemplate
for two different template strings. A totally unexpected, rare, and thus hard to catch failure.StringTemplateSource
must comparecontent
, notfilename
!The text was updated successfully, but these errors were encountered: