[
https://issues.apache.org/jira/browse/SLING-10135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Norman updated SLING-10135:
--------------------------------
Description:
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" path
declarations. Those declared locator paths would be traversed to augment the
set of potential language roots whenever a ResourceBundle is requested.
was:
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.
> 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
> Priority: Major
> 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" path
> declarations. Those declared locator paths would be traversed to augment
> the set of potential language roots whenever a ResourceBundle is requested.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
