> > 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?
the env-entry applies only to the given webapp. each webapp contains its own
deployment descriptor with its own env-entry items. therefore, specifying
the default is inherently on a web-app-specific basis with deployment
descriptors.
with a properties file, there's no really good way in the source code for
the library to specify a properties file to load -- you won't know where the
file exists. in tomcat, it might be ..\webapps\myapp\foo.properties, but in
weblogic 6, it would be .\config\myapp\foo.properties.
with a properties file loaded as a resourcebundle, you're in immediate
trouble because the bundle would be compiled and loaded once for the life of
the JVM. the first webapp that loaded would specify the bundle to load, and
the bundles for the other webapps would be ignored.
> > 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.
now I'm getting confused... I think we may be talking about different things
here. the env-entry contains a single element which points to the resource
bundle that contains the translations.
what I think you're suggesting is hardcoding a properties file that the
localize tag will read upon initializing. this file will contain a single
key/value pair that tells the localize tag which resource bundle to load by
default for the translations.
this approach seems unnecessary -- you're stating that a webapp should have
a known place to be able to look at for initialiation properties.. sounds a
lot like a deployment descriptor to me. :-)
it seems in comparison that the only drawback with the current approach is
that the deployment descriptor env-entries are only available through JNDI.
> It's always good to provide a default, otherwise the bundle
> has to be always
> specified in every usage of the tag.
>
yes, but this is only once per page, at the top of the page. it seems that
it would make things easier to maintain for developers if they come back in
to make a bug fix to an application after six months (or if they are new) if
they can just look on the page to determine what bundle is in place.
If someone unfamiliar with the application needs to maintain it, having to
know to look somewhere else (even if its the deployment descriptor, but
especially if it's some taglib specific hardcoded properties file) seems
like it will just make long-term maintenance harder.
again, I'm just specifying how *I* plan to use the library, which is not to
ever use a default, but I think some people will still want to do that, so I
put it in there.
All that said, I think Craig McClanahan has made a suggestion that will work
quite well (see his separate message). Having a load-on-startup servlet set
the variable in an application-scope variable, much like you were
suggesting, should work perfectly. I'll update the library to allow to look
in a specific application scoped variable. In fact, since that should be
fairly lightweight, I'll put that in front of having the JNDI lookup for the
environment entry. Then I'll update the error to help the user with both
options if neither are present.
If I do that can I have your +1? :-)
Tim
