[
https://issues.apache.org/jira/browse/TILES-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12906958#action_12906958
]
Bryan Keller commented on TILES-515:
------------------------------------
I am guessing that, because Tomcat unarchives the war to the file system, it
will try to read from the file system and not directly from the war file. Thus
it works. I'll experiment w/ embedded Jetty, which allows loading directly from
a war, and see if I can duplicate.
For me, I'm using Tiles inside a war bundle in an OSGi container (Apache
Felix), with an OSGi HttpService implementation (Pax-Web). The war is never
unarchived. This setup might be a little more involved, so I'll look at an
embedded Jetty example to reproduce.
> ResolvingLocaleUrlDefinitionDAO doesn't handle loading from war properly
> ------------------------------------------------------------------------
>
> Key: TILES-515
> URL: https://issues.apache.org/jira/browse/TILES-515
> Project: Tiles
> Issue Type: Bug
> Affects Versions: 2.2.2
> Reporter: Bryan Keller
>
> The BaseLocaleUrlDefinitionDAO does not handle loading view definitions
> directly from a war bundle properly. In the loadDefinitionsFromURL() call, it
> catches a FileNotFoundException if a definition is not found, logs a debug
> message and continues. This is the proper way to handle situations where a
> view definition has not been defined for a particular locale. However, when
> loading from a resource URL (e.g. "classpath:/..." or "bundle:/"), if the
> view definition is not found, a "FileNotFoundException is not thrown, rather
> an IOException is. A plain IOException is not consumed, but rather thrown,
> and prevents Tiles from initializing.
> The code is in BaseLocaleUrlDefinitionDAO, line 277. The IOException handling
> should check if it is a resource not found error and ignore the exception if
> so.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
