Eric Norman created SLING-10135:
-----------------------------------
Summary: Add the ability to locate non JCR based ResourceBundle
resources
Key: SLING-10135
URL: https://issues.apache.org/jira/browse/SLING-10135
Project: Sling
Issue Type: Improvement
Reporter: Eric Norman
Assignee: Eric Norman
Fix For: i18n 2.5.16
The sling.i18n ResourceBundle discovery mechanism appears to be utilizing a JCR
centric xpath query that is used to locate the resources that contain the
resource bundles strings. Specifically:
"//element(*,mix:language)[@jcr:language]"
This means that any resources provided by a non-JCR backed resource provider
like the Sling-Bundle-Resources technique are not discovered and used. The
non-JCR provider implementations usually don't supply an "xpath"
QueryLanguageProvider implementation that would understand the query that the
sling.i18n bundle is running.
What I propose is to supply a new osgi.extender technique in sling.i18n so that
a bundle can declare certain paths that should be traversed to locate
ResourceBundle resources.
For example, the bundle providing the resources could define something like
this:
{code:java}
Require-Capability:
osgi.extender;filter:="(&(osgi.extender=org.apache.sling.i18n.resourcebundle.locator.registrar)(version<=1.0.0)(!(version>=2.0.0)))"
Provide-Capability:
org.apache.sling.i18n.resourcebundle.locator;paths="/libs/i18n/path123";depth=1{code}
The "Provide-Capability" instruction would define which (csv) resource paths to
traverse and how deep to drill down (depth=1 by default) looking for candidates.
The sling.i18n bundle would supply the
"org.apache.sling.i18n.resourcebundle.locator.registrar" capability that would
track any bundles added/removed that contain the new "locator" paths. Those
new locator paths would be traversed to augment the set of potential language
roots when a ResourceBundle is requested.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
