• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Devaka Cooray
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Knute Snortum
  • Bear Bibeault
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • Piet Souris
  • Ganesh Patekar
Bartenders:
  • Frits Walraven
  • Carey Brown
  • Tim Holloway

web server/fmt JSTL and properties bundle caching

 
Ranch Hand
Posts: 97
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A project I am assigned to is to create a i18n custom tablib process that allows for resource string updates as they are pushed to the server without the need of a server restart.

Main problem they have with trying to use the standard fmt JSTL is it would seem that once the properties file is initially referenced from an fmt call in a jsp it is cached. All subsequent references to this properties file remain static until a server restart.

Is this behavior a product of the fmt library, or is this the result of standard application server implementation?
It would seem the former as I can start the server and can edit the properties file in place which is represented by the output from the jsp on initial reference, but any changes to the properties file thereafter are ignored. It would appear that fmt adds the resource bundle instance into the session scope (at least) upon initial load ? I can understand the reasoning behind wanting to avoid the cost of rereading on each reference, but can this behavior be avoided without a re-write?
 
Sheriff
Posts: 67266
170
Mac Mac OS X IntelliJ IDE jQuery Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Is this behavior a product of the fmt library, or is this the result of standard application server implementation?


It is a result of Java's implementation of resource bundles.

without the need of a server restart.


You never need to restart the server -- only the web app needs to be restarted.
 
Karl Krasnowsky
Ranch Hand
Posts: 97
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Bear Bibeault wrote:

Is this behavior a product of the fmt library, or is this the result of standard application server implementation?


It is a result of Java's implementation of resource bundles.

without the need of a server restart.


You never need to restart the server -- only the web app needs to be restarted.



I misspoke... I meant the web app.
 
Marshal
Posts: 24594
55
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually... if you check the Java 6 API documentation for ResourceBundle, you'll see a section headed "Cache Management". Presumably you won't be able to make JSTL clear the cache, but your own taglib could work with the new features.
 
Karl Krasnowsky
Ranch Hand
Posts: 97
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Paul Clapham wrote:Actually... if you check the Java 6 API documentation for ResourceBundle, you'll see a section headed "Cache Management". Presumably you won't be able to make JSTL clear the cache, but your own taglib could work with the new features.



Well I'll be darned. I've been using ResourceBundle for ions and never noticed this behavior before. Assumed it was a web app optimization policy.
Thanks for the pointer.
 
Paul Clapham
Marshal
Posts: 24594
55
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, it is "since 1.6". But those poor Java engineers... labouring away in their grotty cubicles making neat new stuff, and nobody notices.
 
Karl Krasnowsky
Ranch Hand
Posts: 97
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Paul Clapham wrote:Well, it is "since 1.6". But those poor Java engineers... labouring away in their grotty cubicles making neat new stuff, and nobody notices.



Well, the caching apparently has been there for awhile but the ability to control it is new with 1.6.

Product I'm working with is dependent on Jre 1.5 so using these new services isn't really available anyway.
 
Consider Paul's rocket mass heater.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!