commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Florey" <>
Subject AW: [i18n] man available
Date Wed, 16 Feb 2005 12:08:25 GMT
Hi Woody,
Thanks for your help! See comments inline...


> -----Urspr√ľngliche Nachricht-----
> Von:
> []
> Im Auftrag von Anaximandro (Woody)
> Gesendet: Mittwoch, 16. Februar 2005 11:17
> An: Jakarta Commons Developers List
> Betreff: Re: [i18n] man available
> Hello Daniel,
> Yup, the ConfigManager not prove to be very usefull. This class is
> increasing the coupling level to give me a few features set (the con
> figuration features itself) and gave me much more code to delegate ...
> But you don't think necessary some code to configure the behaviours of
> this component? For instance: in your version when the component not
> find one message id they throw one unchecked exception. The component
> dont't force me to write one try catch block for each LocalizedEntry but
> force me to write all messages ids in their respective resource to avoid
> one exception. Avoid try catch blocks is cool, very cool, but this only
> make my code more clean, however the cost to do this is high: I must write
> the messages id (at least) to don't break the application, but if I forget
> one id the application will break in same mode.

I'll add some examples to the website that show how to deal with missing
messages, ok?

> Using some code to configure this helps in this situation. I can talk to
> component: hey pal, use the message id or entry id as default when you not
> find someone. Don't throw an exception, instead, write this in log. I
> will write these messages later ok?

I try to avoid including logging into the i18n component as there are so
many different loggers around. I just removed the commons-xmlio dependencies
by using sax-parsing instead, so my goal is to achieve a component with no
If we need logging, I'd vote for standard jdk 1.4-logging. What do you

> Hence I think is better to leave this decision to the user component. I
> know you wanna a small and easy to use component, I want the same think,
> but ... I think is more easy to use a componente wich can be configured
> than one wich we can't do this.
> Sorry if I'm talking to much, I really wanna help but my english make this
> more hard than really is.
> Only one MessageManager? no getInstance? As I see the problem exists
> when many threads (with different Locales) try to get a message. I don't
> see any problem with diferent applications (sure, the unique ID is requi
> red). If you use only one MessageManager you will need to always provide
> the desired Locale (in constructor or in getXXX method) because there is
> no more a place to store a default Locale info since the older place
> (setLocale/getLocale) will be shared by this threads. More than this,
> doing this will bestrew Locale info in resulting client code making this
> more hard to update. Well, this is just my opinion.

It is necessary to provide the desired locale in each getXXX method of the
LocalizedBundle-subclasses. I just removed the ones using the default locale
as this causes additional confusion. If you really want to specify a
thread-specific locale (??) then you need to store it in ThreadLocal.
I'll add a method to set the default locale in the MessageManager if it
should be something different than the VM default locale.

> I try to solve this writing the getInstance (as you suggest in email)
> but with this I create another problem: how to link a message with their
> respective manager? Passing this guy as parameter? nope, this is ugly. So
> writing some method to returns the current manager? Yes, make sense, then:
> getCurrentInstance, but, again, I created another problem: I need to write
> monitor code to lock unlock the instance to avoid data corruption (between
> threads). I think this is the last thing I need to close my version. I
> will
> do this (is a little hard to me because I never do this before).
> I'm right im my point? I miss something?
> Did you find some good idea in my code? If you do I can revise and
> generate
> the apropriate patch to you.

Yes, thanks. I'll add some LocalizedRuntimeException, LocalizedError etc.
and rename the LocalizedError to something more speaking.

> Good luck with envinronment (to be honest I need to learn maven, I just
> used eclipse, always redoing the configuration when I need).

Maven is a nice tool, but very bad documented indeed. So it's hard to figure
out how to achieved the desired stuff...

> Woody
> >Hi Woody,
> >I'm currently trying to improve the maven environment, so that releases
> and
> >tests can easily be done.
> >My goal is to complete the component in the actual state in order to
> build
> a
> >usable release as soon as possible.
> >I've already had a look at your proposed changes. I'd like to include
> some
> >changes into the current version (LocalizedRuntimeException), but I'm not
> >sure with the ConfigManager. This one introduces a lot of complexity.
> >In order to keep the i18n-component very simple my suggestions would be
> to
> >keep only one MessageManager with static methods and advice the user to
> use
> >unique message keys (comparable to java package names). This should avoid
> >trouble when using multiple applications. Agreed?
> >Next steps are to remove misleading methods (as we discussed earlier) and
> to
> >complete the javadocs and provide some more tutorials. This is the part
> >where help would be very much appreciated ;-)
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message