Also see the XMLC 2.2 Release Note, XMLC 2.2.1 Release Note, XMLC 2.2.2 Release Note, XMLC 2.2.3 Release Note, XMLC 2.2.4 Release Note, XMLC 2.2.5 Release Note, XMLC 2.2.6 Release Note, XMLC 2.2.7.1 Release Note, XMLC 2.2.8.1 Release Note, XMLC 2.2.9 Release Note, XMLC 2.2.10 Release Note, XMLC 2.2.11 Release Note, XMLC 2.2.12 Release Note, XMLC 2.2.13 Release Note, XMLC 2.2.14 Release Note, XMLC 2.2.15 Release Note, XMLC 2.2.16 Release Note, XMLC 2.2.17 Release Note, XMLC 2.3 Release Note, XMLC 2.3.1 Release Note, and XMLC 2.3.2 Release Note.
Prior to this release, the URLs XMLC derived for SSI's included "." and "..", verbatim to the SSI inclusion reference in the parent template. This works just fine for "file:/"
URLs, but not for "jar:file:/"
URLs. While this issue is, technically, a bug in java.net.JarURLConnection
there's no chance of it getting fixed there so now XMLC works around it.
XMLC now resolves all relative path references to the respective fully qualified canonical path. So, "jar:file:/path/to/app/WEB-INF/lib/some.jar!/com/package/app/templates/../includes/someInclude.ssi"
becomes "jar:file:/path/to/app/WEB-INF/lib/some.jar!/com/package/app/includes/someInclude.ssi"
. This is one of multiple benefits provided by XMLC's new robust SSI URL resolving.
Credit goes to Sasa Bojanic for discovering and reporting this issue on the user list, as well as validating the fix.
ThreadLocal
used inside XMLCDeferredParsingFactory
Using XMLC-2.3.2, upon application/server shutdown Tomcat 7.x reports "probable classloader leaks" because the ThreadLocal
isn't being completely removed from threads (which are pooled and reused by Tomcat). Actually, there is some cleanup going on in XMLC-2.3.2. What's stored is a java.util.Locale[]
array and the elements are nulled out after use, but the Locale[]
array itself isn't removed.
With this fix, the Locale[]
array is entirely removed from each thread so no more complaining (nor potential classloader leaks) by Tomcat 7.x.
org.enhydra.xml.xmlc.misc.SSISystemIdResolver
, along with updates to org.enhydra.xml.xmlc.deferredparsing.DocumentLoaderImpl
, org.enhydra.xml.xmlc.compiler.Parse
, and org.enhydra.xml.xmlc.misc.SSIReader
to take advantage of it.
Provides...
java.net.URLConnection
subclass (especially java.net.JarURLConnection
).
Note: resolution of "." and ".." is only handled starting at the beginning of the path. Nested instances are not resolved. So, given "../../path/../to/some.ssi"
, only the first 2 contiguous ".." instances will be resolved. The 3rd, nested, instance will remain unresolved, left in the path verbatim.
Uses the relative path used to load the parent file to determine the maximum number of directory steps back (the "operative root") to take when performing SSI resolution. For instance, if the parent file, loaded by an XMLC resource loader using the relative path "com/package/app/templates/someTemplate.html"
, resolves to a fully qualified path of "file:/path/to/app/WEB-INF/classes/com/package/app/templates/someTemplate.html"
and the SSI's relative path is "../../../../../../../someInclude.ssi"
the farthest back it will go is "file:/path/to/app/WEB-INF/classes/someInclude.ssi"
. While the resource might not actually exist in the "operative root", this ends up being important when, for instance, deploying to Google App Engine where references outside the app lead to various security exceptions masking the real issue, which is a missing resource.
Note that this is only applicable at runtime, since at build-time (using deferred parsing compilation) resources are loaded using File IO rather than being loaded relative to XMLC resource loader contexts given a relative file path.
ResourceLoader
The concept of the ResourceLoader
was introduced in XMLC 2.3.2. It provides the ability to control the context from which templates are loaded. However, for SSI's a separate, less sophisticated, loading mechanism was used providing no user control. Now all template loading, including SSI, is under full user control via ResourceLoaders
! Among other things, this provides...
This ability, the ability to load in various contexts, as well as continued support for "SSI-base" functionality, results in "operative root" flexibility.
L10nTask
with ssi="true"
.DocumentLoaderImpl.getSourceFileName(Class)
method
This method can never be removed without potentially breaking custom DocumentLoader
implementations. Instead, just documented exactly what the default implementation does so users are aware of how to obtain the same information without said method.