This is one of the use cases for using fragment bundles. A fragment bundle is sharing the same class loader as the host bundle, so you get the same behaviour as with a plain Java project.
Am 16.01.2017 4:42 PM schrieb "Tim Ward" <t...@telensa.com>: What's the recommended approach to loading strings for I18N? Without using OSGi, one might create a bunch of .properties files, and load them as needed with ResourceBundle.getBundle( "basename", loggedInUsersLocale ) with the basename[_...].properties files on the class path. With a suitably chosen class path one can then drop in .properties files at run time to add new language translations[#]. When using OSGi, dropping files into "the class path" is obviously somewhat more complicated, and in any case it would be more in keeping to drop in bundles rather than raw .properties files, wouldn't it? What are the common patterns for doing this with OSGi? - the specific requirement here seems to be to add a new language without a system rebuild: putting a bunch of .properties files into an I18N bundle which gets rebuilt for new languages (ie rebuilding a bundle not the entire system) would probably work but off the top of my head sounds less attractive than a pattern which involves dropping in a new bundle for a new language. Or should I be looking at the fileinstall service? (So many ways to approach things ...) [#] give or take the caching, which I haven't experimented with yet -- Tim Ward _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev