Hi Thank you Oliver for the suggestion. I have attempted using the "classpath" scheme as, but I get "java.lang.IllegalStateException: Unknown protocol: classpath". Maybe Karaf has an additional URLHandler for "classpath"?
Carsten Ziegeler wrote on SLING-9862 > I personally don't like the idea to have repoinit inside a bundle; so if we > can > come to a solution where no new header is introduced that's probably better. > Today, you can install a feature, which references bundles, configurations > and repoinit - which I think is a much more flexible way than having > everything > inside the code bundle. Users of your code might use different users, > different > content paths (if configurable) etc. Unfortunately I am in no position to use the feature model. I am looking for solutions on how to better leverage repoinit on older Sling deployments (namely AEM 6.5 on-prem), where the OSGi installer is still the main means for deployment. Or am I missing something and it is possible to use the feature model for this? My goal is finding a way to maintain repoinit files in a Git Repository and have them applied to the instance upon deployment via content-packages. The existing "RepositoryInitializerFactory" configuration does not quite cut it, as I outlined previously in this thread (mainly the "scripts" configs are not maintainable due to required escaping within config files and "references" to bundle resources are not predictable, see SLING-9524). I think a bundle developer knows best which permissions a service user requires. Therefore I see some value in allowing the bundle to transport such information. However, I acknowledge that embedding such information in the bundle could take away flexibility for deployments to customize the setup. And as you mention, it _is_ possible to use a different name for a service-user. An alternative could be a repoinit installer factory for the OSGi Installer. This would allow repoinit files to be deployed via content-package, e.g. in an /apps/myapp/config folder. Also a combination of the two could be worthwhile: the bundle-header approach could be opt-in and guarded by a configuration that allows whitelisting bundle symbolic names for which embedded repoinit scripts should be deployed. A warning could be printed for any bundle that contains repoinit scripts but is not whitelisted. And finally, an "ignore"-list of bundle symbolic names could allow suppressing the warning. The logging would draw a deployer's attention to the fact that a bundle embeds repoinit files and ideally prompt them to whitelist it or to add it to the ignore list. Even in the case of the ignore list, the deployer could extract the repoinit files and modify them. Any custom repoinit configurations could be deployed via OSGi installer. I am not fixed on either solution, but I would like _a_ way forward. I'd also be happy with "just" the repoinit installer factory. Regards Julian On Sat, Oct 24, 2020 at 5:46 PM Oliver Lietz <[email protected]> wrote: > > On Saturday, October 24, 2020 4:33:56 PM CEST Julian Sedding wrote: > > Hi all > > Hi Julian, > > > I am working on "older" Sling setups that do not yet use the feature > > model to describe instances. Rather they leverage the OSGi Installer > > for deployment of bundles and configurations. > > > > Currently I am looking into using Repoinit for setting up > > Service-Users and ACLs, and possibly also paths and groups. The > > current implementation of the Repoinit JCR bundle allows setting up > > factory configurations with "scripts" and "references". Scripts are > > little (or not so little) snippets of Repoinit DSL, references are > > URLs to files containing Repoinit DSL. So far so good. > > > > For a maintainable setup, the Repoinit DSL should be checked into Git > > (or SCM of choice). However, as Dan already noticed in "SLING-9524 - > > Add Support for Bundle URL References", it is not currently possible > > to reference bundle resources in a stable fashion. This renders the > > "references" Configuration virtually useless (that may be too harsh, > > maybe I am missing something). The "scripts" configurations work, but > > they require the Repoinit DSL to be embedded in a configuration file, > > typically requiring escaping and all on one line. > > Until October 2017 Sling Karaf was using a dedicated bundle for repoinit files > which worked AFAIR quite well (see SLING-7177). > I also do not like the escaped one liners in JSON and will look into this > approach again. > > See also the very last diff entry in > https://github.com/apache/sling-org-apache-sling-karaf-configs/commit/f5d9b596e854e91e5f8fc81a575f89beb0082f62 > > references=[\ > "raw:classpath://org.apache.sling.karaf-repoinit/sling.txt",\ > "raw:classpath://org.apache.sling.karaf-repoinit/sling-discovery.txt",\ > "raw:classpath://org.apache.sling.karaf-repoinit/sling-event.txt",\ > "raw:classpath://org.apache.sling.karaf-repoinit/sling-i18n.txt",\ > "raw:classpath://org.apache.sling.karaf-repoinit/sling-installer-jcr.txt",\ > "raw:classpath://org.apache.sling.karaf-repoinit/sling-scripting.txt",\ > "raw:classpath://org.apache.sling.karaf-repoinit/sling-validation.txt",\ > "raw:classpath://org.apache.sling.karaf-repoinit/sling-xss.txt"\ > ] > > HTH, > O. > > > > To improve the situation I have two suggestions. > > > > (1) Add support for a Bundle-Header (e.g. Sling-RepoInit) with a comma > > separated list of paths to bundle resources. This would allow > > embedding Repoinit Files into bundles, which could be useful for > > keeping service-users creation and bundles together. However, this > > solution would not lend itself to supplying runmode-specific Repoinit > > files. Of course the header could be extended to support a runmode > > qualifier, but to me at least it starts to feel a little wrong when > > bundles (i.e. code) have to know so much about runmodes (i.e. > > deployments). > > > > (2) Add OSGiInstaller support for Repoinit files. I.e. recognize files > > in "install" or "config" folders with a ".txt" extension that can be > > parsed by the RepoInitParser. This requires separate deployment, e.g. > > via a content-package. However, runmode support then comes out of the > > box. > > > > I could imagine adding one or both of these solutions to the Repoinit > > JCR bundle. > > > > Any thoughts on this? Are there any concerns regarding security or > > other objections? > > > > Thanks > > Julian > > > >
