Hello guys,
We have just encounter strange "bug?" (is it bug or I am only dumb?)
We've implemented Custom Repo action - "SampleAction extends ActionExecuterAbstractBase()"
and call it with this sample (test call):
action = actionService.createAction(SampleAction.NAME)
action.setParameterValue(SampleAction.PARAM_QUERY, query)
action.setExecuteAsynchronously(true) // here is the problem when async is true
actionService.executeAction(action, null)
Strange thing happens with asynchronous execution.
In code we try to retrieve localized messages from I18NUtil:
I18NUtil.getMessage("action.sample.msg")
// or
messageService.getMessage("action.sample.msg")
When action is called with asynchronous=false -> everything is alright.
But when asynchronous=true -> I18NUtil or even messageService can not find the message (returns null)
I've tried debug through I18NUtil.getMessage() - seems that budles are there with messages, but can not retrieve the exact message
Status report: we debugged I18NUtil a little bit more: when called from the asynchronous action - our custom budles are cached, but messages from this context are not (not even one message from our custom bundles)
Message budles are registered as follows:
<bean id="custom.base.dictionaryBootstrap"
parent="dictionaryModelBootstrap"
depends-on="dictionaryBootstrap">
<property name="labels">
<list>
<value>alfresco.module.${project.artifactId}.messages.customActions</value>
</list>
</property>
</bean>
Any help would be appreciated.
Thanks
Solved! Go to Solution.
Thanks for your reply.
Yeah, we though this aswell. But it seems that the I18NUtil is able to get proper Locale (messageService.getLocale() returns exact Locale from request header) even in asynchronous action.
SOLVED: so, we have played with this a little bit. Just try/error style.
Register bundles as:
<bean id="resourceBundles" class="org.alfresco.i18n.ResourceBundleBootstrapComponent">
<property name="resourceBundles">
<list>
<value>alfresco.module.${project.artifactId}.messages.customAction</value>
</list>
</property>
</bean>
seems to solve this problem. It looks like bundles are loaded differentyl from dictionaryBootstrap. The messages was really not cached in I18NUtil in asynchronous context.
Do not know if this is bug or not.
Thank you
Your problem probably has to do with the lack of the proper Locale in the context of I18nUtil. When you run an action in synchronous mode, the action and I18nUtil inherit the Locale context from the request thread, which typically is associated with the Locale as provided by the client browser. This context is not carried over to asynchronous actions, and as such, the I18nUtil may try to look up messages in different locales from the ones for which you have provided message bundles, and thus not find any matches.
Thanks for your reply.
Yeah, we though this aswell. But it seems that the I18NUtil is able to get proper Locale (messageService.getLocale() returns exact Locale from request header) even in asynchronous action.
SOLVED: so, we have played with this a little bit. Just try/error style.
Register bundles as:
<bean id="resourceBundles" class="org.alfresco.i18n.ResourceBundleBootstrapComponent">
<property name="resourceBundles">
<list>
<value>alfresco.module.${project.artifactId}.messages.customAction</value>
</list>
</property>
</bean>
seems to solve this problem. It looks like bundles are loaded differentyl from dictionaryBootstrap. The messages was really not cached in I18NUtil in asynchronous context.
Do not know if this is bug or not.
Thank you
Hi @p31r ,
Glad to see you got it sorted - thanks also for reporting the solution, really helpful for others ecountering similar problems.
Best wishes,
Ask for and offer help to other Alfresco Content Services Users and members of the Alfresco team.
Related links:
By using this site, you are agreeing to allow us to collect and use cookies as outlined in Alfresco’s Cookie Statement and Terms of Use (and you have a legitimate interest in Alfresco and our products, authorizing us to contact you in such methods). If you are not ok with these terms, please do not use this website.