Re: Localisation Pull Tool

[John McNally <jm...@collab.net>]

Unfortunately I do not think there is a way to register an alternative
property file ResourceBundle.  The getBundle method looks for a class
according to the naming scheme and if it does not find one looks for a
property file and instantiates a PropertyResourceBundle if it finds
one.  (This is from the javadoc.)

So it appears if you want better behavior than available from
PropertyResourceBundle, you are stuck having to write a class per
property file.  I think it should be possible that these classes could
be empty, so it is not out of the question to go this route.

Other than that you are stuck having to implement a complete
localization implementation independent of ResourceBundles.

john mcnally

Daniel Rall wrote:
> 
> John McNally <jm...@collab.net> writes:
> 
> > Off the top of my head, I would say you will need to write an
> > implementation of ResourceBundle that will reload the properties file if
> > its modified date is greater than the last loaded date.  Quite a bit of
> > work.  Alternatively, if you have class reloading turned on (using
> > tomcat), try forcing a compile of one of the java classes in your app.
> > It should trigger a reload of the properties file, but I am not 100%
> > positive on that.
> 
> I'm also going to need an alternate ResourceBundle implementation.
> The PropertyResourceBundle implementation in the JDK 1.3.1 from Sun
> uses a Hashtable internally for storage.  For a web app, where the
> common use case is many concurrent reads, use of synchronized storage
> for property lookups is definitely not the best design decision.
> 
> Does anyone know how to "register" a ResourceBundle extension so that
> it would be used instead of PropertyResourceBundle when
> ResourceBundle.getBundle() is called?  (I admit I looked around for a
> way to do this only briefly.)  I'd like to write such an extension and
> include it with the LocalizationService--it will yield much higher
> read performance in a web application.
> 
>                                 Daniel
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org