Sharing locale between JSF and Spring

Hi All,

I've been trying to find a solution for sharing the locale of the current user session in JSF with Spring so I can use Spring for localising messages (i.e. as opposed to having to do it in both Spring and JSF).

I did have a look around and couldn't see any solutions for this, so I've come up with my own method, however I'm not entirely convinced its a good design so I thought I would post it here and let you all tear it to pieces :)

First off, a little background on what I'm trying to achieve:

1. I don't want the main code to be dependent upon Spring - not for any particular reason, just I don't see the point in introducing a dependency if I can avoid it :)

2. While the UI portion of my code uses JSF, the back-end doesn't assume that its there - this is so I can call the back-end without using JSF if i need to (e.g. through a Web Service)

3. I don't want to have to put in code everywhere that uses messages that forces it to work out what the locale is

4. There may be multiple concurrent users using different locales.

So, with all that, here's what I've done:

1. I create a normal Spring bean to hold the messages (using ResourceBundleMessageSource). This still expects the locale to be passed in to retrieve a message. I've named it 'globalMessageBundle'

2. I create a thread local Spring bean to hold a localised wrapper around the messages (using ProxyTargetFactory and ThreadLocalTargetSource). This has a method to allow a Locale to be set, and provides pass-through methods to the globalMessageBundle. This is 'localMessageBundle'.

3. In JSF, I've created a PhaseListener that activates on RESTORE_VIEW, picks up the localMessageBundle and sets the locale on it.

If I'm not using JSF, this would be done manually before using the localMessageBundle.

4. Any methods that then require messages can then pickup localMessageBundle and not have to worry about the locale and just retrieve the messages.

This whole design is based on the assumption that the application server isn't going to have multiple concurrent users on the same threads - which i believe is a pretty same assumption?

Does this design make sense? or is there a better way to achieve my goals above?

Thanks for any advice :)


Lee

Quote:

---

Originally Posted by xenrik

Hi All,

I've been trying to find a solution for sharing the locale of the current user session in JSF with Spring so I can use Spring for localising messages (i.e. as opposed to having to do it in both Spring and JSF).

I did have a look around and couldn't see any solutions for this, so I've come up with my own method, however I'm not entirely convinced its a good design so I thought I would post it here and let you all tear it to pieces :)

First off, a little background on what I'm trying to achieve:

1. I don't want the main code to be dependent upon Spring - not for any particular reason, just I don't see the point in introducing a dependency if I can avoid it :)

2. While the UI portion of my code uses JSF, the back-end doesn't assume that its there - this is so I can call the back-end without using JSF if i need to (e.g. through a Web Service)

3. I don't want to have to put in code everywhere that uses messages that forces it to work out what the locale is

4. There may be multiple concurrent users using different locales.

So, with all that, here's what I've done:

1. I create a normal Spring bean to hold the messages (using ResourceBundleMessageSource). This still expects the locale to be passed in to retrieve a message. I've named it 'globalMessageBundle'

2. I create a thread local Spring bean to hold a localised wrapper around the messages (using ProxyTargetFactory and ThreadLocalTargetSource). This has a method to allow a Locale to be set, and provides pass-through methods to the globalMessageBundle. This is 'localMessageBundle'.

3. In JSF, I've created a PhaseListener that activates on RESTORE_VIEW, picks up the localMessageBundle and sets the locale on it.

If I'm not using JSF, this would be done manually before using the localMessageBundle.

4. Any methods that then require messages can then pickup localMessageBundle and not have to worry about the locale and just retrieve the messages.

This whole design is based on the assumption that the application server isn't going to have multiple concurrent users on the same threads - which i believe is a pretty same assumption?

Does this design make sense? or is there a better way to achieve my goals above?

Thanks for any advice :)


Lee

---

Hello

I was searching solution for this problem too, but with no luck....

I have declared:

Code:

---

<bean id="msg" class="org.springframework.context.support.ResourceBundleMessageSource">
        <property name="basenames">
        <list>
                <value>com.unizeto.edicta.os.messages.validation</value>
                <value>com.unizeto.edicta.os.messages.interface</value>
        </list>       
        </property>
</bean>

---

And wana use it in my jsf pages. For example I have in com.unizeto.edicta.os.messages.interface property structname=Nazwa struktury. Is it possible to use it in some way like this <ice:outputText value="#{structname}" />

Please help...

I would not worry about multiple concurrent users as localMessageBundle (if you use ReloadableResourceBundleMessageSource) gets the Locale from LocaleContextHolder, which is thread safe and I can not imagine an application server, serving different requests on the same thread. I think your solution would work. I have an opposite problem. I primarily manage my Locale in FacesContext and want to pass it to Spring whenever it is changed in JSF. No pretty solution found so far (see my thread "Forwarding Locale change from JSF to Spring") - maybe you've got an idea...

Regards, Andrew