Major Description
Currently i18n files are much like plain java property files, except that they are parsed based on an execution context, so that the same key can be translated differently in different contexts.
The same system could be used also for other parts of the system where property files are used, which are only two :
- Settings
- Services (converters and formatters)
The problem with contextualization is a problem of caching. For example, right now, properties are used for database configuration, so right now the first time the database is accessed the whole database infrastructure is loaded (connections created, pooling, jndi whatever it is), and then reused for subseguent connections. If these properties were contextualized, it would be possible to define different database settings for different parts of the system (like for example, a different database for a certain package). While this is rarely useful, it is a good example of which kind of problems this improvement could cause : every connection would have to be created depending on the context, potentially leading to a great performance issue. So a smarter caching and reuse system will have to be implemented.