More questions below:
Tim Dawson wrote:
>
> I assume you're suggesting a hardcoded property file in the constructor of
> the localize tag. There are a number of problems with this approach:
>
> 1. the property file needs to be in a relative location depending upon the
> deployment of the web application -- I may well want different defaults for
> different web apps
How do you solve this problem when using env-entry?
>
>
> 2. the web app may well be in a WAR file or even doubly nested in an EAR
> file. the only way to safely get this info would be to use a resource
> bundle and place it in the classpath somewhere -- probably in
> WEB-INF/classes/ -- but this is (1) pretty ugly from a maintainability
> standpoint (2) if we're going to use a hardcoded resource bundle, why have
> the resource bundle point me to another resource bundle -- why not just
> hardcode the resource bundle that needs to be used by the i18n library? :-)
Isn't it the same using env-entry? I only see the storage mechanism (file vs
JNDI) as the difference.
>
>
> 3. the tags are often cached or pooled by the servlet container & reused.
> you can't necessarily count on the constructor being called for the tag on
> each page, and some pages may want to provide a specific bundle while others
> use the default.
>
> and finally...
>
> 4. it's too hardcoded & unobvious. the servlet spec specifically points out
> that the env-entry portion of the deployment descriptor is supposed to be
> used for "allowing a servlet to obtain references to resources".
>
> It seems to me that the potential cures are worse than the disease.
> Besides, as the doctor says "if it hurts, don't do it". You can always just
> specify which bundle each time you use the tag if you're really concerned
> using JNDI. Or we could just remove the default bundle feature altogher... I
> never liked it that much anyway. :-)
It's always good to provide a default, otherwise the bundle has to be always
specified in every usage of the tag.
>
>
> Tim
