Dynamic resource loader (context/moduleName) seems optional yet is required to use this feature (KNL-563)
Description
relates to
Activity
Matthew Jones July 17, 2013 at 4:42 PM
Should be resolved by
Matthew Jones July 17, 2013 at 4:41 PM
We're trying this out, it looks pretty good. It looks like the RSF tools aren't a problem anymore. It's possible might have updated this issue too so I'm just going to close it for now.
John Bush January 31, 2013 at 10:09 AMEdited
If a tool isn't using the ResourceLoader by directly loading the bundles it won't work. I don't remember the situation with rsf tools off the top of my head, probably there is still a problem there. I know there is still work to do for the wicket tools like profile2 as well. The original tools that were updated can be found here: SAK-18985, I see something for evalsys that is an rsf tool. So probably that same mechanism can be applied to reset-pass. The profile2 issue is recorded here: PRFL-705. I'll dig into this one a little more and see what's going on.
Matthew Jones June 18, 2012 at 10:05 AM
I believe the first time we actually tried to use this was on reset-pass, trying to change the bundle property for "msg.expiredValidation". For this rsf lookup it was using "uk.org.ponder.messageutil.TargettedMessage" and wasn't correctly working. I think in rsf it was causing it to come through without a context as well for the lookup and failing?
John Bush June 15, 2012 at 3:59 PMEdited
Yes there is a reason this was done, its because folks haven't used any namespace in a lot of places in sakai there are quite a few basename ='messages' that come from different modules. This was the best idea I could come up with to provide a solution to make things things discrete without refactoring all the tools to use package names or something else that would make the bundles discrete. You are correct, any i18n stuff behind a service will have a problem. I welcome more thinking here, I'm not sure how much service only lookups really exist. When I started out, I considered creating processes that could index the files or something like that, but in the end self registration and relying on the context seemed a way to get further quickly without enforcing changes all of the tools, or some build time funny business looking at the files.
In KNL-563, the ability to load dynamic resources bundles out of the database was added.
However
in DbResourceBundle.java
static public ResourceBundle addResourceBundle(String baseName, Locale locale, ClassLoader classLoader) {
if the context is null, it won't load any dynamic values. However only baseName, locale and classLoader should be required and context/moduleName seems like it would just be a subset or "extra" information given the baseName.
I'm either looking for
1) A clarification on why moduleName exists as a field at all
and /or
2) Moving the check for moduleName out of this function and into MessageBundleServiceImpl.java->getBundle and making it optional there.
There are some cases where the context will be returned as null yet a message bundle lookup is still needed to be processed.