> My though was to re-use the basename or id used when "installing"
> ResourceBundle or XML providers. For example, after issuing
> ResourceBundleMessageProvider.install("errorMessages");
> I would like to be able to qualify the newly installed messages with
> MessageBundle msg = new MessageBundle("errorMessages", "unexpectedError");
> but also keep the existing alternative with
> MessageBundle msg = new MessageBundle("unexpectedError"); //
> "unexpectedError" from any source
Do you want this to be able to install different resources with the same message key or is it mainly because of implementation details (performance)?
Primarily multiple entries with same key, secondarily performance.
> This may seem like a minor change at a first glance, but to also improve
> performance my thought was to to change the MessageManager class from
> holding a list of provider instances - which in turn can contain multiple
> resources (and thus assumes one instance per provider class) - to holding a
> Map from basename/id/namespace/qualifier to provider instance, where each
> instance only contains a single resource (i.e. XML-file/ResourceBundle).
> Though I planned on backwards compatibilty, by looping over the Map values
> - instead of the List entries - in the current MessageManager.getText() method.
> (Did I make myself clear?)
I try my best to get your point...
At the moment there is only one MessageProvider holding many resources. You want to change this to many MessageProviders holding one resource each in order to improve performance?
Yes. Instead of having to loop through the providers - catching exceptions from those who do not contain the entry, which is quite costly performance wise - and get the first match, I want to be able to point out the source which I expect to hold the entry. But then again, todays behaviour should be kept as the default behaviour when not using a basename/namespace qualification.
I currently don't have access to the sources as I'm on a project in Jordan
(You can browse them online, http://jakarta.apache.org/commons/sandbox/i18n/xref/index.html is quite easy to navigate)
but as soon as I'm back home I'll try to have a closer look at this.
Should I try to create a patch suggestion which you could look at then?
Always keep in mind that it should be very simple to use the component.
Sure. As I said, I intend to be backwards compatible with currenty usage. Though possibly the installation of resources may look slightly different.
Do you have sandbox commit access?
Nope.
Mattias Jiderhamn
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
