On Thursday, October 29, 2020 3:44:35 PM CET Julian Sedding wrote: > Hi 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"? Yes, Pax URL which can be used outside of Karaf of course: https://ops4j1.jira.com/wiki/spaces/paxurl/overview And see here for the bundles: https://github.com/apache/sling-org-apache-sling-testing-paxexam/blob/master/ src/main/java/org/apache/sling/testing/paxexam/SlingOptions.java#L168 Regards, O. > 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/f5d > > 9b596e854e91e5f8fc81a575f89beb0082f62 > > > > 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
